SUIT Working Group at IETF 105 in Montreal, CA WEDNESDAY, 24 July 2019 at 10:00 Jabber: xmpp:suit@jabber.ietf.org?join MeetEcho: https://www.meetecho.com/ietf105/suit Etherpad: https://etherpad.ietf.org/p/notes-ietf-105-suit WG Charis: Dave T., Dave W., and Russ Note Takers: Sorin and Robin Jabber Scribe: Tero Agenda ------ 1) Agenda bashing, Logistics -- Chairs 2) Hackathon Report -- Emmanuel Baccelli 3) SUIT Architecture -- Authors - draft-ietf-suit-architecture 4) SUIT Information Model -- Authors - draft-ietf-suit-information-model 5) SUIT Manifest Format -- Authors - Call for adoption results - draft-moran-suit-manifest 6) Next Steps -- Chairs Meeting ------- 1) Agenda bashing, Logistics -- Chairs Reminder of the Note Well. Status report on documents: - SUIT Architecture - WG Last Call got decent feedback. - Information Model - Updated after IETF 104. - SUIT Manifest - Ongoing WG Call for Adoption for manifest using CBOR; chairs declare that there is consensus to adopt the draft. Milestones: - The March 2018 milestone regarding the adoption of manifest serialization format is quite tardy, but we expect to see a document to address this topic soon. 2) SUIT Architecture - draft-ietf-suit-architecture -- Authors Hannes presented the architecture draft. The document is close to completion but there is stil an issue between the SUIT WG and ITU-T work in same area relating to behaviour of Status Tracker component. There is an email from Brendon raising the one issue needs discusion. For the most part, manifest monitoring is done before updating the firmware. Components in the device can be cascaded, depending on the architecture of the device. Can be instructed by on-network status tracker. Dave T: Is it done inside the devices status tracker as a separate entity, device with multiple MCUs? Brendon: IETF should not try to too hard to update. Keith Moore: In my opinion, the architecture anticipated by ITU-T is a poor one as it does not adequately cover the variety of scenarios required by different IoT devices, based on differences in device function, connectivity, available power, and so on. IETF should not try too hard to align with it, other than to avoid conflicting / confusing terminology. What do we need for alignment in the document? Often happens that the device talks to server upfront to determine whether an update is pending. Takahashi (editor of ITU-T document): IETF should not put too much effort to align, and ITU-T tried to address the issue. Chairs: It is good that we have common participation in both SUIT and ITU-T SG17. It sounds like the ITU-T editors will work to align their document with the SUIT Architecture. Device management: the device registers with the server, checking status of device. What is running currently? What needs to be updated? The server could trigger the updates. It is a complex process, and it is not clear how much should really described in the document. It is useful to know how they work today. The authors can propose some text this week for the section, taking some of the nested aspects as they are deployed today. Chairs: The normative part is the manufest to be kept at high level. Keep it at high level and as flex as possible. Chairs: WG Last Call can be used resolve these comments. Hannes: Will update the document this week, and requests review with a view to finalizing it. Dave T.: This group's normative work is on the manifest, so we should avoid working on the status tracking function that does not relate specifically to the manifest. Russ: Intent is that these comments are the last step before WG Last Call, so comment now! ITU-T architectural model appears to allow for multiple status trackers, and their status trackers can both interact with each other and initiate firmware updates, rather than just monitoring firmware / device status. 3) SUIT Information Model - draft-ietf-suit-information-model -- Authors Brendon presented remotely. Lot of changes in the information model, but most are replacing numerical values with names. ARM security found a hole in the protocol, and the solution is to digest half of the firmware and use that as a firmware digest. Recommend inclusion of a new usecase use of delegation server. Chairs: Is more work needed or are we ready for WG Last Call? Brendan: Barring any further commentary, I think it is done. Chairs: We will start last call after this meeting. 4) SUIT Manifest Format - draft-moran-suit-manifest -- Authors Brendon presented remotely. An overview of change from descriptive to behavioral. IoT updates should be easy, but it is not due to multiple actors and multiple phases in the process. Hannes presented locally. We seen wide range of IoT devices. Single MCU with single firmware is good, but we also need to support more complex devices. Many different hardware architectures that require different treatment, different split between secure and untrusted space. Some devices update directly from flash. Where do you copy the software updates? The answer differs depending on the device hardware architecture. And, there may be different keys for different device models. Some of this is covered in the architecture document. Different roles and actors may be involved in the upgrade process. Who needs to aprove the updates? Maybe these actors need to be mentioned in the manifest documents. Hannes: The technical design for updates has to accommodate many legitimate non-technical factors, including certification of medical devices. Many devices have a simple basic micro-controller, and nice to work in a thin layout, but in many devices are made of lots of components that need to interact. There is common practice when the device has radio, like bluetooth or Wi-Fi,to manage the updates for all components. Manufacturers often "buy in" components for different radio technologies, so SUIT has to take into account the fact that different manufacturers' components may be present within a device, hence the need for a detailed manifest and flexibility in processing updates. Security Considerations have been discussed at the end of last year and the beginning of this year based on hackathon experiences. Thaler proposed a different method to optimize for different devices: copy image from server side to the device, use one format for all, but have a simple answer. Brandon: Need one format, not similar formats. Complexity in update formats leads to complexity in the parser; IoT devices (and their bootloaders) are constrained, so simplicity of parsers is key, and therefore update primitives (operations, data structures) need to be kept as simple and consistent as possible. This is reflected in the changes from -04 to -05. That is, common elements have been moved into a nested bstr (byte string), and the encoding of command sequences has been updated tso that a single SUIT_Command is a pairs of {integer, argument}. Hannes: Need a simple format to keep bootloader fast and simple, but we also want secure boot. Brandon: Most updates use similar operations; it gets copied from one firmware package to another. Check properties of the device, and other devices to use same fundamental operations. Perhaps it is controversial; an update consumer does not care what the update does, but cares how to install the new code. In the current model, information that is used outside the manifest processor includes the structure version number and sequence number. Next, there are dependencies and common, which are used setup the environment. The current draft has 6 command sequences. Summary changes in the -04 revision: - moved to a nested form consistent; - everything in the manifest is wrapped in a structure except for the number version; - common sequence is referenced by all the other sequences; - fixed size making sequencer simpler; - {integer, argument} pair encoded in a flat way; - changed handling of optional sequences: -- Was: conditional sequences, no explicit structure; -- Now: "try-each" list of conditional sequences, but one must pass. - add support for COSE encryption of manifest; - added a "swap" directive to replace an image with a single directive. Discussion after IETF 104 on the mail list includes discussion that some digest algorithms absolutely not supported, but others should be supported. Russ: I just want to confirm, draft-moran-suit-behavioural-manifest was not updated, but draft-moran-suit-manifest was updated. The two drafts were merged? Brandon : Yes. Russ: draft-moran-suit-manifest currently marked as only informational; it should be marked for standards track. Hannes: At the TEEP WG, there was a suggestion for an update based on the Hackathon. Would there be interest to do a tutorial before the hackathon at the next IETF. Better to know if there is interest in the tutorial to know what to bring to the next hackathon. Chairs: We need some training, maybe not during the hackathon. Whichever folks prefer. Roman: Would start to encrypt some threads and encourage structure. Keith Moore: This all seems needlessly baroque to me. Update instructions in particular seem fairly likely to be platform specific. Dave T: Short report between TEEP and SUIT. Brandon gave at the interim a chracterization. TEEP will depend on the SUIT manifest for firmware updates. TEEP is not necessarily firmware. The manifest format is not constrained to frimware only. Hannes agreed to prepare a draft of normative requirements to fulfill the needs of the TEEP use cases. Russ: Does the overlap between TEEP and SUIT create new milestones or dependencies? Dave T: TEEP and OTRP expect SUIT manifest to be completed before it is needed by OTRP would need to make use of it, so TEEP does not have a concern about that. Ming Pai: TEEP decided to adopt the SUIT manifest. TEEP wants to leverage SUIT scope, but how much TEEP should adopt. Dave T: TEEP will not expect to need to resolve circular conditions in updates; it will depend on SUIT to have solved that problem. Brendon: SUIT address the sequence question and allows different signers. Manifest has a way to handle dependencies, which I tried to explain. There was an open question regarding personalization data for individual devices. Also, the point at which a trust anchor update ia made. Ming: Trust anchor is different than configuration data, which is more related to manifest. One is a question of data structure definition, the other is a question of deciding who you trust. Hannes: Should add use cases pointing to TEEP document, including personalization data. Ming: This is outside the use cases scope. Chairs: We need to continue the discussion on the mail list. Need to make sure information is shared between TEEP and SUIT (good thing the groups have a chair in common). One implementer has issues with the current manifest requirements. Needs a better understanding of "simple". Randy Turner: What do folks mean by the word "simple"? My rough calculation I'll need: COSE, CBOR, hashing, ... would be nice if any hackathon could aim to produce an output saying what components and resources were needed to get this working. For example, my company has sensors with 4k RAM. Brandon: Agree getting the sizes down is a priority. CBOR implementation doesn't need to be an existing library. 200 lines for CBOR and 600 lines for hash. It is tough to reduce, but you don't have to use an existing COSE/CBOR library, and size reductions there can be achieved. However, SHA-256 hash implementation is hard to reduce, so in general, fitting trusted updates into a 4K to 8K device will be tough. Benjamin: The task is to put code in bootloader; it should be limited size. Hannes: At hackathon there was an effort for addresing this, at least in part. Also, the COSE implementation do not need all the details, but only the parts you need. One of COSE open source implementations is not production ready; a paper provides the information. The bigger chunks are for crypto algorithms. If you use bigger keys, the processing takes longer. There is a paper that will soon appear in IEEE. Benjamin: More and more often the SHA-256 is provided in the hardware, shifting from software to hardware, een for Class 1 devices. Hannes: Can move stuff between hardware and software. Brandon: I assume devices with crypto accelerators start at 128K. Keith Moore: I am concerned about how many different things an implementor has to know and understand in order to build an implementation that is appropriate to their product? Some things like hashes and signatures are unavoidable. But encoding really needs to be as simple as possible, the manifest needs to be as simple as possible, encoding behavior strikes me as making things too complex for some use cases. Brendon: I agree that it needs to be kept simple, and I suspect it may turn out to be simpler than you expect; we also need to provide a few example cases for different classes of devices to show an implementation. Brandon: What needs to be demonstrated? It turns out much simpler but needs to provide examples of such devices. Hannes' work has produced some figures for the memory/performance implications of choosing different software/crypto stacks. Published through IEEE, but open access. [ Link provided by Hannes: Secure Firmware Updates for Constrained IoT Devices Using Open Standards: A Reality Check https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8725488 ] Hannes: Give a better wy to take size down. Randy Turner: Great if we can see some iplementation. Hannes agreed to provide outputs from last hackathon. Roman: talk about hackathon, it is good to update the wiki page. Chairs: If people have links to implementations, please contribute them either directly to the wiki or by sending to the chairs. [ The SUIT wiki is here: https://trac.ietf.org/trac/suit/wiki ] Roman: Please relate any implementations to specific draft and version. 5) Next Steps -- Chairs Chairs: We talked updating milestones. Chairs: We will start WG Last Call on the information model follwing this meeting. We will allow little extra time to account for travel from IETF and vacation season. Roman: The milestones is about giving other people an opportunity to chip in even if they weren't in the room... so it is as much a marketing tool as a matter of project management. AI: Since complete WG Last Call on the architecture document, we need one more revision for status tracker. Russ: Need to see if we need an interim before next IETF or arrive at Singapore early and do the tutorial there. Hannes will drive the conversation on the mail list. [Meeting adjourned.]