Minutes IETF102: suit
Software Updates for Internet of Things
||Minutes IETF102: suit
IETF 102 SUIT Working Group in Montreal, QC, CA
Wednesday, 18 July 2018 at 09:30 EDT
1) Agenda bashing, Logistics -- Chairs (5 mins)
2) Hackathon Report -- Hannes (15 mins)
3) Suit Architecture -- Authors
4) Suit Information Model -- Authors
5) Suit Manifest Format -- Authors
6) Next Steps -- Chairs
Agenda bashing, Logistics -- Chairs
- WG Update
-- Architecture and information model adopted by WG
-- Virtual Interim on 6 June 2018, focused on architecture and manifest
--- Minutes have been posted
-- Hackathon projects at the interim and at IETF 102
-- Missed serialization formats milestone, but doing fairly well on
-- Need to focus on the manifest information model milestone, and need
to create the missing milestone for the architecture document
Hackathon Update (Hannes Tschofenig)
- Demonstrated ability to generate manifest, encode with CBOR, sign
with COSE, and verify with SUIT prototype board
- Board manufactured for Hackathon (see picture in slides)
- Writeup produced by Jaime -- useful for newcomers
-- See https://etherpad.tools.ietf.org/p/FUIETF102
- Lessons learned:
-- Need easier set up process
-- Need to release new COSE implementation with a different license
-- Good to have a stripped-down CBOR implementation for decoding the
manifest on the embedded platform
-- Traversing some of the data structures with the tinyCBOR API is
-- Want to focus on producing more running code and increase
involvement from the WG
-- Will start discussion on list for planning for IETF 103 Hackathon
Architecture (Hannes Tschofenig)
- Lots of changes in draft-moran-suit-architecture-03
-- New terminology; see three slides in presentation
-- Updated operating modes
-- Device firmware update examples
-- Additional coauthor (David Brown)
- Settled on terminology for authors and communicators
-- Device/network operator split motivated by discussions in London
and interim; may need to introduce more players
- Architecture includes concept of a Trust Provisioning Authority (TPA)
to distribute trust anchors and authorization permissions
- Need to document in greater detail various trust scenarios
- Use cases might drive particular solutions. Hannes says the use cases
are in the information model document.
- Brendan points out that the TPA will often be the OEM, but not always.
The TPA allows for a layer of abstraction for this role to enable
scenarios such as customers deploying their own trust anchors.
Erik: Try to separate the issues, don't conflate them.
Jonathan: Can we coordinate terminology with other RFCs that include
Hannes: They are different; coordination is a long shot.
Carsten: Maybe we can describe how they are different.
- Three modes: client-initiated, server-initiated, and hybrid. NATs
and similar middleboxes might dictate what mode can be used.
Dave Thaler: Confusion previously brought up by others about term
"mode" implying a device needs to support multiple modes, maybe "model"
would work better to be clear that's not the case.
- Walk through some examples
Keith Moore: May have to update low-RAM devices in slices; SoC
encompasses a wide range of systems, including the BeagleBone.
This needs a lot of work, and I'm happy to provide input.
I can help write improved use case examples.
(David Brown tried to make comments over meetecho, unintelligible)
- Human rights review (link in slides) recommended encryption of
manifests when a device is easily associated with a human.
-- Proposed text on list, but issue remains open.
From jabber: Group needs to decide at what level to set requirements.
Dave Thaler (as individual): Be careful to not overcomplicate the
architecture; can just encrypt the manifest as a binary blob and can
take it from there recursively.
- Next steps for this document
-- More editorial cleanup
-- Incorporate feedback from this meeting
-- More text about device interactions and bootloader design
-- Better alignment with information model
Information Model for Manifests
- Use cases:
-- Multiple Network Operators with a Single Device Operator
-- Single Network Operator with Multiple Device Operators
-- Shows that a single signature is not enough to guarantee that
requirements of the device-controlling entity are met.
- Incorporated terminology from the architecture document.
- Added new use case for rollback, which allows distribution of new
manifest pointing to old firmware. Capability implicitly allowed in
earlier versions of the specification; this use case makes it explicit.
-- Question of whether this opens you up to a downgrade attack.
Hannes: The risk is managed via the manifest sequence number.
Brendan: The provable intent of the author helps here too.
- Storage Location element tells device which component is being
updated (two storage locations, file system or flash).
- Component Identifier indicates which part of the storage
architecture is the target of the payload.
Carsten: Earlier you used the phrase "part of the component". That
concept needs to be clarified.
- Some conditions need to be checked before installation (identifiers,
time, precursors), but other conditions need to be checked after
-- Still need to reflect split of pre- and post-conditions in the
- Directives, Aliases and Dependencies need to be combined into one
element in the manifest.
Henk Birkholz: In my earlier contribution today, I was copying this,
but I have no clue about its intended semantics.
- Next Steps for this document:
-- Fix inconsistencies between manifest format and information model
(and, in the future, start with one document and then split the
Henk: Need to incorporate concept of major and minor versions.
Stephen Banghart: Be consistent with capitalization of "must"
Hannes: Still deciding what is mandatory to implement.
CBOR Manifest Serialization
Carsten: This is the data model?
- Open issue: Primary object is array or map?
Brendan: I think it is an array because most fields are mandatory.
Carsten: Agree, this is a stable set of fields.
Henk: 5 are mandatory, 7 are optional.
Dave Waltermire: Prefers map to reduce branches and add extensibility.
Carsten: If you need to see whole picture, map is fine. Array is
beneficial if you can do processing without seeing whole thing.
David Brown: Document needs to identify the processing sequences.
Carsten: Planning to define slightly different canonical encoding in
Ben: Have to keep in mind that a new extension might be critical.
Brendan: I like the idea of a pull parser. Maybe we can combine these
concepts. Put elements in order needed by device to get best of both
David Brown: Maybe we can contribute [something] back to CBOR.
Henk: We could use a 2D array, but why, when there are maps.
- Open issue: Should the manifest graph be a tree?
Carsten: Trees allow tying control flow to sequence in which they come
in, easier to process.
- Open issue: One digest for the whole manifest?
-- Should sections be severable?
-- COSE has no algorithm identifiers for digests, do we need to create
-- Encrypt manifest?
- Tree Process Description (Slide 5)
Dave W.: Have you thought about namespace for component identifiers?
Brendan: It's like an OID (object identifier).
Dave W.: Need to clarify that.
Dave W.: Think about how to manage extensions, follow common pattern.
Brendan: Negative numbers for extensions, Positive numbers for
registered extensions (e.g., specification required)
Henk: Use CDDL. Also, I couldn't compile it due to name discrepancies.
- Description of installation process in manifest (Slide 13)
Hannes: Need to sync up information model and data model.
Chairs: Let the authors do one more update, particularly regarding
map vs. array, and then we will do a call for adoption.
Brendan: Works for me.
Hannes: Preference in room for map.
Dave Kemp: Some serializations provide ordering.
Chairs: Ordered vs. unordered can be addressed in information model.
Ordering important for signing. Need to discuss and define where
ordering does matter, and prioritize documenting these concepts in
the information model before updating the data model. Could be
done in parallel if being done by different people.
Henk: Can register CBOR tag if ordered map is important to the WG.
Brendan: Ordered multimap has benefits.
Henk: ... and disadvantages.
David B.: Order is important for signing and making poll parsing
easier. Processing steps may have different actors, how do we
Brendan: Each actor defines a new process tree, telling recipient
what to do. How deep could that queue get?
David B.: Maybe 30.
Brendan: 30 is hard for a constrained device; might manage 3.
- Current Changes: updates from previous versions (Slide 15)
- Guiding principle for severable test is that severable part is used
by humans, not devices. So, it lives outside the authenticated container.
David B.: Are we creating a CBOR tag for this?
Dave W.: CoSWID is targeted toward management systems, perhaps we can
use that for some of the human-focused capabilities, and leave manifest
work as machine-focused.
Henk: CoSWID has firmware resource extension; we detached it and sent
it to SUIT. It was submitted last night. It is based on maps.
Hannes: Aren't you an author of the information model?
- Split payloads in multiple parts, allowing multiple payloads to
be used (Slide 20)
- Split conditions into pre- and post-conditions (Slide 22)
- Component identifier replaced storage identifier (Slide 23)
- Virtual interim will be mid-to-late September
-- Chairs will send out Doodle poll on dates
- Architecture: expect updated draft by next week
- Information Model: expect updated draft by the virtual interim
- Data Models (both Moran and Birkholz): expect updated draft by the
Hannes: Need to get more companies in the conversation
Dave W.: Need convergence between historic work and our current
efforts. Henk's draft is an example of how we can drive that
convergence. CoSWIDs can help with management functions; it has
some adoption with industry in XML format. We can arrange a
presentation at the virtual interim. Henk made several
improvements to the DM too.
- Milestones: Chairs will work with AD to add architecture milestone.
Hannes: Who will be in Bangkok and participate in the Hackathon?
-- 4 or 5 hands went up
-- There will also be a couple remote participants.
-- Chairs will pose question to the list.