Skip to main content

Minutes IETF105: suit
minutes-105-suit-00

Meeting Minutes Software Updates for Internet of Things (suit) WG
Title Minutes IETF105: suit
State Active
Other versions plain text
Last updated 2019-08-12

minutes-105-suit-00
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.]