Subject: Re: [Fud] Charter Text

From: Olaf Bergmann <[email-masked]>
Date: Mon, 07 Aug 2017 12:32:00 +0200

Emmanuel Baccelli <[email-masked]> writes:

> thanks a lot for the strawman! Reads well in my opinion. 

+1

> At high level, I have the following comments & suggestions:
>
> - we have the case of software updates, not only firmware updates, so
> I'd rather we talk about the more general case of software updates. Is
> there a strong reason against this?

This is more a question of whether a module is regarded as part of the
firmware (cf. "firmware package" in the text). Some application-specific
JavaScript code may or may not fall under this category. (You could,
e.g., discuss if Ethereum contracts are "software" in this sense. But I
am not sure that this would be addressed in this WG?)

Grüße
Olaf

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 8 Aug 2017 12:29:52 +0200

Hi Emmanuel

sorry for the delay in responding to your review (due to vacation).

On 07/22/2017 09:57 AM, Emmanuel Baccelli wrote:
> Hi Hannes,

There are several reasons why I wanted to focus on firmware updates:

(a) In ARM we have worked on firmware updates for M-class devices and
A-class devices. The constraints, developer experience, business models,
the involved parties, security concerns, etc. between these two classes
of devices are different. We don't see a lot of guys running special
versions of Java, JavaScript/JerryScript, etc. on M-class devices even
though we have been experimenting with these ideas as well (see
https://developer.mbed.org/javascript-on-mbed/). My personal opinion is
that those are nice fun projects but not useful for anything serious.

(b) We wanted to have it focused in the hope that this work can be
finished in a somewhat timely manner.

(c) There are many software update mechanisms for regular OSs available
already. I am not sure there is need for more work.

(d) We have also proposed a software update mechanism for trusted
applications running on a TEEs with the work in TEEP. The requirements
are different there since we also need an attestation concept.
(There may, however, be some synergies between this work and TEEP.)

> 
> - many people think IoT= RaspberryPi, so I think we should be very very
> clear that we are also targeting constrained devices as defined in RFC7228.
> In particular, I'm convinced we can (and should) explicitly include
> Class 1 devices as also being a target for such software updates.

That's a good suggestion.

What about adding a paragraph that says something like:

"
This group focuses on defining a firmware update solution for Class 1
devices, as defined in RFC 7228, i.e., IoT devices with ~10 KiB RAM and
~100 KiB flash.
"

This is clearly quite ambitious since you will typically need a bit more
flash to store a second firmware image (to have a robust firmware update
solution). I would probably feel a bit more comfortable talking about
~20 KiB RAM and ~200 KiB flash if we are talking about a system that
uses public key cryptography.

I just want to avoid that we rule out public key crypto and also have
the freedom to explore ideas Russ suggested regarding hash-based
signatures. Just working on a system that only offers symmetric key
crypto is IMHO not enough.

> 
> - FUD is quite an unfortunate acronym. Here's an alternative name
> proposal for the working group: how about SUIT (Software Updates for
> Internet of Things).

Fine for me. I let the chairs decide about the best possible name for
the working group.

> 
> (there is a heavy similarity between the above comments and the ones I
> put forward during the f2f meeting in Prague, as well as with the> comments I posted on the manifest+arch drafts you submitted this week ;)

Thanks for summarizing your feedback made during the face-to-face meeting.

Ciao
Hannes

> 
> Cheers,
> 
> Emmanuel
> 
> 
> 
> On Fri, Jul 21, 2017 at 11:52 PM, Hannes Tschofenig
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Here is a strawman proposal for a charter text. Suggestions welcome!
> 
>     ----
> 
>     Firmware Updating Description (FUD)
> 
>     Vulnerabilities with Internet of Things (IoT) devices have raised the
>     need for a secure firmware update mechanism that is also suitable for
>     constrained devices. Security experts, researchers and regulators
>     recommend that all IoT devices are equipped with such a mechanism. While
>     there are many proprietary firmware update mechanisms in use today there
>     is a lack of an modern interoperable approach of securely updating IoT
>     devices.
> 
>     A firmware update solution consists of several components, including a
>     mechanism to transport firmware images to IoT devices and a manifest
>     that provides meta-data about the firmware image as well as
>     cryptographic information for protecting the firmware image in an
>     end-to-end fashion. With RFC 4018 the IETF standardized a manifest
>     format that uses the Cryptographic Message Syntax (CMS) to protect
>     firmware packages.
> 
>     Since the publication of RFC 4108 more than 10 years have passed and
>     more experience with IoT deployments have lead to additional
>     functionality requiring the work done with RFC 4108 to be revisited. The
>     purpose of this group is to standardize a version 2 of RFC 4108 that
>     reflects best current practices. This group will not define any
>     transport mechanism.
> 
>     In 2016 the Internet Architecture Board organized a workshop on
>     'Internet of Things (IoT) Software Update (IOTSU)', which took place at
>     Trinity College Dublin, Ireland on the 13th and 14th of June, 2016. The
>     main goal of the workshop was to foster a discussion on requirements,
>     challenges and solutions for bringing software and firmware updates to
>     IoT devices. This workshop also made clear that there are challenges
>     with lack of regulatory requirements, and misaligned incentives. It is
>     nevertheless seen as important to standardize the building blocks that
>     help interested parties to implement and deploy a solid firmware update
>     mechanism.
> 
>     In particular this group aims to publish two documents, namely
>      * an IoT firmware update architecture that includes a description of
>     the involved entities, security threats and assumptions, and
>      * the manifest format itself.
> 
>     This group does not aim to standardize a generic software update
>     mechanism used by rich operating systems, like Linux, but instead
>     focuses on software development practices in the embedded industry.
> 
>     This group will aim to develop a close relationship with silicon vendors
>     and OEMs that develop IoT operating systems.
> 
>     Milestones
> 
>     Dec 2017     Submit "Architecture" document as WG item.
> 
>     Dec 2017     Submit "Manifest Format" specification as WG item.
> 
>     Jul 2018    Submit "Architecture" to the IESG for publication as an
>     Informational RFC.
> 
>     Nov 2018     Submit "Manifest Format" to the IESG for publication as a
>     Proposed Standard.
> 
> 
>     Additional calendar items:
> 
>     Mar 2018     Release initial version of the manifest creation tools as
>     open source.
> 
>     Apr 2018     Release first version of manifest test tool suite as open
>     source.
> 
>     Jun 2018     Release first IoT OS implementation of firmware update
>     mechanisms as open source.
> 
>     _______________________________________________
>     Fud mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/fud
>     <https://www.ietf.org/mailman/listinfo/fud>
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 8 Aug 2017 12:39:16 +0200

Hi Olaf,

> am not sure that this would be addressed in this WG?)

I believe Emmanuel needs to tell us a bit more about the use case he has
in mind.

The use cases I would like to cover are:

- a developer creates a single firmware image, which may consist of
source code from various parties and may also contain binaries from
third parties.

- a developer creates multiple firmware images (since the device has
multiple microcontrollers that need to be updated).

In this model the update service on a microcontroller gets code from a
single source only (at least for the device it appears so since it does
not know whether an included library was written by a different developer).

What I specifically want to exclude is a model like JavaScript where you
can get code from multiple different sources dynamically during code
execution. Not only does this lead to challenges for code execution on
these constrained devices but it also raises all sorts of security
issues, which are difficult to solve on these low end devices. While
there are isolation techniques available (like the MPU on Cortex M class
devices and TrustZone for v8-M in upcoming devices) they have their limits.

Ciao
Hannes

PS: I consider Smart Contracts also outside the scope of this group.
Maybe an IRTF research group should work on them.

---

From: Olaf Bergmann <[email-masked]>
Date: Tue, 08 Aug 2017 12:50:18 +0200

Hi Hannes,

> I believe Emmanuel needs to tell us a bit more about the use case he has

And of course others as well. Hannes did a good outline of what he
thinks should be addressed. Those who have use cases that are not
covered by this should speak up.

> not know whether an included library was written by a different developer).

Yes, I agree in principle.

What we have seen (not only at the IOTSU workshop but also on existing
devices such as VoIP phones) is that firmware updates typically do not
come as a monolithic package but that in modules that can be updated
separately (the most common---and desirable---split is between the OS
and the basic bootloader). I think that at least this should be
addressed here.

> execution.

I agree as well.

Grüße
Olaf

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 10 Aug 2017 13:47:36 +0200

Hi Olaf,

a few remarks below.

> covered by this should speak up.

Certainly.

> and the basic bootloader). I think that at least this should be

FWIW I would not consider VoIP phones in scope of the devices we would
be looking at.

I also recall discussions at the IoTSU workshop but I remember that
there was some confusion between the concept of a monolithic firmware
images and what is actually sent over the wire (full image vs.
differential updates). I don't think we ever talked about bootloaders
vs. the rest of the OS.

Ciao
Hannes

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 10 Aug 2017 18:15:56 +0200

Hi Hannes,

> FWIW I would not consider VoIP phones in scope of the devices we would

I do not say that we should look at VoIP phones in general (if they
happen to be class 1 devices, they might be in focus here). I brought
these up as an example that shows how multi-step firmware updates today
are handled on devices that also have certain limitations on their RAM
and flash memory.

This brings me back to the charter text. It says:

  "Since the publication of RFC 4108 more than 10 years have passed and
   more experience with IoT deployments have lead to additional
   functionality requiring the work done with RFC 4108 to be revisited."

Now, although it was already suggested (and you agreed) to mention RFC
7228 class 1 devices later in the charter, the quoted sentence may lead
to the impression that this is merely a 4108bis which would address
non-constrained devices as well.

> differential updates). I don't think we ever talked about bootloaders

It's never too late to start. As said before: Vendors do this already.

Grüße
Olaf

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Aug 2017 23:51:06 +0200

Hi Hannes,

We always have this tension of different classes of hardware target.
Most of the work of CoRE was about targeting class 1, but not in the sense of targeting it exclusively, but just in the sense that class 1 can be part of the solution as well as the higher classes (see also the 7228bis for a way to extend the class nomenclature — https://lwig-wg.github.io/terminology/ ).

> devices, as defined in RFC 7228, i.e., IoT devices with ~10 KiB RAM and

Maybe s/for/that is applicable to/ (so it’s not just limited to class-1, but can also work for class-2).

Maybe add that the sweet spot (full range of capabilities) is likely to start about factor 2 or 3 above those numbers, as you mentioned.

And maybe also give an impression of where the range of applicability we are shooting for will end (i.e., this is not meant for updating Linux, which 7228bis calls J-group and ARM calls A-class).

Grüße, Carsten

---

From: "Thomas Eichinger" <[email-masked]>
Date: Thu, 10 Aug 2017 15:36:27 -0700

Hi Hannes,

Thanks for the proposal! Please see comments below.

> that those are nice fun projects but not useful for anything serious.

Personally, from the charter text it is not clear what it considers part of
the firmware and what it doesn't.
The general definition of firmware is very blurry with different meanings
for many people. So applications running in an OS or on top of a driver
library are not necessarily considered firmware although maybe part of the
same resulting monolithic binary image.

Best, Thomas

ps.: There is a reference of RFC4018 which is probably unintended.

---

From: Russ Housley <[email-masked]>
Date: Mon, 14 Aug 2017 09:05:10 -0400

I'm jumping into this conversation after vacation.  I have read the whole thread to date before composing this note.

> Firmware Updating Description (FUD)

The page that Kathleen set up call this group Firmware UpDate (FUD).

> format that uses the Cryptographic Message Syntax (CMS) to protect

There are some vital pieces of information that need to be conveyed, but from the above text, it is not clear to me whether they are expected to be in the manifest and meta-data.  The vital data includes:

   - a firmware package identifier;
   - whether the package is a patch or upgrade;
   - the hardware the package needs to run;
   - dependencies on other firmware packages; and
   - if the package is encrypted to protect intellectual property, the key needed to decrypt it.

> Trinity College Dublin, Ireland on the 13th and 14th of June, 2016. The

13-14 June 2016

> * the manifest format itself.

The text a few paragraphs ago made me think that rfc4108bis was an output.  Why is it not here?

> focuses on software development practices in the embedded industry.

This should be expanded to make it clear that JavaScript is not a goal either.

> Nov 2018     Submit "Manifest Format" to the IESG for publication as a

The text a few paragraphs ago made me think that rfc4108bis was an output.  Why is it not here?

Russ

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 18 Aug 2017 11:58:19 +0200

Hi Thomas,

thanks for your input.Quick response only...

> ps.: There is a reference of RFC4018 which is probably unintended.
Yes, this is a mistake. I should be RFC 4108 "Using Cryptographic
Message Syntax (CMS) to Protect Firmware Packages"
https://tools.ietf.org/html/rfc4108

Ciao
Hannes

> [email-masked]

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 18 Aug 2017 11:58:28 +0200

Hi Thomas,

> ps.: There is a reference of RFC4018 which is probably unintended.
Yes, this is a mistake. It should be RFC 4108 "Using Cryptographic
Message Syntax (CMS) to Protect Firmware Packages"
https://tools.ietf.org/html/rfc4108

Ciao
Hannes