Minutes IETF101: suit
minutes-101-suit-01

IETF 101 SUIT Working Group in London
Monday, 19 March 2017
13:30-15:30 (GMT) Buckingham


Session Chairs: Dave Thaler, Dave Waltermire, Russ Housley
Note Takers: Ted Lemon, Brian Witten
Jabber: xmpp:suit@jabber.ietf.org?join
MeetEcho: https://www.meetecho.com/ietf101/suit


1) Agenda bashing, Logistics -- Chairs (5 mins)
https://datatracker.ietf.org/meeting/101/materials/slides-101-suit-chairs-slides-00
-----------------------------------------------
1. Note well, volunteers for note taking, agenda bashing
2. Now chartered as a working group
3. ITU liaison statement, "agreed to monitor the work ITU is doing"
4. Reviewed architecture and manifest drafts, and posted those notes
5. Will report on the Hackathon results


2) Review of charter milestones -- Chairs (10 mins)
https://datatracker.ietf.org/meeting/101/materials/slides-101-suit-chairs-slides-00
---------------------------------------------------
Slide 6: Hoping to make progress adopting the architecture document
   and manifest serialization


3) Hackathon Report -- Hannes Tschofenig (30 mins)
https://datatracker.ietf.org/meeting/101/materials/slides-101-suit-ietf-101-suit-hackathon-report-01
--------------------------------------------------
There was a SUIT-related project at the IETF 101 Hackathon, which was
announced to the SUIT mail list before the meeting.  Contributing to
the hackathon were:

   Markus Gueller from Infineon,
   Max Groening from Texas Instruments,
   Hannes Tschofenig from ARM,
   Brendan Moran (remote) from ARM,
   Jaime Jiménez from Ericsson, and
   Alexander Pelov from Acklio.

The focus of this effort was to get some early implementation experience
to provide feedback to the SUIT WG.  The group focused on implementation
around the RIOT OS.  There was interest in development around MCU Boot,
but David from Linaro who works on MCU Boot was not able to attend.

Brendan provided input to the group up front.  The group worked on a
solution using a manifest serialized in CBOR, with use of COSE for
signatures.  ARM provided K64F hardware for the project.  For the
effort, the team kept the original "blinky" example in flash, and
loaded a new "pseudo-bootloader" into RAM but did not start this
loaded code.  This is why it was considered a "pseudo-bootloader".
This terminology is a departure from what is traditionally called a
"bootloader", which is typically a small program in ROM that starts
the whole process.  There are open questions on how the device uses the
image to start, how the firmware is fetched (e.g., USB) if something
went wrong, and how greater reliability can be supported using different
slots that can be swapped.  These questions lead to implementation
issues, but are important for overall the overall design. The group
needs more participants who work on boot loaders to provide more
information to help the SUIT WG to answer these questions. It was
acknowledged that more discussion is needed arounnd boot loader
architecture, and some dedicated time on this topic needs to be
included in a future meeting.

A number of lessons were learned during the hackathon:
1. There is a steep learning curve around getting a working development
   environment setup.
2. The COSE C library has some issues.  The effort needs a small crypto
   library, that utilizes RAM in a way that suitable for a device with
   ~10KiB RAM.  The participants did not find C libraries that implement
   embedded crypto and digital signature algorithms, so mbedtls was used
   after some frustration around finding a suitable implementation.
   More work is needed to expand algorithm support and a mature COSE C
   library for production use.  It would be useful to have other options
   too.  The chairs are interested in finding volunteers willing to
   write code to address these gaps.  No one steped forward during the
   meeting.
3. The manifest format described by draft-moran-suit-manifest-03 worked
   well in this early trial.
4. More help is needed around a number of areas including: post quantum
   crypto algorithms, use of group communication, and multiple signer
   concepts.  It will be valuable to experiment hands-on with these
   topics to inform Internet-Draft development.

Note: Information provided at the end of the slides provide helpful
information related to setting up a development environment, including
mbed environment, the boot loader written by Max , and other resources.


4a) Architecture
draft-zhu-suit-automatic-fu-arch-00 -- Julian Zhu (15 mins)
https://datatracker.ietf.org/meeting/101/materials/slides-101-suit-draft-zhu-suit-automatic-fu-arch-00-01
-----------------------------------------------------------
This presentation focused on availability issues related to software
updates.  The initial discussion focused on the concept of "idle
status".  Julian addressed this concept as a state where the device
is waiting for instructions from a server or is sleeping.  The group
was confused at first, since many devices are always actively
performing some function, which may be sleeping in some designs.
The group discussed some examples of when an update might occur.
One example discussed focused on the MCU in a car.  It was agreed
that updating this device during operation might lead to a failure in
the car's operation.  Instead, the car's driver (user) may want to
wait on updating or reseting the MCU until the car was parked.  In
other examples, the device may periodically poll a server for an
available update when it reaches an update window.  In yet other
cases, a device may spend much of its time sleeping to conserve
power.  An update in this last case would need to wait until the
device wakes up.

Slide 5: The discussion focused on 3 modes: client initiated,
server initiated, and negotiated updates.  The group recognized that
these proposed modes might be a good way to frame discussion about
when and how an update might occur.  The SUIT architecture has to be
capable of dealing with multiple existing protocols that vary in how
updates are initiated.  It might be useful to use this taxonomy in
the WG architecture draft.  While discussing initiation of updates is
important, discussion of failure cases also need to be covered where
updates do not go as planned.  It must also be noted that specific
bootloader implementations and hardware constraints may limit what
types of initiation and failure handling methods are possible.  The
WG needs to figure out how to discuss these dimensions while still
being protocol agnostic, since defining a specific protocol is not in
the scope of the WG charter.  It was suggested that the level of
detail on slide 5 is a good start, but the architecture must say
enough about protocol use cases to determine what manifest features
will be relevant.  This will be useful to evaluate manifest proposals.
In the end, the group settled on initial terminology around
"self-initiated", "initiated by other", and "negotiated" as the
starting point for more work.


4b) Architecture
draft-moran-suit-architecture-03 -- Hannes Tschofenig (15 mins)
https://datatracker.ietf.org/meeting/101/materials/slides-101-suit-draft-moran-suit-architecture-03-00
---------------------------------------------------------------
This presentation started with a discussion of five terms.  The terms
are related to each other, but they are not all overlapping.  The group
did not agree on the terminology, and further discussion is needed.  It
was noted that the Terminology used by the ITU-T is broader than needed
for SUIT.

It was suggested that the group focus on "state of the art" requirements
for the bootloader, including a post-quantum secure digital signature.
Hannes is not sure that we know the right answer on "state of the art",
and he called for feedback.

The manafest structure should allow an attached firmware image as well
as independent retrieval of the firmware image.


Call for Adoption of draft-moran-suit-architecture -- Chairs (15 mins)
----------------------------------------------------------------------
Dave Thaler sent a review to the list the other day, and he did not see
anything there that would block adoption.  However, he suggested one or
two things the WG would need to do if the Internet-Draft gets adopted.
Dave Thaler walked through issues 2-6 from his review email, and most of
them led to some discussion.

2. Currently the document assumes public key crypto, and says "Future
versions may also describe a symmetric key approach".  The WG should
decide whether symmetric key support is also required.

Brendan: They are definitely needed.   We've already got some ideas of
where to go with it.

Dave Thaler: So it becomes a work item, either in the same document or
a new document.   Sounds like you're saying it belongs in the same
document.

There are no objections to that opinion from the authors.

3. The architecture document does not discuss the four roles we
discussed in the interim meeting during the liaison statement
discussion.  It should (modulo any changes we make to the roles).

No discussion.

4. The discussion of broadcast discovery is confusing, and the WG
probably needs to discuss this.

Dave Thaler: The document should cover as little as possible, but enough
to motivate requirements later on.

Hannes: There are two aspects to this.  First, firmware distribution to
different devices, could be elaborated on, it is very brief.   Also,
the use of encryption in the case where the firmware image itself is
protect or encrypted with a symmetric key, it should be broadcast
distribution-friendly.

Dave Thaler: The text is ambiguous as to whether talking about broadcast
delivery of manifest or firmware image.   Sounds like both, but the text
is confusing.

5. The discussion of quantum resistant signatures needs elaboration.

Russ: I'm advocating we pick a quantum-resistant signature as the
mandatory-to-implement digital signature.

Dave Thaler: It will be hard to do later once device is deployed; if a
quantum computer is invented that can break current digital signatures,
then it will be hard to trust an update.

Russ: The transition from SHA-1 to SHA-256 took at least five years.  A
transition from ECC or RSA-based signatures to a quantum-resistant
signature will be a 5-year effort.  So if we don't put it in now, there
will be devices out there using ECC and RSA algorithms when a quantum
computer comes to pass.  So, if we want to use crypto that is quantum-
resistant, how do we get there from here?   Do not want answer to be
that we have to physically touch each device.

Dave Thaler: The document has short blurb about it.

Hannes: The architecture can talk just about high level issues.   When
it comes to actually using a mechanism the performance of most of them
is disastrous.

Russ: Not true.

Hannes: They are not finalized yet.

Russ: That is not true either.  In the CFRG, they are working on two
hash-based signatures, they have slightly different properties, but
they both have very small code footprints, very fast signature
validation, but large signature values.  Given this application, where
the signature size is amortized over the whole firmware load, it is
acceptable.

Peter Koch: The explanation provided by Russ is great, but is it
related to algorithm trust anchor management?

Dave Thaler: The point of it being on agenda is to decide whether this
is something the WG needs to spend some time on.  If we believe it is a
requirement, then the architecture needs to motivate, and the manifest
format needs to have a way to do it.

Peter: We need to spend more text in the draft on this topic, perhaps
a paragraph or so.

Brendan: One other point, the current draft of the manifest calls out
COSE as the signature container, so it seems to me that if we are going
to talk about quantum-resistant signatures, correct place would be in
the COSE specification.

6. The coverage of counter-signing by the owner/operator is incomplete.
Some sections are now good, but some are still wrong because they don't
take that into account.  Also, one should not assume that the device
owner/operator is necessarily the same entity as the network
owner/operator.  They may or may not be the same.

Dave Thaler: The first half is editorial.  We should focus on the 
architecture question.   Is it safe to assume that device owner/operator
is the same as the network owner/operator?

Micheal Richardson: You ask architecture question.  To me the question
should be: does the device do all of the determination as to what is an
acceptable update, or does the device accept updates from only a single
entity which is one of the things you mentioned before, which may or may
not be the same.   Not to say that the manifest may or may not have
complicated statements, but the device does not process the manifest
until it has been authenticated.  We do not have to depend on the
devices doing it all.  I think it tweedles the question of
owner/operator independently.

Dave Thaler: We had this discussion at interim meeting, the notion of
counter-signing.  Author of firmware, and an entity that says that it is
appropriate.  Is that okay, or is there ever a case where you need three,
because the device owner is different from network owner.

Micheal: Consider a self-driving car, the owner of the vehicle can say I
do not want to update right now, I am going on a trip and I do not want
changes to automatically get installed while on the trip.  We all have
this issue with our laptops; we do not update the day before IETF.
Meanwhile, the owner of the vehicle considers it really important.  Then
we have the Dept. of Transportation that says, "You will not operate
your vehicle unless you are at this firmware state".

Dave Thaler: Sounds like you're arguing "one or more", not "one or two".

Micheal: My real question is not should there be one or four or 10.
Is it reasonable for the device to only support one, but offload that
decision elsewhere?  I would argue that the case of two signatures
should always be offloaded, device should only ever have to trust one.

Raj Patel: Regarding the question of whether device is owned by the
operator, you have scenarios where device is not owned by operator, but
any sort of update needs to be authorized by operator.   From service
perspective is owned by the operator, any firmware update has to be
authorized.  Network operator has to authorize that firmware, I do
not want that firmware to be sent out to my device.  Not necessarily
a binary situation.

Robin Wilton: I do not want an architecture based on the assumption
that the operator and network are the same entity.   In principle, if
you do that, it tends to favor the walled garden model of proprietary
IoT deployments, we have learned from previous experience that
interests of the end user tend to be better represented once you move
beyond that.  In practice, it has more to do with trust and network
services.  The ability of a third party to interpose themselves on the
user's behalf between the vendor and the device.  Services can broker
terms and conditions on behalf of the user.  You want that ability for
a third party to interpose themselves.   I do not see that being
favored by model where architecture assumes unitary ownership.

Erik Nordmark: Michael brought up few cases, and I do not think it is
that complicated.   Going on trip example is not about image or the
manifest or how they are verified, but about being able to control when
they are applied.  If there is an outage associated with the update,
even for 10 seconds, someone in chain of control might want to say when
to apply it.  I think that is a piece we can externalize.  We can have
a more complex relationship with the manifest signer being different
from the firmware image signer.  The current draft is not sufficiently
precise  on the language for such cases.  This is a real-world case
with automakers, suppliers, and other parties like government and
safety bodies are involved.  The signer can take into account whatever
these parties are saying.  We can externalize some complex stuff, but
There has to be timing pieces.  

(unknown): I don't think we should assume that they are the same,
artificially limiting to one or two signers may not be effective in
the long-term.

C. Xiong: On a wireless network, we should only support multicast, not
broadcast.  5G does not support broadcast.  If lots of parties download
an update at the same time, it can be harmful.

Dave Thaler: We do not want to get into protocol differences between
multicast and broadcast, except in so far as whether the manifest needs
to include details on the recipients.

Dave Thaler: The point of going through those is to be clear about known
open issues in the text.   We had a call for adoption on the mail list.
My personal opinion is that all the things we have talked about can be
done by WG, and they are not obstacles to adoption.  We have already
asked the list, and now we want to ask the people in the meeting room.
Do you believe that this document is a good starting point?  If you
hum "no", I am going to make you say why.

If you believe the draft is good starting point, hum now.  (lots)

If you believe the draft is not the right starting point, hum now. (none)

I claim that that is a clear consensus, next version will be a WG
Internet-Draft.



5a) Manifest Information Model -- Dave Waltermire
https://datatracker.ietf.org/meeting/101/materials/slides-101-suit-chairs-slides-00
---------------
Slide 10: We have milestones for an information model for manifests in
addition to the data model.  The differences between the information
model (IM) and data model (DM) are defined in RFC 3444.

   IM – abstract data elements, cardinality, optionality, abstract
        typing, but all at a level which is not implementable

   DM – defined at a lower level, with sufficient detail for
        implementation

Slide 11: How do we move forward laying out an information model for the
manifest?  Looking at Section 6 of the current architecture draft, it is
providing requirements for an IM.  Appendix A6 provides a few additional
details and manifest fields.  Perhaps as a next step the authors should
break these out into an explicit IM.

Hannes: What information model language should be used?  Currently the
figure is a kind of incomplete UML representation.  One could argue that
UML is a reasonable information model description.  Other things could
be selected as well.

Dave Thaler: English is fine.

(unknown): I have seen these information model efforts go sideways when
we start to talk about using existing data modeling languages.  I have
found they tend to go sideways when you go to a data modeling language.

Dave Kemp: I have been working on several standards where information
models are expressed as tables.  Having cardinality, English prose is
good at expressing that.  Google protobuf has an IDL that is abstract,
although ther encoding is fixed.

Mays A.: On data models, there has been agreement adopting YML as a
language.  I am more interested in the relationship between information
model and data model.  Maybe the document can include one or two
examples about how information model relates to the data models.

Dave Thaler: Our milestones call for an information model and a
serialization, which does not need to be a full data model.

Brendan: I am happy with idea of full flow from usability and security
requirements through to information model.  I am quite happy with
taking output of threat analysis and turning that into an information
model.

Dave Thaler: Section 6 and Section A.6 would be inherently an
information model.  Maybe that could become the basis for an
information model document.

Dave Waltermire: I want to take a quick hum.

Hum now if you are in favor of converting Section 6 and Appendix A into
an information model document, which will be adopted as a WG draft.
(significant hum)

Hum now for no, which means that we will continue to solicit an
information model document using traditional means. (silence)

Slide 12: Next major milestone is adopt an initial manifest
serialization format document, with the goal of it being ready for
the IESG in November.


5b) Manifest Format -- Brendan Moran (30 mins)
https://datatracker.ietf.org/meeting/101/materials/slides-101-suit-draft-moran-suit-manifest-03-00
-----------------------------------
Slide 2: Usability and Threat Model: criteria are in Appendix A.

Slide 4: Manifest Encoding: redrafted manifest format in CBOR and COSE.

Rest of slides: Use of CBOR maps and CDDL

Dave Thaler: The timestamp is controversial because it might require a
clock.

Brett Jordan: Are we going to call out what kind of timestamp?

Brendan: It uses UNIX timestamp.  It can avoid a real-time clock.

Dave Thaler: That will work as long as not sending more than one update
per second.  Also, it is only a clock from the sender’s perspective.
From the receiver’s perspective, it is just a number you compare with
other numbers received.

Henk: I totally get that time is monotonically increasing, but maybe it
is little bit complicated to use time.  Please do not use time.

(unknown): I think we should just say monotonically incrementing number,
much more straightforward and safe.

Henk: I am seeking clarification on conditions and directives.

Brendan: The intent here is that you match all conditions before
applying any directives.

Henk: Okay, maybe make it less complicated or align with the ECA.

David Waltermire: What is the “that” you would be aligning with?

Henk: Maybe a YANG automation control framework using ECA.

David Waltermire: Please send pointers to some of these documents to
the list.

Hannes: Carsten had suggested to use the term "claims" here, but in
essence the basic idea is simple, based on description in the
architecture document, we want the ability to express that an update
is only applicable to a certain device.  In this version, the condition
is used for that.  Four conditions have been proposed so far that nail
down which devices the update is for.

Henk: Please do not call it a condition.  It is a description.

Brendan: One is the minimum bashery level that is required to apply
the update.

Henk: One might be "best before" a given date.   

Rick Taylor: I think the word we are looking for is "prerequisite."

Brendan: That sounds right to me.

Dave Thaler: If you believe these are conditions to be checked by device
itself, then I do not think device can check "best before" that without
a real-time clock. So either say "best before" is okay to ignore, or say
this is a reason to use a different protocol.

Micheal Richardson: You' are using CBOR/CDDL, so you need extensions too.

Brendan: The current implementation is an array.

Micheal: You can still add things to array.   If you are saying that
there is the order in the array, then I think that is a mistake.

Henk: Relaying a comment:  Can one manifest rely on other manifests?
The dependency is another manifest, not some random resource.

Markus: Is everybody happy with CBOR and COSE?  It would be very good to
get some libraries or code running on constrained devices.  It would be
very important for implementers to get a feeling of how this works.

David Waltermire: Please come see the chairs after the session if you
want to work on that.


Presentation to Outgoing Security Area Director, Kathleen Moriarty
------------------------------------------------------------------
Russ Housley invited Kathleen Moriarty to the front of the room...
In the plenary on Wednesday, Kathleen will be stepping out of her role
as a Security Area Director.  To thank her for her part in starting
this group, Russ presented a "SUITable" a gift.