IETF 102 SUIT Working Group in Montreal, QC, CA Wednesday, 18 July 2018 at 09:30 EDT Session Chairs: Dave Waltermire Dave Thaler Russ Housley Note Takers: Jessica Fitzgerald-McKay Carsten Bormann Jabber: xmpp:suit@jabber.ietf.org?join MeetEcho: https://www.meetecho.com/ietf102/suit Etherpad: https://etherpad.tools.ietf.org/p/notes-ietf-102-suit Agenda: 1) Agenda bashing, Logistics -- Chairs (5 mins) 2) Hackathon Report -- Hannes (15 mins) 3) Suit Architecture -- Authors - draft-ietf-suit-architecture 4) Suit Information Model -- Authors - draft-ietf-suit-information-model 5) Suit Manifest Format -- Authors - draft-moran-suit-manifest 6) Next Steps -- Chairs Agenda bashing, Logistics -- Chairs Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-suit-chair-slides-00 - 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 - Milestones -- Missed serialization formats milestone, but doing fairly well on other milestones -- Need to focus on the manifest information model milestone, and need to create the missing milestone for the architecture document Hackathon Update (Hannes Tschofenig) Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-suit-hackathon-report-00 - 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 not intuitive -- 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) Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-suit-suit-architecture-02 - 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 trust anchors? 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 Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-suit-an-information-model-for-manifests-02.pdf - 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 installation. -- Still need to reflect split of pre- and post-conditions in the information model. - 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 functionality). 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 Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-suit-draft-moran-suit-manifest-01 Carsten: This is the data model? Brendan: Yes - 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 CBOR WG. Ben: Have to keep in mind that a new extension might be critical. Henk: Yes. 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 worlds. 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. Henk: Agree. - Open issue: One digest for the whole manifest? -- Should sections be severable? -- COSE has no algorithm identifiers for digests, do we need to create an update? -- 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 address that? 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. (Slide 17) David B.: Are we creating a CBOR tag for this? Brandan: Yes. 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. Brendan: Great. Henk: CoSWID has firmware resource extension; we detached it and sent it to SUIT. It was submitted last night. It is based on maps. (See draft-birkholz-suit-coswid-manifest) Hannes: Aren't you an author of the information model? Henk: Yep. - 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) Wrap Up - 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 virtual interim 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.