SUIT Working Group at IETF 106 in Singapore Agenda ------ 1) Agenda bashing, Logistics 2) Developers Gatherings - Hackathon Report - Workshop in January 3) SUIT Architecture - draft-ietf-suit-architecture 4) SUIT Information Model - draft-ietf-suit-information-model 5) SUIT Manifest Format - draft-ietf-suit-manifest 6) Next Steps Jabber: xmpp:suit@jabber.ietf.org?join MeetEcho: https://www.meetecho.com/ietf106/suit Etherpad: https://etherpad.tools.ietf.org/p/notes-ietf-106-suit Notetakers: Carrick Bartle, Stuart Cheshire Notes: 1) Agenda bashing, Logistics Status: 2 drafts in last call, 1 in progress Milestones: on track Plan is to submit drafts this month, manifest in March --- 2) Developers Gatherings - Hackathon Report - Workshop in February (was January) There was no SUIT work at the IETF 106 hackathon this time Hannes Tschofenig (ARM) presented information about the upcoming “Securing the IoT” Hackathon in Berlin, 17-19 February 2020 Would like to have a tutorial on the first day Work will be done relating to: Software Updates for Internet of Things (SUIT) Trusted Execution Environment Provisioning (TEEP) Remote ATtestation ProcedureS (RATS) Hackathon is free but need registration info to get a count since there may be some hardware provided for some things See https://siot-hackathon.github.io/ --- 3) SUIT Architecture https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/ Hannes Tschofenig (ARM) presented a status update on draft-07 Previous version had added extra more text on bootloaders, and added TEEP info Kathleen Moriarty then posted a review that led to version 7 Hannes discussed the state of the art in security mechanisms (confidentiality, hash-based sigs). Devices with long lifetimes are at a disadvantage when classical security mechanisms in unchangeable code in a device no longer work Dave Thaler: section 3.3 says a mandatory-to-implement set of algorithms "has to be defined"... Should it say "is defined in the SUIT manifest"? Brendan Moran: A set is not currently defined in SUIT manifest, but can't see anywhere that would be a better place to define it. ACTION: Brendan to define in the SUIT manifest, and the arch doc should point to the SUIT manifest document for the set David Waltermire, NIST: Have you considered requiring 128-bit keys here? That's the NIST recommendation for lifetimes > 10 years. Kathleen Moriarty: draft should mention applicability to higher-end use cases as well (e.g. those that use classical Linux), not just for lower-end devices Brendan Moran: right, not prevented from being used by anything else. I have heard talk about using this to update Linux and even Windows Dave Waltermire: SUIT charter also doesn't prevent use for higher-end Dave Thaler: just specify in architecture doc that it can be used in anything; it's already in the manifest Michael Richardson: we've discussed this already, during chartering, we just have to beat people over the head about this? Updating is totally in scope. It's a perception issue; trying to address it Michael Richardson: do we need more examples? Things that SUIT may not seem appropriate for? ACTION: Hannes will provide a -08 draft soon after the meeting addressing examples of update use cases that illustrate use of SUIT in more capable devices. The chairs will submit this revised draft to the IESG. --- 4) SUIT Information Model https://datatracker.ietf.org/doc/draft-ietf-suit-information-model/ Brendan Moran, ARM, presented a status update on the Working Group Last Call Extensive comments from Dave Thaler lead to draft-04. Emmanuel Baccelli, Inria: We need to be mindful of RAM requirements Brendan Moran, ARM: This is specifically for integrated (and therefore small) payloads, e.g. encrypted key, not payload of update David Thaler, Microsoft: Who is expected to know what payload size will fit in RAM for any particular device? Is the manifest author supposed to know it? Brendan Moran, ARM: This is exactly why I want feedback on this. Either enough to fit a wrapped key or up to implementer (Brendan doesn't like latter, but picking a number out of the air might break things.) Dave Waltemire: There might not be pre-knowledge of the size Brendan Moran: Will look at capability reporting, get info from device at time of manifest creation Hannes Tschofenig, ARM: The TEEP WG talked about a capability mechanism. The manifest has to fit in RAM so you can verify the signature. The manifest will generally be very small, so typically not an issue but could get larger, e.g. if need to include key. David Thaler, Microsoft: We could define (similar to IPv6 reassembly) a mandatory minimum size that devices must support; devices are allowed to support larger if desired. Brendan Moran: need more time to think about it. I like Dave's suggestion, except we could end up with devices that use min instead of what they need. Hannes Tschofenig, ARM, will consider the options and make a recommendation on the list by the end of this week. Mohit: can you define max based on large key size? At least document these considerations and not give min/max, and implementers would have to do their own testing. ACTION: With regards to size of the integrated payload, the draft will not specify a specific size, but will provide some considerations relative to possible sizes. Brendan will work on language to post to the list in the next couple days. The WG will have 2 weeks to provide any final feedback on the draft. After addressing feedback, the draft will be sent to the IESG. --- 5) SUIT Manifest Format https://datatracker.ietf.org/doc/draft-ietf-suit-manifest/ Brendan Moran, ARM, presented a status update on SUIT Manifest. Draft-moran-suit-manifest was previously adopted as a Working Group document. Now draft-ietf-suit-manifest-02. Interpreter behavior sections were added to help implementers, and make testing easier. Required checks: e.g. validation of sigs, vendor ID, dependencies have been executed Added text fields that had been missing, e.g. to UUID5 function, json/yaml-source (input file can be incl. in text fields) The name “SUIT Manifest” suggests this is only for constrained devices, and is not amenable to discovery via Google searches. Russ Housley, Vigil Security LLC, suggested changing the name to “Software Update Manifest” Dave Thaler: I like "Software Update Manifest" ACTION: Change the name of the draft to "Software Update Manifest" Example section is very big, what should we do with it? Prune some info (JSON representation), Move to appendix, or Move to another doc? Dave Thaler: All three WG chairs say to do both of the first two (prune some, and move to appendix) Brendan Moran then presented the Map-Test-Execute proposal Dave Waltermire: Why do you need temporary parameters? Params won't be applied to system state until tests are done, but need to apply parameters before tests since the tests work on the parameters. If the tests succeed, then the temporary parameters become committed. Dave Waltermire: was confused by the terminology If using A/B offset, should be required For single-image devices, not required want feedback on Map-Test-Execute, especially for multi-component devices David Waltermire, NIST: Would anyone in the room implement Map-Test-Execute? No one spoke up. Brendan Moran: This is essentially a compression scheme for compressing the manifest itself. My posting on the list showed what it would do in variety of circumstances Henk Birkholz: Many CBOR items still have text values in them. We are considering allowing LZ4 compression to a CBOR data item. The combination of CBOR and LZ4 also used for DNS benchmarking by ICANN and they liked it; reduced data significantly. Brendan Moran: We don't want LZ4, as it requires a 64k table-size Dave Waltermire: We also have to keep in mind the size reduction vs. computation cost tradeoff Henk: Next question, SACM proposed using CWT structure instead of CoSWID CBOR structure in front of manifest, to ease adoption of the data structure. CWT parsers are everywhere. SUIT manifest currently has same structure as CoSWID CBOR item. Brendan Moran: pro-SUIT tag, prefer it to CWT Henk Birkholz: will SUIT tag hinder adoption because it's not a CWT and it's less common? Brendan Moran: don't think so; this is a specific use-case. wouldn't matter to me Dave Waltermire: our charter is to make SUIT manifest format Hannes: what happens if you take the CWT but not the mandatory fields in there? Dave Waltermire: Out of time, need to continue discussion on the list Brendan: We are adding text fields, but they only take the size of a digest to populate --- Dave Thaler presented Manifest Requirements from TEEP WG Some of these requirements are supported already by SUIT Brendan: having a URI that's not binary download URI is an easy add Requirement: Need a way to specify "create me a security domain" as an installation action in manifest Brendan: already do-able; if need explicit, easy add Requirement: Ability to update a file that isn’t a binary executable Brendan: can already update non-executable binary Henk: if manifest is lacking semantics, can be added by root code exception Requirement: indicate which TEE a binary should be installed to Brendan: that's the whole point of component ID, which is what you use there. Just need to confirm that this works Suggestion: add use-case template for TEEP to the SUIT manifest draft along with the other use case templates? Brendan Moran: yes, would love to --- Distributed SUIT Architecture Model - Seoyun Choi, Protocol Engineering Lab, Sangmyung University Proposal to use Blockchain, to reduce load on servers, and handle the situation where an author writes and signs some software and then disappears. David Waltermire, NIST: Who is going to host the Private Blockchain platform? If the software author disappears, won’t the corresponding Private Blockchain go away at the same time? Seoyun: Also other articipants who want to be nodes in the blockchain Brendan: Unclear on what happened after author disappeared. Why is server not responding? Seoyun: Because servers are managed by author Brendan: SUIT was designed for untrusted content distribution networks. Is blockchain an untrusted content distribution network? Seoyun: Yes Brendan: Ok, the existing architecture is already compatible with this Michael Richardson: The blockchain can just be a URL like any other URL Michael Richardson, Sandelman Software Works: I like the idea of firmware images being stored independently of the author who wrote it. If this is done using blockchain, what are the incentives for people to do the computational work to generate the blocks? Some might have an incentive to do so for servers that connect externally to get images, and internally to serve them to private devices. Stephen Banghart: This sort of thing has been done before, distrbuted files over blockchain, currently in use for immutable files. Using it for SUIT is cool, and I don't think we need to change SUIT to support it. Hannes Tschofenig, ARM: If the author disappears, what happens to the author’s private key, which is needed to sign future updates? Being unable to get any updates in future might be an issue. Waltermire: Take further discussion to the list, we are out of time --- END