﻿IETF 101 SUIT Working Group in London Monday, 19 March 2017 13:30-15:30 (GMT) Buckingham Session Chairs: Dave Thaler, Dave Waltermire, Russ Housley Note Takers: Ted Lemon, Brian Witten Jabber: xmpp:suit@jabber.ietf.org?join MeetEcho: https://www.meetecho.com/ietf101/suit 1) Agenda bashing, Logistics -- Chairs (5 mins) https://datatracker.ietf.org/meeting/101/materials/slides-101-suit-chairs-slides-00 ----------------------------------------------- 1. Note well, volunteers for note taking, agenda bashing 2. Now chartered as a working group 3. ITU liaison statement, "agreed to monitor the work ITU is doing" 4. Reviewed architecture and manifest drafts, and posted those notes 5. Will report on the Hackathon results 2) Review of charter milestones -- Chairs (10 mins) https://datatracker.ietf.org/meeting/101/materials/slides-101-suit-chairs-slides-00 --------------------------------------------------- Slide 6: Hoping to make progress adopting the architecture document and manifest serialization 3) Hackathon Report -- Hannes Tschofenig (30 mins) https://datatracker.ietf.org/meeting/101/materials/slides-101-suit-ietf-101-suit-hackathon-report-01 -------------------------------------------------- There was a SUIT-related project at the IETF 101 Hackathon, which was announced to the SUIT mail list before the meeting. Contributing to the hackathon were: Markus Gueller from Infineon, Max Groening from Texas Instruments, Hannes Tschofenig from ARM, Brendan Moran (remote) from ARM, Jaime Jiménez from Ericsson, and Alexander Pelov from Acklio. The focus of this effort was to get some early implementation experience to provide feedback to the SUIT WG. The group focused on implementation around the RIOT OS. There was interest in development around MCU Boot, but David from Linaro who works on MCU Boot was not able to attend. Brendan provided input to the group up front. The group worked on a solution using a manifest serialized in CBOR, with use of COSE for signatures. ARM provided K64F hardware for the project. For the effort, the team kept the original "blinky" example in flash, and loaded a new "pseudo-bootloader" into RAM but did not start this loaded code. This is why it was considered a "pseudo-bootloader". This terminology is a departure from what is traditionally called a "bootloader", which is typically a small program in ROM that starts the whole process. There are open questions on how the device uses the image to start, how the firmware is fetched (e.g., USB) if something went wrong, and how greater reliability can be supported using different slots that can be swapped. These questions lead to implementation issues, but are important for overall the overall design. The group needs more participants who work on boot loaders to provide more information to help the SUIT WG to answer these questions. It was acknowledged that more discussion is needed arounnd boot loader architecture, and some dedicated time on this topic needs to be included in a future meeting. A number of lessons were learned during the hackathon: 1. There is a steep learning curve around getting a working development environment setup. 2. The COSE C library has some issues. The effort needs a small crypto library, that utilizes RAM in a way that suitable for a device with ~10KiB RAM. The participants did not find C libraries that implement embedded crypto and digital signature algorithms, so mbedtls was used after some frustration around finding a suitable implementation. More work is needed to expand algorithm support and a mature COSE C library for production use. It would be useful to have other options too. The chairs are interested in finding volunteers willing to write code to address these gaps. No one steped forward during the meeting. 3. The manifest format described by draft-moran-suit-manifest-03 worked well in this early trial. 4. More help is needed around a number of areas including: post quantum crypto algorithms, use of group communication, and multiple signer concepts. It will be valuable to experiment hands-on with these topics to inform Internet-Draft development. Note: Information provided at the end of the slides provide helpful information related to setting up a development environment, including mbed environment, the boot loader written by Max , and other resources. 4a) Architecture draft-zhu-suit-automatic-fu-arch-00 -- Julian Zhu (15 mins) https://datatracker.ietf.org/meeting/101/materials/slides-101-suit-draft-zhu-suit-automatic-fu-arch-00-01 ----------------------------------------------------------- This presentation focused on availability issues related to software updates. The initial discussion focused on the concept of "idle status". Julian addressed this concept as a state where the device is waiting for instructions from a server or is sleeping. The group was confused at first, since many devices are always actively performing some function, which may be sleeping in some designs. The group discussed some examples of when an update might occur. One example discussed focused on the MCU in a car. It was agreed that updating this device during operation might lead to a failure in the car's operation. Instead, the car's driver (user) may want to wait on updating or reseting the MCU until the car was parked. In other examples, the device may periodically poll a server for an available update when it reaches an update window. In yet other cases, a device may spend much of its time sleeping to conserve power. An update in this last case would need to wait until the device wakes up. Slide 5: The discussion focused on 3 modes: client initiated, server initiated, and negotiated updates. The group recognized that these proposed modes might be a good way to frame discussion about when and how an update might occur. The SUIT architecture has to be capable of dealing with multiple existing protocols that vary in how updates are initiated. It might be useful to use this taxonomy in the WG architecture draft. While discussing initiation of updates is important, discussion of failure cases also need to be covered where updates do not go as planned. It must also be noted that specific bootloader implementations and hardware constraints may limit what types of initiation and failure handling methods are possible. The WG needs to figure out how to discuss these dimensions while still being protocol agnostic, since defining a specific protocol is not in the scope of the WG charter. It was suggested that the level of detail on slide 5 is a good start, but the architecture must say enough about protocol use cases to determine what manifest features will be relevant. This will be useful to evaluate manifest proposals. In the end, the group settled on initial terminology around "self-initiated", "initiated by other", and "negotiated" as the starting point for more work. 4b) Architecture draft-moran-suit-architecture-03 -- Hannes Tschofenig (15 mins) https://datatracker.ietf.org/meeting/101/materials/slides-101-suit-draft-moran-suit-architecture-03-00 --------------------------------------------------------------- This presentation started with a discussion of five terms. The terms are related to each other, but they are not all overlapping. The group did not agree on the terminology, and further discussion is needed. It was noted that the Terminology used by the ITU-T is broader than needed for SUIT. It was suggested that the group focus on "state of the art" requirements for the bootloader, including a post-quantum secure digital signature. Hannes is not sure that we know the right answer on "state of the art", and he called for feedback. The manafest structure should allow an attached firmware image as well as independent retrieval of the firmware image. Call for Adoption of draft-moran-suit-architecture -- Chairs (15 mins) ---------------------------------------------------------------------- Dave Thaler sent a review to the list the other day, and he did not see anything there that would block adoption. However, he suggested one or two things the WG would need to do if the Internet-Draft gets adopted. Dave Thaler walked through issues 2-6 from his review email, and most of them led to some discussion. 2. Currently the document assumes public key crypto, and says "Future versions may also describe a symmetric key approach". The WG should decide whether symmetric key support is also required. Brendan: They are definitely needed. We've already got some ideas of where to go with it. Dave Thaler: So it becomes a work item, either in the same document or a new document. Sounds like you're saying it belongs in the same document. There are no objections to that opinion from the authors. 3. The architecture document does not discuss the four roles we discussed in the interim meeting during the liaison statement discussion. It should (modulo any changes we make to the roles). No discussion. 4. The discussion of broadcast discovery is confusing, and the WG probably needs to discuss this. Dave Thaler: The document should cover as little as possible, but enough to motivate requirements later on. Hannes: There are two aspects to this. First, firmware distribution to different devices, could be elaborated on, it is very brief. Also, the use of encryption in the case where the firmware image itself is protect or encrypted with a symmetric key, it should be broadcast distribution-friendly. Dave Thaler: The text is ambiguous as to whether talking about broadcast delivery of manifest or firmware image. Sounds like both, but the text is confusing. 5. The discussion of quantum resistant signatures needs elaboration. Russ: I'm advocating we pick a quantum-resistant signature as the mandatory-to-implement digital signature. Dave Thaler: It will be hard to do later once device is deployed; if a quantum computer is invented that can break current digital signatures, then it will be hard to trust an update. Russ: The transition from SHA-1 to SHA-256 took at least five years. A transition from ECC or RSA-based signatures to a quantum-resistant signature will be a 5-year effort. So if we don't put it in now, there will be devices out there using ECC and RSA algorithms when a quantum computer comes to pass. So, if we want to use crypto that is quantum- resistant, how do we get there from here? Do not want answer to be that we have to physically touch each device. Dave Thaler: The document has short blurb about it. Hannes: The architecture can talk just about high level issues. When it comes to actually using a mechanism the performance of most of them is disastrous. Russ: Not true. Hannes: They are not finalized yet. Russ: That is not true either. In the CFRG, they are working on two hash-based signatures, they have slightly different properties, but they both have very small code footprints, very fast signature validation, but large signature values. Given this application, where the signature size is amortized over the whole firmware load, it is acceptable. Peter Koch: The explanation provided by Russ is great, but is it related to algorithm trust anchor management? Dave Thaler: The point of it being on agenda is to decide whether this is something the WG needs to spend some time on. If we believe it is a requirement, then the architecture needs to motivate, and the manifest format needs to have a way to do it. Peter: We need to spend more text in the draft on this topic, perhaps a paragraph or so. Brendan: One other point, the current draft of the manifest calls out COSE as the signature container, so it seems to me that if we are going to talk about quantum-resistant signatures, correct place would be in the COSE specification. 6. The coverage of counter-signing by the owner/operator is incomplete. Some sections are now good, but some are still wrong because they don't take that into account. Also, one should not assume that the device owner/operator is necessarily the same entity as the network owner/operator. They may or may not be the same. Dave Thaler: The first half is editorial. We should focus on the architecture question. Is it safe to assume that device owner/operator is the same as the network owner/operator? Micheal Richardson: You ask architecture question. To me the question should be: does the device do all of the determination as to what is an acceptable update, or does the device accept updates from only a single entity which is one of the things you mentioned before, which may or may not be the same. Not to say that the manifest may or may not have complicated statements, but the device does not process the manifest until it has been authenticated. We do not have to depend on the devices doing it all. I think it tweedles the question of owner/operator independently. Dave Thaler: We had this discussion at interim meeting, the notion of counter-signing. Author of firmware, and an entity that says that it is appropriate. Is that okay, or is there ever a case where you need three, because the device owner is different from network owner. Micheal: Consider a self-driving car, the owner of the vehicle can say I do not want to update right now, I am going on a trip and I do not want changes to automatically get installed while on the trip. We all have this issue with our laptops; we do not update the day before IETF. Meanwhile, the owner of the vehicle considers it really important. Then we have the Dept. of Transportation that says, "You will not operate your vehicle unless you are at this firmware state". Dave Thaler: Sounds like you're arguing "one or more", not "one or two". Micheal: My real question is not should there be one or four or 10. Is it reasonable for the device to only support one, but offload that decision elsewhere? I would argue that the case of two signatures should always be offloaded, device should only ever have to trust one. Raj Patel: Regarding the question of whether device is owned by the operator, you have scenarios where device is not owned by operator, but any sort of update needs to be authorized by operator. From service perspective is owned by the operator, any firmware update has to be authorized. Network operator has to authorize that firmware, I do not want that firmware to be sent out to my device. Not necessarily a binary situation. Robin Wilton: I do not want an architecture based on the assumption that the operator and network are the same entity. In principle, if you do that, it tends to favor the walled garden model of proprietary IoT deployments, we have learned from previous experience that interests of the end user tend to be better represented once you move beyond that. In practice, it has more to do with trust and network services. The ability of a third party to interpose themselves on the user's behalf between the vendor and the device. Services can broker terms and conditions on behalf of the user. You want that ability for a third party to interpose themselves. I do not see that being favored by model where architecture assumes unitary ownership. Erik Nordmark: Michael brought up few cases, and I do not think it is that complicated. Going on trip example is not about image or the manifest or how they are verified, but about being able to control when they are applied. If there is an outage associated with the update, even for 10 seconds, someone in chain of control might want to say when to apply it. I think that is a piece we can externalize. We can have a more complex relationship with the manifest signer being different from the firmware image signer. The current draft is not sufficiently precise on the language for such cases. This is a real-world case with automakers, suppliers, and other parties like government and safety bodies are involved. The signer can take into account whatever these parties are saying. We can externalize some complex stuff, but There has to be timing pieces. (unknown): I don't think we should assume that they are the same, artificially limiting to one or two signers may not be effective in the long-term. C. Xiong: On a wireless network, we should only support multicast, not broadcast. 5G does not support broadcast. If lots of parties download an update at the same time, it can be harmful. Dave Thaler: We do not want to get into protocol differences between multicast and broadcast, except in so far as whether the manifest needs to include details on the recipients. Dave Thaler: The point of going through those is to be clear about known open issues in the text. We had a call for adoption on the mail list. My personal opinion is that all the things we have talked about can be done by WG, and they are not obstacles to adoption. We have already asked the list, and now we want to ask the people in the meeting room. Do you believe that this document is a good starting point? If you hum "no", I am going to make you say why. If you believe the draft is good starting point, hum now. (lots) If you believe the draft is not the right starting point, hum now. (none) I claim that that is a clear consensus, next version will be a WG Internet-Draft. 5a) Manifest Information Model -- Dave Waltermire https://datatracker.ietf.org/meeting/101/materials/slides-101-suit-chairs-slides-00 --------------- Slide 10: We have milestones for an information model for manifests in addition to the data model. The differences between the information model (IM) and data model (DM) are defined in RFC 3444. IM – abstract data elements, cardinality, optionality, abstract typing, but all at a level which is not implementable DM – defined at a lower level, with sufficient detail for implementation Slide 11: How do we move forward laying out an information model for the manifest? Looking at Section 6 of the current architecture draft, it is providing requirements for an IM. Appendix A6 provides a few additional details and manifest fields. Perhaps as a next step the authors should break these out into an explicit IM. Hannes: What information model language should be used? Currently the figure is a kind of incomplete UML representation. One could argue that UML is a reasonable information model description. Other things could be selected as well. Dave Thaler: English is fine. (unknown): I have seen these information model efforts go sideways when we start to talk about using existing data modeling languages. I have found they tend to go sideways when you go to a data modeling language. Dave Kemp: I have been working on several standards where information models are expressed as tables. Having cardinality, English prose is good at expressing that. Google protobuf has an IDL that is abstract, although ther encoding is fixed. Mays A.: On data models, there has been agreement adopting YML as a language. I am more interested in the relationship between information model and data model. Maybe the document can include one or two examples about how information model relates to the data models. Dave Thaler: Our milestones call for an information model and a serialization, which does not need to be a full data model. Brendan: I am happy with idea of full flow from usability and security requirements through to information model. I am quite happy with taking output of threat analysis and turning that into an information model. Dave Thaler: Section 6 and Section A.6 would be inherently an information model. Maybe that could become the basis for an information model document. Dave Waltermire: I want to take a quick hum. Hum now if you are in favor of converting Section 6 and Appendix A into an information model document, which will be adopted as a WG draft. (significant hum) Hum now for no, which means that we will continue to solicit an information model document using traditional means. (silence) Slide 12: Next major milestone is adopt an initial manifest serialization format document, with the goal of it being ready for the IESG in November. 5b) Manifest Format -- Brendan Moran (30 mins) https://datatracker.ietf.org/meeting/101/materials/slides-101-suit-draft-moran-suit-manifest-03-00 ----------------------------------- Slide 2: Usability and Threat Model: criteria are in Appendix A. Slide 4: Manifest Encoding: redrafted manifest format in CBOR and COSE. Rest of slides: Use of CBOR maps and CDDL Dave Thaler: The timestamp is controversial because it might require a clock. Brett Jordan: Are we going to call out what kind of timestamp? Brendan: It uses UNIX timestamp. It can avoid a real-time clock. Dave Thaler: That will work as long as not sending more than one update per second. Also, it is only a clock from the sender’s perspective. From the receiver’s perspective, it is just a number you compare with other numbers received. Henk: I totally get that time is monotonically increasing, but maybe it is little bit complicated to use time. Please do not use time. (unknown): I think we should just say monotonically incrementing number, much more straightforward and safe. Henk: I am seeking clarification on conditions and directives. Brendan: The intent here is that you match all conditions before applying any directives. Henk: Okay, maybe make it less complicated or align with the ECA. David Waltermire: What is the “that” you would be aligning with? Henk: Maybe a YANG automation control framework using ECA. David Waltermire: Please send pointers to some of these documents to the list. Hannes: Carsten had suggested to use the term "claims" here, but in essence the basic idea is simple, based on description in the architecture document, we want the ability to express that an update is only applicable to a certain device. In this version, the condition is used for that. Four conditions have been proposed so far that nail down which devices the update is for. Henk: Please do not call it a condition. It is a description. Brendan: One is the minimum bashery level that is required to apply the update. Henk: One might be "best before" a given date. Rick Taylor: I think the word we are looking for is "prerequisite." Brendan: That sounds right to me. Dave Thaler: If you believe these are conditions to be checked by device itself, then I do not think device can check "best before" that without a real-time clock. So either say "best before" is okay to ignore, or say this is a reason to use a different protocol. Micheal Richardson: You' are using CBOR/CDDL, so you need extensions too. Brendan: The current implementation is an array. Micheal: You can still add things to array. If you are saying that there is the order in the array, then I think that is a mistake. Henk: Relaying a comment: Can one manifest rely on other manifests? The dependency is another manifest, not some random resource. Markus: Is everybody happy with CBOR and COSE? It would be very good to get some libraries or code running on constrained devices. It would be very important for implementers to get a feeling of how this works. David Waltermire: Please come see the chairs after the session if you want to work on that. Presentation to Outgoing Security Area Director, Kathleen Moriarty ------------------------------------------------------------------ Russ Housley invited Kathleen Moriarty to the front of the room... In the plenary on Wednesday, Kathleen will be stepping out of her role as a Security Area Director. To thank her for her part in starting this group, Russ presented a "SUITable" a gift.