Minutes interim-2018-suit-01: Mon 07:00
Software Updates for Internet of Things
||Minutes interim-2018-suit-01: Mon 07:00
SUIT Virtual Interim, 2018/02/26
Juan Carlos Zuniga
- Agenda bashing, Logistics -- Chairs (5 min)
- WG status -- Chairs (5 min)
Dave Waltermire welcomed everyone to the newly formed SUIT WG.
The WG then discussed participation at the IETF 101 Hackathon.
Henk, Hannes, and Brendan all reported they would be there for SUIT.
Ari, Carsten, and Hannes all reported they would be there for WISHI.
It was suggested that SUIT and WISHI either share a table or have
adjacent tables, depending on the number of people.
ACTION ITEM (Hannes): WISHI hackathon, colocate - Hannes will setup a
- ITU-T-SG-17-TSB Liaison Statement -- Chairs (10 min)
Dave Thaler led a discussion of the liaison statement received from
ITU-T SG 17. The statement says it is for our information, not a
request for action or a question asking for a response. SG 17 has a
work item in progress that the statement says covers requirements,
architecture, and a high-level update procedure sequence. The WG
interpreted this explanation as not including a detailed protocol.
The liaison statement also explained SG 17s taxonomy of roles from its
document: Device Core, Communicator, Status Tracker, and Firmware
Server. The WG discussed these four roles and they seem to make sense
for IETF to use as well, although "Update Server" is also used by some
IETF drafts (such as the arch draft discussed in the next agenda item)
as a synonym for a Firmware Server. Hannes reported that OMA also has
terminology for various roles.
?: Consider thanking for providing this info
?: Ask for them to keep us up-to-date on any progress
Henk: Consider adopting the terminology
Dave: It would be useful for several SDOs to use the same terminology.
Take this into account when writing our documents. Hannes: OMA has
worked on a device management solution, with a software update
mechanism that is similar to the ITU-T approach. Hannes will post the
OMA terminology WG will provide other terminology from other SDOs Dave
W. will talk with Takahashi about the ITU-T liaison statement. Hannes:
Will you write back thanking them? Dave: We should wait until we have
something to update them on (e.g., adopting a draft). Dave: We need to
talk to other IETFers that are working in the ITU-T on this.
ACTION ITEM (Hannes): report back to the WG on OMAs terminology for
roles ACTION ITEM (anyone): any other WG members please provide other
terminology from other SDOs ACTION ITEM (DaveW): Dave W. will talk with
Takahashi about the ITU-T liaison statement.
- Discussion of proposed work (90 min)
Most of the time was spent on discussion of this document which was
recently updated in response to WG feedback (e.g., to use CBOR/COSE),
and the authors proposed it for adoption by the WG for the architecture
document charter milestone. Brandan and Hannes walked through the
various use cases and architecture components (see slides). Overall
feedback was positive, but the WG provided additional feedback to the
authors. For example, the coverage of counter-signing is lacking,
based on list discussion. The authors agreed to update the document in
the next few days with the feedback from the interim meeting. The
meeting participants believed that the document was a good starting
point, and has sufficient completeness and author cycles to be
considered for WG adoption. The WG understands there was another
architecture document (Nandakumars) but that document is less
comprehensive, has not been updated for some time, and had no
proponents at the interim meeting.
Dave T.: Counter-signing can provide a means for operators to
selectively authorize what software may be deployed. Transport security
can provide further access control to allowed software for deployment.
Carsten: Operators need to control what specific software is allowed to
be deployed Dave T.: Who checks the signature. The communicator? The
device on which the software will be deployed? Brendan: This slide was
not intended to go to this detail Dave T.: Ok. We need to make sure it
is well understood how the manifest fits into transport security and
code signing? Hannes: Do we need to sign the manifest twice by the
developer and operator? We don't have much text on this yet. Dave T.:
There is consenus that we need to support multiple sigantures. Hannes:
We need more text on this. Slide 6: Dave W: Is the hash discussed here
in the signature or a digest of the software. Brendan: The manifest
contains many hashes (e.g., over the software, signature over the
manifest) Hannes: We are talking about the hash in the signature here.
Carsten: Should we treat the contents of the manifest as claims or as
metadata? The device needs to analyze these claims. Henk: A minimum set
of data needs to be required. Hannes: Do we need to change terminology
or make a more fundimental change? Carsten: No change, but we should
think about these as a set of claims as a mental model. Hannes: Ok. We
can try to rephrase in this style to make it easier to understand.
Slide 7: Dave T., Dave W.: This is a simplified architecture. There may
be other, more complex paths. Brenan: The key point here is the notion
of end-to-end security through an untrusted intermediary. ALL:
Consensus that we need more in diagrams to discuss encapsolation of the
firmware in the manifest, second authors, and other components (e.g.,
communicators). Slide 8: Markus: How would you manage the decryption
keys? Hannes: The content decryption key would be included/referenced
in the manifest for the specific device. Dave T.: The device should not
have to download a bunch of information that does not pertain to the
device. The manifest must be decomposable to support this. Brendan:
Providing a URL for the device to lookup its key is a way to support
this. On a USB device, a table can be used to lookup the key for a
device. Dave T.: I am good if this lookup is not burdensom. Hannes: We
need to highlight the issues around these use-scenarios. Any feedback
on the Architecture? Poll: Have you read the architecture? 6 hands
raised Question: Do the authors believe the draft is a good starting
point for WG adoption? Dave W.: We need to ask about other architecture
drafts. We have both draft-moran-suit-architecture-01 and
draft-nandakumar-suit-secfu-solution-arch-00. Chairs: Start the
adoption call after the next version of
draft-moran-suit-architecture-01 is posted on the list to conclude at
the meeting at IETF 101, unless we hear that
draft-nandakumar-suit-secfu-solution-arch-00 is a going concern.
ACTION ITEM (Brendan): Update document to reflect meeting discussion
ACTION ITEM (DaveW): Ping Nandakumar to check the status and intent of
the authors of the other draft ACTION ITEM (Chairs): Start a call for
adoption after that, to conclude during the London IETF meeting.
Only a brief period of time was spent on these due to lack of time. A
quick run-through of two proposals was done, but there was not time for
deep discussion, so further discussion was deferred to the London
meeting and mailing list.