SUIT Virtual Interim, 2018/02/26 People present: Andrzej Puzdrowski Antonio Langiu Antti Kolehmainen Ari Keranen Avri Doria Bjorn Hjelm Brendan Moran Brian Haberman Carsten Bormann Dave Thaler Hannes Tschofenig Henk Birkholz Juan Carlos Zuniga Klaus Hartke Marco Tiloca Markus Gueller Michael Richardson David Waltermire Peter Koch - Agenda bashing, Logistics -- Chairs (5 min) - WG status -- Chairs (5 min) Summary: Dave Waltermire welcomed everyone to the newly formed SUIT WG. The WG then discussed participation at the IETF 101 Hackathon. Detailed discussion: Henk, Hannes, and Brendan all reported they would be there for SUIT. Ari, Carsten, and Hannes all reported they would be there for WISHI. It was suggested that SUIT and WISHI either share a table or have adjacent tables, depending on the number of people. Acton items: ACTION ITEM (Hannes): WISHI hackathon, colocate - Hannes will setup a wiki entry - ITU-T-SG-17-TSB Liaison Statement -- Chairs (10 min) Summary: Dave Thaler led a discussion of the liaison statement received from ITU-T SG 17. The statement says it is for our information, not a request for action or a question asking for a response. SG 17 has a work item in progress that the statement says covers requirements, architecture, and a high-level update procedure sequence. The WG interpreted this explanation as not including a detailed protocol. The liaison statement also explained SG 17’s taxonomy of roles from its document: Device Core, Communicator, Status Tracker, and Firmware Server. The WG discussed these four roles and they seem to make sense for IETF to use as well, although "Update Server" is also used by some IETF drafts (such as the arch draft discussed in the next agenda item) as a synonym for a Firmware Server. Hannes reported that OMA also has terminology for various roles. Detailed discussion: ?: Consider thanking for providing this info ?: Ask for them to keep us up-to-date on any progress Henk: Consider adopting the terminology Dave: It would be useful for several SDOs to use the same terminology. Take this into account when writing our documents. Hannes: OMA has worked on a device management solution, with a software update mechanism that is similar to the ITU-T approach. Hannes will post the OMA terminology WG will provide other terminology from other SDOs Dave W. will talk with Takahashi about the ITU-T liaison statement. Hannes: Will you write back thanking them? Dave: We should wait until we have something to update them on (e.g., adopting a draft). Dave: We need to talk to other IETFers that are working in the ITU-T on this. Action items: ACTION ITEM (Hannes): report back to the WG on OMA’s terminology for roles ACTION ITEM (anyone): any other WG members please provide other terminology from other SDOs ACTION ITEM (DaveW): Dave W. will talk with Takahashi about the ITU-T liaison statement. - Discussion of proposed work (90 min) - draft-moran-suit-architecture-01 Summary: Most of the time was spent on discussion of this document which was recently updated in response to WG feedback (e.g., to use CBOR/COSE), and the authors proposed it for adoption by the WG for the architecture document charter milestone. Brandan and Hannes walked through the various use cases and architecture components (see slides). Overall feedback was positive, but the WG provided additional feedback to the authors. For example, the coverage of counter-signing is lacking, based on list discussion. The authors agreed to update the document in the next few days with the feedback from the interim meeting. The meeting participants believed that the document was a good starting point, and has sufficient completeness and author cycles to be considered for WG adoption. The WG understands there was another architecture document (Nandakumar’s) but that document is less comprehensive, has not been updated for some time, and had no proponents at the interim meeting. Detailed discussion: Slide 5: Dave T.: Counter-signing can provide a means for operators to selectively authorize what software may be deployed. Transport security can provide further access control to allowed software for deployment. Carsten: Operators need to control what specific software is allowed to be deployed Dave T.: Who checks the signature. The communicator? The device on which the software will be deployed? Brendan: This slide was not intended to go to this detail Dave T.: Ok. We need to make sure it is well understood how the manifest fits into transport security and code signing? Hannes: Do we need to sign the manifest twice by the developer and operator? We don't have much text on this yet. Dave T.: There is consenus that we need to support multiple sigantures. Hannes: We need more text on this. Slide 6: Dave W: Is the hash discussed here in the signature or a digest of the software. Brendan: The manifest contains many hashes (e.g., over the software, signature over the manifest) Hannes: We are talking about the hash in the signature here. Carsten: Should we treat the contents of the manifest as claims or as metadata? The device needs to analyze these claims. Henk: A minimum set of data needs to be required. Hannes: Do we need to change terminology or make a more fundimental change? Carsten: No change, but we should think about these as a set of claims as a mental model. Hannes: Ok. We can try to rephrase in this style to make it easier to understand. Slide 7: Dave T., Dave W.: This is a simplified architecture. There may be other, more complex paths. Brenan: The key point here is the notion of end-to-end security through an untrusted intermediary. ALL: Consensus that we need more in diagrams to discuss encapsolation of the firmware in the manifest, second authors, and other components (e.g., communicators). Slide 8: Markus: How would you manage the decryption keys? Hannes: The content decryption key would be included/referenced in the manifest for the specific device. Dave T.: The device should not have to download a bunch of information that does not pertain to the device. The manifest must be decomposable to support this. Brendan: Providing a URL for the device to lookup its key is a way to support this. On a USB device, a table can be used to lookup the key for a device. Dave T.: I am good if this lookup is not burdensom. Hannes: We need to highlight the issues around these use-scenarios. Any feedback on the Architecture? Poll: Have you read the architecture? 6 hands raised Question: Do the authors believe the draft is a good starting point for WG adoption? Dave W.: We need to ask about other architecture drafts. We have both draft-moran-suit-architecture-01 and draft-nandakumar-suit-secfu-solution-arch-00. Chairs: Start the adoption call after the next version of draft-moran-suit-architecture-01 is posted on the list to conclude at the meeting at IETF 101, unless we hear that draft-nandakumar-suit-secfu-solution-arch-00 is a going concern. Action items: ACTION ITEM (Brendan): Update document to reflect meeting discussion ACTION ITEM (DaveW): Ping Nandakumar to check the status and intent of the authors of the other draft ACTION ITEM (Chairs): Start a call for adoption after that, to conclude during the London IETF meeting. - draft-moran-suit-manifest-01 - draft-ietf-sacm-coswid-03 Summary: Only a brief period of time was spent on these due to lack of time. A quick run-through of two proposals was done, but there was not time for deep discussion, so further discussion was deferred to the London meeting and mailing list.