1) Logistics
2) SUIT Architecture -- RFC 9019
3) SUIT Information Model
4) Firmware Encryption with SUIT Manifests
5) SUIT Manifest Format
6) Secure Reporting of Update Status
7) Strong Assertions of IoT Network Access Requirements
8) Any Other Business (if time permits)
The discussion of Firmware Encryption with SUIT Manifests was moved earlier in the agenda to accomodate individual schedules. The reordered agenda is shown above.
Minute Takers are Hannes Tschofenig and David Waltermire. Also, all participants were asked to add their names to the blue sheets section in the Etherpad. Etherpad: https://codimd.ietf.org/notes-ietf-interim-2021-suit-01-suit#
Jabber Scribe is Russ Housley. Jabber: xmpp:suit@jabber.ietf.org?join
Webex: https://ietf.webex.com/ietf/j.php?MTID=m33c3ec34b20789e79025d2e73ac322c1 Meeting number: 161 318 3724 Password: IoTSoftware
The SUIT Architecture document was recently published as RFC 9019.
Brendan Moran (not on the call yet) has submitted an updated draft with the changes requested by the IESG. The WG is encouraged to review the changes. The document will move to the RFC Editors queue soon.
Dave Thaler (DaveT) went through the Pull Requests (PRs) that went into the most recent update. There were no comments during the meeting.
Hannes Tschofenig provided an overview of the Internet-Draft, which was just posted a few hours before the meeting.
DaveT (as Chair): Understanding that few have read the new draft, based on the overview provided by Hannes, would this draft make sense to adopt as a WG draft? Would we need a charter update to adopt this? Previous guidance from Roman (the Security AD) is that if this is part of the orginal chartered work a charter update is not needed. Does the WG think this is an update to the original SUIT manifest document?
Russ Housley: We asked Hannes to not delay the original manifest document for this work. This means that this work can be considered to be part of the original charter, together making up a complete manifest capability.
DaveT: Agree.
Brendan Moran: That question may be irrelvant if we recharter anyway.
DaveT: Yes. But we don't need to wait.
David Waltermire (DaveW) (as Chair) we should start the call for adoption now for a 3 week period.
DaveT: Agree.
ACTION: Start a call for adoption after this meeting to run for 3 weeks.
ACTION: Henk Birkholz and Carsten Bormann to review the CDDL representation in the draft.
Brendan Moran (now on the call) talked about the changes to the latest manifest draft.
Change "Garbage collect" to "Unlink". Supported by Ira. No concerns raised.
Suggestion to remove the COSE definitions from the Manifest CDDL (with a note that the CDDL is only correct if the manifest CDDL is concatenated with the COSE CDDL).
Carsten: Agrees. An intermediate solution would be to put the COSE CDDL into the document as an appendix.
Ira McDonald: Does not like copying the COSE CDDL into an appendix.
Carsten: Believe the COSE definitions are clear when referencing a specific RFC.
DaveT: We should probably have a test vector in our repo to help implementers confirm that their code can parse according to the proper definition.
Decision: Do not provide full CDDL in an appendix; provide clear description to concatenate the COSE CDDL to the end to get the complete CDDL.
Carsen: Suggests a reference Section 1.4 of 8152bis for the full version of the COSE CDDL.
Brendan raised the issue of detached recipients.
DaveT: Liked the idea from a TEEP WG use case perspective. Recipient structures may change in the delivery process, and recipient updates should not break the signatures.
Discussion lead to a the idea to move the COSE_Encrypt structure outside the manifest in the envelope. This would require a change to the manifest and envelope.
The group could not come to a conclusion about the issue and requires more thoughts about how to change into the specification.
ACTION: Brendan to propose a way forward on the mail list.
Øyvind: Would like to bring up some questions based on his message to the mail list (https://mailarchive.ietf.org/arch/msg/suit/EFE31WP1qyISKDYuE7KLmwrCSIw/):
Q1. Integrated payloads / dependencies should be referenced by Component Identifier rather than URI, so they can be used in copy/validate/etc commands. As it is now, they can in principle only be referenced by component identifier after a fetch command which would mean a superfluous copy operation. This is unless fetch is specifically defined as a noop for integrated payloads and dependencies.
Brendan: I interpret the relative URI as a local device offset. The result is that you have to find the offset to the firmware image/payload. The offset is not known upfront since it depends on the number of commands in the manifest.
Øyvind suggests a more formal description would be useful to have in the manifest. Text should be added to address this.
Q2. Should there be a suit-future-reference-uri-list in parallel with suit-reference-uri that specifies where to find updates to the current manifest itself?
Øyvind: Is this be in scope?
Brendan: This would apply to self-managed devices. So far, we have considered device management for providing updates to the devices. The question is how the firmware image and the manifest get to the device.
DaveT: What if the manifest was retrieved out-of-band?
Brendan: When we are talking about modular images, the URIs might not be in the firmware. I see a reasonable argument for adding this.
Q3. I realized I never replied to Brendan's breakdown of my previous review (-07), but it was all fine, except one thing that is still unclear to me: I still do not quite understand what the "offset of the current component" in Section 8.7.6.5 refers to? "Who" manages this offset? What causes a component's offset to be updated? When, if ever, is the offset "reset"?
Øyvind: For me the component identifier is context dependent, like a slot.
Brendan: Slots have not been discussed. For proper rollback you need multiple slots with the same component identifiers or a slot identifier. We should probably have a slot identifier rather than re-using an offset. This allows offsets to be handled by the bootloader and we don't need to worry about them anymore.
Q4. Links from tables in htmlized output are sometimes truncated (part of the chapter number is lost leading to wrong links). e.g. suit-directive-set-component-index can be found at Section 8.7.7.1, but the link goes to Section 8.7.
Øyvind summarized points from his PR: https://github.com/suit-wg/manifest-spec/pull/33
The status reports can be used for debugging when manifests processing fails. Brendan goes through an example.
Russ: There is a call for adoption already underway. A charter update is not needed for this item. We wanted to give folks an opportunity to object to adoption of this work before making a consensus call.
DaveT: Roman (Security AD) has already told the WG that the suit-reports document does not require recharter; however, the MUD document (later on the agenda) does require recharter.
David Brown: We shoud figure out whether there are any security implications from leaking this information.
Brendan: This is an excellent question. The reporting policy is defined with the manifest itself. It is up to the author to decide what information to leak information.
DaveT: I think it is fine to talk about this topic in a security considerations section and guidance for how to carry SUIT reports. This can be done after WG adoption of the draft.
Russ (as Chair): I am not hearing anyone speaking against adoption, and I am not hearing any new technical discussion. Brendan submit a new version of the document as draft-ietf-suit-...
ACTION: Brendan Moran to post SUIT WG draft of the Secure Reporting of Update Status document.
Brendan: We had discussion about re-chartering for "Muddy SUIT". DaveT talked about how this fits into the TEEP use case and how a TAM could fetch the status reports from the device. He wanted to make sure that the text matches the TEEP use case.
DaveT: The draft charter text is probably okay. Suggest that we delete the word "Additional" from "Additional Specifications of Names or Numbers ..."
Proposed charter text:
To support the manifest format(s) defined by this group, it will also define formats and protocols that enable a Status Tracker to determine if a particular manifest could be successfully deployed to a device and determine if an operation was successful.
Specifications of names or numbers will enable the use of manifests, their precursors, and their successors within existing or future protocols.
Russ: The next steps are for Brendan to post the text to the WG mail list, and then the WG chairs will move it forward to Roman for approval by the IESG. Roman will ask for milestones.
DaveT: What is the timeframe for completion?
Brendan briefly summarized the SUIT-MUD draft. It is a fairly simple technical solution. The big question this document is trying to answer is: Who is in the position to say what a device is supposed to be doing?
Brendan talks about current limits of announcing MUD URLs. What if we deliver MUD files in SUIT?
Brendan: Believes MUD+SUIT+EAT is a powerful combination.
DaveT (as Chair): We need to have a charter update completed before completing a call for adoption. The tentative consent about whether we want this is "yes" but we have to wait for the rechartering.
ACTION: Brendan Moran to post charter text and milestones to the SUIT WG mail list.