Minutes IETF103: suit
minutes-103-suit-01

SUIT Working Group at IETF 103 in Bankok, TH
THURSDAY, 8 November 2018 at 0900

Scribes: Zach Shelby

Agenda
------
1) Agenda bashing, Logistics -- Chairs
--------------------------------------
Slides:
https://datatracker.ietf.org/meeting/103/materials/slides-103-suit-chair-slides-00
        https://datatracker.ietf.org/meeting/103/materials/slides-103-suit-milestones-00

None

WG Update

The WG decided not to do an interim meeting after Prague since the architecture
and information model drafts had not yet been updated Chairs showed the
milestones presented in Prague, not updated in the datatracker yet The timeline
for the architecture document is still open, nede to work with the AD to add
the milestone Seriazation format milestone date is still open as the WG still
have three proposals on the table (was Mar 2018) Manifest information model is
a little late (was July 2018)

2) Liaison Statement from ITU-T SG17
   - https://datatracker.ietf.org/liaison/1598/
-----------------------------------------------
Slides:
https://datatracker.ietf.org/meeting/103/materials/slides-103-suit-liaison-statement-from-itu-t-sg17-00

Previous liason statement presented in IETF102
Defined four terms in the previous liason statement
WG consensus was that we should re-use terms where it makes sense
These have since been included in the architecture draft
New liason statement includes the actual SG17document
Terminology has changed in this version
Device Core -> Firmware Consumer
Status Tracker and Communicator are now combined
Dave explained the architecture of the roles
Status trackers can be inside or outside the device
This ITU specification does not define protocols nor formats
References the IETF SUIT work
References the IOTSU workshop and OneM2M
Does however define requirements for each role, and these seem consistent with
SUIT requirements Takeshi Takahashi: I am involved with the ITU and author of
the liason statement and specification. Agrees with how this was described.
Stated a preference to work on formats in the SUIT WG. Hannes volunteered to
review the ITU specification Questions to the WG 1. Should we update our
architecture to be consistent with the SG 17? Consensus in the room to update.
Architecture authors will work on this. 2. Should we add an informative
reference to the SG17 doc to say they're conisistent? Consensus to state that
the SUIT architecture is "aligned". This will address the risk that the SUIT
docs might be done before the SG17 docs are completed. Tak commented that the
ITU terminology may still evolve. 3. Do we need to respond? Consensus that
there is no need to respond as an ITU participant is present at this meeting.
Robin Wilton: Status trackers in the chain may have different functionality
depending on the place in the chain.

3) Hackathon Report -- Hannes
-----------------------------
Slides:
https://datatracker.ietf.org/meeting/103/materials/slides-103-suit-hackathon-report-00
Notes from the Hackathon: https://etherpad.tools.ietf.org/p/FUIETF103

Held last weekend in Bangkok
10 participants
Lots of different hardware, 6 platforms with a new Renesas board this time
Hackathon process
0. Dockerized development environments for Mbed OS & Riot
1. Create Firmnware and Manifest -> JSON -> CBOR
2. Transported to the devices (USB, JTAG, CoAP)
Explained the role of the bootloader and location in memory, and how it updates
the firmware using a staging area Simplistic approach here, likely more
sophisticated in production Lessons learned: First day is always painful -
power adapter died, missing a serial-to-usb cable Help is nearby thanks to many
people participating, help can be found from others CDDL tool is hell... COSE
tool is hell too... experts are nearby SUIT manifest specification needs an
update SUIT won the IETF103 hackathon (applause)

4) Suit Architecture --  Authors
   - draft-ietf-suit-architecture
---------------------------------
No Slides
May need to add more bootloader text to address multiple types of bootloaders.
More WG review is needed of this text.

5) Suit Information Model -- Authors
   - draft-ietf-suit-information-model
--------------------------------------
No Slides
Need to get the terminology in sync around the terms in the manifest. Also,
align with the SG17 terminology. TODO: Forward and backward references for the
security requirements and elements that address the requirement The threat
model isn't complete, e.g., no physical attacks Need to address countersigning
Gurshabad Grover: What about encrypting the manifest, since it may contain more
sensitive information than the firmware itself? Hannes: Both the manufest
format and firmware can be encrypted Brendan: There are problems with at-rest
encryption of the manifest format, which would prevent it being used in a
broadcast environment. There are some workarounds to solve the problem, needs
careful consideration. Transport encryption may be sufficient. Hannes: Does it
matter if it happens at-rest or in-transit? Carsten: Might be useful to encrypt
the manifest, and doesn't understand the broadcast case Carsten; Can use an
onion approach that encrypts the inner part, while leaving the outer part
unencrypted. The outer part could describe how to get the firmware. Erik
Nordmark: Didn't we previously talk about the encryption of firmware. How does
this relate to encryption of firmware? Hannes: Encryption of the firmware has
been optional. Need to consider how it is sent to the device. There may be
privacy issues, which is how that discussion started.

6) Suit Manifest Format -- Authors
----------------------------------
Chairs (Russ) set up the context.
The main difference between these documents is the type of encoding. We have
two CBOR variations and one custom binary. Need to consider if we want one or
several formats.

   - draft-birkholz-suit-coswid-manifest - Henk Birkholz

No Slides
Henk explained that this was a proposal, and now it looks to be covered. 
Intent is to fold this work into draft-moran-suit-manifest.

   - draft-moran-suit-manifest-03 - Brendan Moran
   Slides:
   https://datatracker.ietf.org/meeting/103/materials/slides-103-suit-draft-moran-suit-manifest-03-00

Was a comment from Jim Schad on the list that the current proposal for (the
digest?) may be too heavy Brendan explain a COSE_Digest solution There are a
few more preconditions and predirectives to be defined Questions/comments Dave
Waltermire: Why not re-use the IDs from the name registration hash registry?
https://www.iana.org/assignments/named-information/named-information.xhtml
Brendan: Doesn't see an issue unless it is large Henk: These are small indexes
Emmanuel: We are updating our implementation to -03 still. The specification is
becoming more complex. Wants to remind the WG that we need to be able to use
this manifest even on the smallest devices. Need to have the simplest example.
What simplifications could we make, e.g. having a reference to text. Brendan:
Showed example 3 from the slide deck again. Fields can be made severable if
necessary, although this incurrs encoding overhead. Need to limit how many
fields we make severable to help constrained devices. Hannes: All the features
that people want come with a price tag. Need to keep in mind what we were
trying to accomplish and minimize the mandatory elements.

   - draft-pagel-suit-manifest-00 - Martin Pagel
   Slides:
   https://datatracker.ietf.org/meeting/103/materials/slides-103-suit-binary-manifest-format-01

Questions/comments:
Hannes: Presentation had two components - what format should we have, CBOR or
custom binary?, how many formats should we specify? The other aspect was about
the features that we want as a WG. Martin argued that he doesn't see some of
the information model as necessary. What is the expectation about including
functionality in whatever formats we adopt. Ideally, the semantics can't be
different between formats. Martin: The way I look at it is that the (optional)
fields are not listed in the format. Some things can be implemented by the
installer rather than including them in the manifest. Hannes: Understood that
in some cases we don't want to use features. Will bring it to the list. JC: Did
you check the size of the manifest? Martin: No, I don't have the specifics on
size. Would need to do a typical or minimum size example on the mailing list.
Dave: Please make the examples similar to moran-03 Brendan: What does "loaded
directly into memory" from the draft? Martin: Straight into memory Brendan: How
would you access this? Are you referring to recasting the buffer as a C
structure? Martin: Yes Brendan: The C standard clearly defines this as
undefined behaviour and it can change between compilers or at any time between
versions. Brendan: You still need a parser for this binary format, it just
looks a little different Brendan: Who is the primary consumer of the manifest
format? We find that the schema is the primary receiver of the information. The
validation of the data has to be done regardless of the encoding. Rich: You
need to use a standard signature digest anyways, which further negates encoding
savings Ming Pei: Could there be devices that can't parse CBOR because it is
too constrained Hannes: You need a parser regardless. We started with ASN.1 as
that is already being parsed by crypto stacks. We came to the conclusion that
we already are parsing CBOR at other places in the IETF stack and thus it is
not additional overhead.

7) How many formats should move forward? -- Chairs (Russ)
---------------------------------------------------------

Russ: How much are you going to be able to assume that is implementation
specific vs. including in the manifest. What needs to be done vs. what is
platform specific. This would help us determine how many formats to put
forward. Alex Pelov: Let's get one format right. We can add an additional
encoding later. Henk: From the list it was pointed out that the WG charter says
specifically that it will focus on a firmware update solution and a solution
for class 1 devices. Hannes: This can be dealt with using options as in
Brendan's presentation. The biggest code size is with the signature algorithms
and not with the manifest parsing. Dave Thaler (from participant mic): The
question seems to be about what encodings might already be in a device. What is
the space overhead is the real question, both the manifest and the code. A
device manufacturer wants to minimize the overhead. David: The bootloader is a
different environment and a CBOR parser is typically available only at the
application layer. Hence, I don't buy the argument that the CBOR library is
already available. Rich (From Jabber): Is Martin's proposal addressing
industrial IoT? Martin: Yes. Eliot: We see an explosion of formats. I am a bit
nervous of the code paths being created. Zach: I don't want to see two
different encodings on two different information models. Russ: The authors of
the two documents believe their work is inline with the same information model
(the information model draft). Zach: I also don't think we should treat this
functionality as specific to each MCU. We want to enable more sharing of code
among MCUs and OSs. Carlos: We need efficiency and we need to have flexiblity &
extensibility. We should limit the number of versions. Brendan: Are we
standardizing a format for the header? Are we doing secure boot? Ming: The code
size for the crypto is much larger than the code size for the parser. Carsten:
Two data points. The size of the CBOR parser can even be lower than Brendan
stated if you leave floating point out. Carsten: There is a difference in who's
signature we are validating. It depends on the authorization scope of the
bootloader. Russ: Are you advocating a specific architectural view? Carsten: I
think it's not hard to do the part of CBOR that lives in the bootloader. There
are two situations: 1) where you re-sign, and 2) where you use the original
signature. David: Regarding the reuse of CBOR please don't say that we are
re-using code. I didn't mean this negative. It is good to re-use an already
working library for use in a bootloader.

8) Next Steps -- Chairs (Dave)
-----------------------

Authors need to update architecture and information model documents
Martin has an action item to post numbers similar to those from Brendan
Chairs have an action to update the milestones