SUIT Working Group at Virtual IETF 109 === Agenda ------ 1) Logistics - Agenda Bashing - Minute Taker - Jabber Scribe - Bluesheets 2) SUIT Architecture - draft-ietf-suit-architecture - Discuss any issues raised by IESG evaluation 2) SUIT Information Model - draft-ietf-suit-information-model - Discuss any issues raise by IETF Last Call 4) SUIT Manifest Format - draft-ietf-suit-manifest - Discuss open issues; get ready for WG Last Call 5) Secure Reporting of Update Status - draft-moran-suit-report - Discuss open issues; get ready for WG call for adoption 6) Strong Assertions of IoT Network Access Requirements - draft-moran-suit-mud - Discuss open issues; get ready for WG call for adoption 7) Any Other Business (if time permits) Jabber: xmpp:suit@jabber.ietf.org?join MeetEcho: https://www.meetecho.com/ietf109/suit Etherpad: https://codimd.ietf.org/notes-ietf-109-suit# Notes: --- 1) Logistics - Agenda Bashing - Minute Taker - Jabber Scribe - Bluesheets Note Taker: Hannes Tschofenig Russ started with the introduction and gave a status update. --- 2) SUIT Architecture - [draft-ietf-suit-architecture](https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/) - Discuss any issues raised by IESG evaluation Brendan spoke about the comments from the IESG. The feedback was positive. Editorial changes and clarifications will, however, be needed. Question about whether references should be normative or informative. Brendan believes the references should be informative and forward references are OK. DaveT agrees. TEEP depends on SUIT and RATS. RATS does not depend on SUIT. Russ agrees. No disagrement to keep the references informative. Hannes created PRs to address the editorial review comments. --- 2) SUIT Information Model - [draft-ietf-suit-information-model](https://datatracker.ietf.org/doc/draft-ietf-suit-information-model/) - Discuss any issues raise by IETF Last Call Brendan mentioned that there were only two reviews. GenART says the document is fine. SecDIR review says that it is not ready. SecDIR review suggests to change the title of the document to "Information and Threat Model". Russ and DaveT have no objections. Suggestion to change the order. Currently it is Elements, Threats and Requirements. Initially it was Threats, Requirements, and Elements. Proposal is Elements, Requirements, and Threats. Henk: Whatever order you select, it is the wrong one. Proposal: threats, requirements, elements DaveT: I prefer order it is in right now. Henk agree that the document should be labled "Threat Model and Information Model" then the body of the document. This is also less work. Agreement is to go for re-ordering to threats, requirements, and elements. Add a note early in the document to allow the reader to jump to the elements. Clarifications needed for OPTIONAL vs. REQUIRED with the text around serialization. Need to split what is OPTIONAL and what is REQUIRED. There was a question by the reviewer about appropriately referencing the Microsoft STRIDE document. DaveT will find out whether there is a better link to the STRIDE document. DaveW: STRIDE is discussed in Shostack (2014). *Threat Modeling: Designing for Security*. Wiley. pp. 61–64. ISBN 978-1118809990. It might be good to use this as the stable reference. Russ: Having a stable reference would be useful for the community (beyond the SUIT working group). Matt: Clarification question about the SUIT specification. --- 4) SUIT Manifest Format - [draft-ietf-suit-manifest](https://datatracker.ietf.org/doc/draft-ietf-suit-manifest) - Discuss open issues; get ready for WG Last Call Brendan goes through the changes in the SUIT manifest specification. Topics: - Private enterprise numbers No concerns were raised about the approach as documented. - remove SUIT_Digest from COSE payload No concerns about the change. We are using the COSE mechanism in detached mode. - Add CBOR tags Asked if anyone has a preference for the 3-byte tag value. DaveT suggested 107. - Index lists No comments about the change. - SUIT_Report removed No comments about the change. - Editorial changes Thanks to DaveT for his extensive review. DaveT raises a question that surfaced in the TEEP group regarding component ids. The current TEEP protocol draft suggests to use COSWID but the SUIT specification uses UUID. Brendan: The TEEP protocol draft should tell what content to put into the component id. SUIT will always have a component id and may carry a COSWID but it may be stripped someone along the path. DaveT: In a small editors group we concluded that SUIT does not need changes. Henk: There is a draft -- suit-claims-id. There is a system property claim that is contains a component id. It may be included in the EAT draft. Matt: Should a PEN OID entity be required to publicly present their information in the same format? Matthew Gimore (Matt, in chat): How would SenML fit with a SUIT manifest? Brendan: I don't know SenML and cannot answer the question. DaveT: I don't see the overlap with SUIT. DaveT: Refers to an email he posted to the list (see https://mailarchive.ietf.org/arch/msg/suit/dBSWDXWxK0kl21XTw_RpQNyMEf0/). Asking whether SUIT should talk about installing/deleting/updating payloads. Brendan: Sees challenges with introducing delete operations. He believe the TEEP use case is orthogonal to the SUIT use case. DaveT: The issue can come up when you install multiple independent components. Brendan: I have to think about this aspect. We need to think about cases where there are multiple copies of a component. DaveT: TEEP has to express the components that are installed and there has to be an identification that there is a need to identify it uniquely. We currently do not have the answer but I believe the solution has to go into SUIT. Brendan: Will post a mail to the list. --- 5) Secure Reporting of Update Status - [draft-moran-suit-report](https://datatracker.ietf.org/doc/draft-moran-suit-report/) - Discuss open issues; get ready for WG call for adoption Reporting what the manifest processing did. If you have a copy of the manifest, what do you need to do a backtrace. DaveT: question to DaveW and Russ, should we ask for adoption at this time? The TEEP protocol took a dependency on this document in the hope that the group would adopt it. Russ: I have no objection; does anyone object to start a call for adoption? I see no objection - only support. **ACTION: The chairs will discuss with the SecAD if a recharter is needed or if it is ok to start a call for adoption.** --- 6) Strong Assertions of IoT Network Access Requirements - [draft-moran-suit-mud](https://datatracker.ietf.org/doc/draft-moran-suit-mud/) - Discuss open issues; get ready for WG call for adoption Already discussed at [IETF#108](https://datatracker.ietf.org/meeting/108/materials/minutes-108-suit-03.html). The idea is to convey MUD info in SUIT. Russ: Should we adopt this document? DaveT: At the previous IETF we had talked about what the right WG is and the conclusion was SUIT. DaveW: We do need to re-charter. **ACTION: The chairs will initiate the re-chartering process** --- 7) Any Other Business (if time permits) No time was available.