SUIT Working Group at IETF 103 in Bankok, TH THURSDAY, 8 November 2018 at 0900 Scribes: Zach Shelby Agenda ------ 1) Agenda bashing, Logistics -- Chairs -------------------------------------- Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-suit-chair-slides-00 https://datatracker.ietf.org/meeting/103/materials/slides-103-suit-milestones-00 None WG Update The WG decided not to do an interim meeting after Prague since the architecture and information model drafts had not yet been updated Chairs showed the milestones presented in Prague, not updated in the datatracker yet The timeline for the architecture document is still open, nede to work with the AD to add the milestone Seriazation format milestone date is still open as the WG still have three proposals on the table (was Mar 2018) Manifest information model is a little late (was July 2018) 2) Liaison Statement from ITU-T SG17 - https://datatracker.ietf.org/liaison/1598/ ----------------------------------------------- Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-suit-liaison-statement-from-itu-t-sg17-00 Previous liason statement presented in IETF102 Defined four terms in the previous liason statement WG consensus was that we should re-use terms where it makes sense These have since been included in the architecture draft New liason statement includes the actual SG17document Terminology has changed in this version Device Core -> Firmware Consumer Status Tracker and Communicator are now combined Dave explained the architecture of the roles Status trackers can be inside or outside the device This ITU specification does not define protocols nor formats References the IETF SUIT work References the IOTSU workshop and OneM2M Does however define requirements for each role, and these seem consistent with SUIT requirements Takeshi Takahashi: I am involved with the ITU and author of the liason statement and specification. Agrees with how this was described. Stated a preference to work on formats in the SUIT WG. Hannes volunteered to review the ITU specification Questions to the WG 1. Should we update our architecture to be consistent with the SG 17? Consensus in the room to update. Architecture authors will work on this. 2. Should we add an informative reference to the SG17 doc to say they're conisistent? Consensus to state that the SUIT architecture is "aligned". This will address the risk that the SUIT docs might be done before the SG17 docs are completed. Tak commented that the ITU terminology may still evolve. 3. Do we need to respond? Consensus that there is no need to respond as an ITU participant is present at this meeting. Robin Wilton: Status trackers in the chain may have different functionality depending on the place in the chain. 3) Hackathon Report -- Hannes ----------------------------- Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-suit-hackathon-report-00 Notes from the Hackathon: https://etherpad.tools.ietf.org/p/FUIETF103 Held last weekend in Bangkok 10 participants Lots of different hardware, 6 platforms with a new Renesas board this time Hackathon process 0. Dockerized development environments for Mbed OS & Riot 1. Create Firmnware and Manifest -> JSON -> CBOR 2. Transported to the devices (USB, JTAG, CoAP) Explained the role of the bootloader and location in memory, and how it updates the firmware using a staging area Simplistic approach here, likely more sophisticated in production Lessons learned: First day is always painful - power adapter died, missing a serial-to-usb cable Help is nearby thanks to many people participating, help can be found from others CDDL tool is hell... COSE tool is hell too... experts are nearby SUIT manifest specification needs an update SUIT won the IETF103 hackathon (applause) 4) Suit Architecture -- Authors - draft-ietf-suit-architecture --------------------------------- No Slides May need to add more bootloader text to address multiple types of bootloaders. More WG review is needed of this text. 5) Suit Information Model -- Authors - draft-ietf-suit-information-model -------------------------------------- No Slides Need to get the terminology in sync around the terms in the manifest. Also, align with the SG17 terminology. TODO: Forward and backward references for the security requirements and elements that address the requirement The threat model isn't complete, e.g., no physical attacks Need to address countersigning Gurshabad Grover: What about encrypting the manifest, since it may contain more sensitive information than the firmware itself? Hannes: Both the manufest format and firmware can be encrypted Brendan: There are problems with at-rest encryption of the manifest format, which would prevent it being used in a broadcast environment. There are some workarounds to solve the problem, needs careful consideration. Transport encryption may be sufficient. Hannes: Does it matter if it happens at-rest or in-transit? Carsten: Might be useful to encrypt the manifest, and doesn't understand the broadcast case Carsten; Can use an onion approach that encrypts the inner part, while leaving the outer part unencrypted. The outer part could describe how to get the firmware. Erik Nordmark: Didn't we previously talk about the encryption of firmware. How does this relate to encryption of firmware? Hannes: Encryption of the firmware has been optional. Need to consider how it is sent to the device. There may be privacy issues, which is how that discussion started. 6) Suit Manifest Format -- Authors ---------------------------------- Chairs (Russ) set up the context. The main difference between these documents is the type of encoding. We have two CBOR variations and one custom binary. Need to consider if we want one or several formats. - draft-birkholz-suit-coswid-manifest - Henk Birkholz No Slides Henk explained that this was a proposal, and now it looks to be covered. Intent is to fold this work into draft-moran-suit-manifest. - draft-moran-suit-manifest-03 - Brendan Moran Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-suit-draft-moran-suit-manifest-03-00 Was a comment from Jim Schad on the list that the current proposal for (the digest?) may be too heavy Brendan explain a COSE_Digest solution There are a few more preconditions and predirectives to be defined Questions/comments Dave Waltermire: Why not re-use the IDs from the name registration hash registry? https://www.iana.org/assignments/named-information/named-information.xhtml Brendan: Doesn't see an issue unless it is large Henk: These are small indexes Emmanuel: We are updating our implementation to -03 still. The specification is becoming more complex. Wants to remind the WG that we need to be able to use this manifest even on the smallest devices. Need to have the simplest example. What simplifications could we make, e.g. having a reference to text. Brendan: Showed example 3 from the slide deck again. Fields can be made severable if necessary, although this incurrs encoding overhead. Need to limit how many fields we make severable to help constrained devices. Hannes: All the features that people want come with a price tag. Need to keep in mind what we were trying to accomplish and minimize the mandatory elements. - draft-pagel-suit-manifest-00 - Martin Pagel Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-suit-binary-manifest-format-01 Questions/comments: Hannes: Presentation had two components - what format should we have, CBOR or custom binary?, how many formats should we specify? The other aspect was about the features that we want as a WG. Martin argued that he doesn't see some of the information model as necessary. What is the expectation about including functionality in whatever formats we adopt. Ideally, the semantics can't be different between formats. Martin: The way I look at it is that the (optional) fields are not listed in the format. Some things can be implemented by the installer rather than including them in the manifest. Hannes: Understood that in some cases we don't want to use features. Will bring it to the list. JC: Did you check the size of the manifest? Martin: No, I don't have the specifics on size. Would need to do a typical or minimum size example on the mailing list. Dave: Please make the examples similar to moran-03 Brendan: What does "loaded directly into memory" from the draft? Martin: Straight into memory Brendan: How would you access this? Are you referring to recasting the buffer as a C structure? Martin: Yes Brendan: The C standard clearly defines this as undefined behaviour and it can change between compilers or at any time between versions. Brendan: You still need a parser for this binary format, it just looks a little different Brendan: Who is the primary consumer of the manifest format? We find that the schema is the primary receiver of the information. The validation of the data has to be done regardless of the encoding. Rich: You need to use a standard signature digest anyways, which further negates encoding savings Ming Pei: Could there be devices that can't parse CBOR because it is too constrained Hannes: You need a parser regardless. We started with ASN.1 as that is already being parsed by crypto stacks. We came to the conclusion that we already are parsing CBOR at other places in the IETF stack and thus it is not additional overhead. 7) How many formats should move forward? -- Chairs (Russ) --------------------------------------------------------- Russ: How much are you going to be able to assume that is implementation specific vs. including in the manifest. What needs to be done vs. what is platform specific. This would help us determine how many formats to put forward. Alex Pelov: Let's get one format right. We can add an additional encoding later. Henk: From the list it was pointed out that the WG charter says specifically that it will focus on a firmware update solution and a solution for class 1 devices. Hannes: This can be dealt with using options as in Brendan's presentation. The biggest code size is with the signature algorithms and not with the manifest parsing. Dave Thaler (from participant mic): The question seems to be about what encodings might already be in a device. What is the space overhead is the real question, both the manifest and the code. A device manufacturer wants to minimize the overhead. David: The bootloader is a different environment and a CBOR parser is typically available only at the application layer. Hence, I don't buy the argument that the CBOR library is already available. Rich (From Jabber): Is Martin's proposal addressing industrial IoT? Martin: Yes. Eliot: We see an explosion of formats. I am a bit nervous of the code paths being created. Zach: I don't want to see two different encodings on two different information models. Russ: The authors of the two documents believe their work is inline with the same information model (the information model draft). Zach: I also don't think we should treat this functionality as specific to each MCU. We want to enable more sharing of code among MCUs and OSs. Carlos: We need efficiency and we need to have flexiblity & extensibility. We should limit the number of versions. Brendan: Are we standardizing a format for the header? Are we doing secure boot? Ming: The code size for the crypto is much larger than the code size for the parser. Carsten: Two data points. The size of the CBOR parser can even be lower than Brendan stated if you leave floating point out. Carsten: There is a difference in who's signature we are validating. It depends on the authorization scope of the bootloader. Russ: Are you advocating a specific architectural view? Carsten: I think it's not hard to do the part of CBOR that lives in the bootloader. There are two situations: 1) where you re-sign, and 2) where you use the original signature. David: Regarding the reuse of CBOR please don't say that we are re-using code. I didn't mean this negative. It is good to re-use an already working library for use in a bootloader. 8) Next Steps -- Chairs (Dave) ----------------------- Authors need to update architecture and information model documents Martin has an action item to post numbers similar to those from Brendan Chairs have an action to update the milestones