* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Suit Status Pages

Software Updates for Internet of Things (Active WG)
Sec Area: Roman Danyliw, Benjamin Kaduk | 2017-Dec-15 —  

IETF-105 suit minutes

Session 2019-07-24 1000-1200: Viger - Audio stream - suit chatroom


minutes-105-suit-00 minutes

          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
          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
          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.
           - 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
          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
          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
          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
          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
          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
          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
          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
          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
          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.]

Generated from PyHt script /wg/suit/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -