SUIT BoF at IETF 100 in Singapore Monday, 13 November 2017 at 15:50 Note Taker: Michael Rosa Jabber Scribe: Stephen Banghart Jabber: xmpp:suit@jabber.ietf.org?join MeetEcho: http://www.meetecho.com/ietf100/suit Etherpad: http://etherpad.tools.ietf.org/p/notes-ietf-100-suit AGENDA Agenda bashing, Logistics -- Chairs (5 min) Review of proposed charter text -- Chairs (10 mins) Charter discussion (45 mins) Discussion of new work items (20 mins) Hannes Tschofenig draft-moran-suit-architecture draft-moran-suit-manifest Suhas Nandakumar draft-nandakumar-suit-secfu-requirements draft-nandakumar-suit-secfu-solution-arch Review of milestones & wrap up -- Chairs (10 minutes) AGENDA BASHING AND LOGISTICS Co-Chairs are Dave Waltermire, Russ Housley, and Dave Thaler. Russ was unable to make it to this meeting, so Dave Thaler stepped in. (Thanks!) Participants were reminded about the IETF Note Well. The chairs will extend charter discussion instead of new work items if necessary. No agenda bashing by anyone. REVIEW OF PROPOSED CHARTER TEXT The proposed charter under review, and it is on the IESG Telechat agenda for scheduled 30 November 2017. Hopefully it will progress quickly. Out of scope: This effort does not intend to define a transport protocol. Someone asked what the co-chair means when he says "we". He meant the proponents of the proposed SUIT WG. Cullen Jennings via remote was looking for greater clarity on transport scoping. The SUIT WG would not define new transport protocols, but the WG could specify intreoperabiltiy or security issues pertaining to use of existing transport protocols for software update. SUIT WG CHARTER DISCUSSION The proposed SUIT WG charter text can be seen at https://datatracker.ietf.org/group/suit/about/ Discussion of the proposed SUIT WG charter text: - Someone asked a question on Class 1 device. Do we assume that the device has the energy to actually do the transfer. Answer: Yes. - Paul Hoffman: Not sure if RFC 4108 is appropriate for starting just because it exists. Suggest removing RFC 4108 from charter. - Suggestion from mic to use the plural form of the word "binary" to accomodate multi-part firmware loads. - Bret Jordan: Prefer the alternate text offered by Paul Hoffman that does not require the work to begin with RFC 4108. That said, I fully support this effort. - Erik Nordmark: RFC 4108 already supports multi-part firmware loads. I do not understand what "script" means in the final paragraph. - Hannes Tschofenig: I want to respond to Erik's question. The intent was to limit the scope to exclude things like Javascript. - Alexandre Petrescu: Prefers the text offered by Paul Hoffman. It better reflects the discussions on the mail list. Discussion of the overlap with the proposed charter text for the TEEP (Trusted Execution Environment Provisioning) BoF: - TEEP BoF will meeting at 13:30 on Wednesday Afternoon - Erik Nordmark: TEEP has a more complex model abut who is authoritative for what. - Hannes Tschofenig: Agreement for proposed approach. TEEP will have a primary focus on smart phones, which have a unique operating system architecture. - Emmanuel Baccelli via remote: Need to clean up usage of "software" and "firmware". Need to recognize a firmware load might not replace the bootloader code; that remains in place. - Alexandre Petrescu: Likes the separation between firmware and software. - David Brown via remote: Class 1 devices might not have a separate trusted execution environment and an untrusted execution environment. Delayed questions from Jabber on proposed SUIT WG charter text: - Suhas Nandakumar via remote: Why are we restricting to one encoding format one we agree on the things that need to be encoded? - Hannes Tschofenig: there is a desire to have one trustworthy parser. - Paul Hoffman: There is a long history where the IETF Security Area has specified multiple formats, and the result was a failure for any of them to get adopted. It would be better to stay with one format. - Someone expressed a desire to have automatic downgrade, and it is not clear whether a topic like this is allowed by the charter. - Martin Thompson: I have a question on process about how edits will be made to reflect today's discussion. - Dave Thaler as co-chair: I want to hear from everyone in the mic line so that we understand where there is consensus. - Jari Arkko: I think this work is useful and interesting. I wonder if the work can be designed to support separate owner and manufacturer authorizations for updates. I would like to see charter text that deals with loading updates after manufacturers go out of business or end support. - Cullen Jennings via remote: Need to clarify the capabilities of the bootloader instead of the class of IoT device. - Alain Durand: Is the choice of the type of identifier in scope? - Dave Thaler as co-chair: It is in scope if its necessary for one of the items mentioned in the charter text. - Alain Durand: Are the selection of multiple transports in scope? - Dave Thaler as co-chair: A new transport will not be defined, but it is okay to specify how an existing transport will be used. - Hannes Tschofenig: Regarding Jari's point, a device may have multiple "manufacturers" are involved with building any particular device. So, Who is allowed to update the firmware is a policy decision. - Hannes Tschofenig: Regarding Cullen's previous statement about the bootloader, thinks that Class 1 is sufficient to identify the type of devices that will be addressed by the SUIT WG deliverables. - Erik Nordmark: The "manifest" talked about in the charter flows into the device. There may be a need for a few bits to represent the capabilities of the device, such as the ability to revert back to the previous firmware download. - Shawn Cooley: This group should not focus on the way that an update is formed because the difference between IoT devices is so vast. Just tell how to sign and encrypt. That said, work on discoverability and transport will be very helpful to the IT folks that are managing the networks that connect these devices. - Paul Hoffman: Regarding transports and discovery, I think the charter should say "the group will not devine any new transport mechanisms" and it should say "the group will not devine any new discovery mechanisms". This makes it clear that existing ones might be used. - Comment from mic: Strongly question "Class 1 Device" terminology in the charter. - Comment from mic: Would like to see clarification on what is "IoT" in this charter. - Hannes Tschofenig: Regarding Shawn's point, some people that build IoT device operating systems are in the room and they have been posting to the mail list. So, they do care. Co-chairs determine consensus of the participants: - Hum: Three posible choices regarding RFC 4108 in the charter: -- Use existing text with its reference of RFC 4108 -- Remove all reference to RFC 4108 -- Mention RFC 4108 in passing -- Strongest support for removing all reference to RFC 4108. - Agreement that the specification should not have dependencies that are beyond the capabilities of a Class 1 device. - Agreement that the the group should not specify any new discovery protocols. - Hum: Should we avoid the development of new transport mechanisms? -- Yes -- No -- Strong support for not the defining a new protocol for the delivery of firmware. - Hum: Should the charter have text to talk about device capabilities? -- Charter needs text -- Leave out of charter, but allow it in the to architecture -- Preference for no text in the charter about device capabilities. - Hum: Should the charter restrict to one manifest format? -- Only one format -- Not restrict the number of formats in the charter -- Much stronger for allowing more than one. - Hum: Should the charter have text on discovery of update servers? -- Charter needs text -- Leave out of charter, but allow it in the to architecture -- Stronger support for leaving the upgrade server discovery discussion to the architecture. - Cullen Jennings via Jabber: I would like the charter to say, "The architecture should provide a way to discover the firmware server." WAY FORWARD The revised charter text will be brought to the mail list for further review and comment. If the group is chartered. it will meet at IETF 101 in London. There was not time for discusion of the Internet-Drafts today. Is there interest in a virtual meeting for that purpose? More than 25 raised hands (including Jabber).