Subject: Re: [Fud] Editorial Charter Update

From: Emmanuel Baccelli <[email-masked]>
Date: Sun, 1 Oct 2017 09:20:47 +0200

Hi Hannes,

thanks for the update. Reads well in my opinion.
A couple of comments below:

On Fri, Sep 29, 2017 at 1:00 PM, Hannes Tschofenig <
[email-masked]> wrote:

>
>
> Firmware Updating Description (FUD)
> [Alternative proposal: SUIT (Software Updates for Internet of Things).]
>
>
To no surprise, I really like SUIT, but if the WG focuses only on firmware
and excludes other types of software updates, we should probably keep that
name for another working group ;)

On the other hand, FUD is still a problematic name. How about an
alternative such as:

FiDeL : Firmware Description for Low-end IoT devices

out of scope are
> software update solutions that aim to take the features of scripting
> languages, such as JavaScript variants like JerryScript, into account.
>

FYI JerryScript is fully compliant with ECMA5.1, hence not really a
"variant".
Here, I don't think we need to be that precise anyway to get the message
across.
How about rephrasing with something like:

"Software update solutions that target updating software other than the
firmware binary (e.g. updating scripts) are out of scope".

Cheers

Emmanuel

---

From: Chris Rouland <[email-masked]>
Date: Sun, 1 Oct 2017 10:11:29 -0400

Hi,

I do think that locking into the firmware binary itself could exclude a significant part of the problem set around updating embedded IOT operating systems that would not technically be classified as FW.

I think SUIT is good and broad.

-Chris

> On Oct 1, 2017, at 3:20 AM, Emmanuel Baccelli <[email-masked]> wrote:
> 
> Hi Hannes,
> 
> On Fri, Sep 29, 2017 at 1:00 PM, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> To no surprise, I really like SUIT, but if the WG focuses only on firmware and excludes other types of software updates, we should probably keep that name for another working group ;)
> 
> On the other hand, FUD is still a problematic name. How about an alternative such as:
> 
> FYI JerryScript is fully compliant with ECMA5.1, hence not really a "variant".
> Here, I don't think we need to be that precise anyway to get the message across.
> "Software update solutions that target updating software other than the firmware binary (e.g. updating scripts) are out of scope".
> 
> Cheers
> 
> Emmanuel
>  
> _______________________________________________
> Fud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fud

---

From: Russ Housley <[email-masked]>
Date: Tue, 3 Oct 2017 09:43:03 -0400

Here is an update to the charter text based on the comments.

Note that the WG name is still FUD.  Any name change will be handled by the IESG.

Russ

= = = = = = =

Firmware Updating Description (FUD)
[Alternative proposal: SUIT (Software Updates for Internet of Things)]

Vulnerabilities in 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 be equipped with such a mechanism.  While
there are many proprietary firmware update mechanisms in use today, there
is a lack of a modern interoperable approach of securely updating the
software in IoT devices.

A firmware update solution consists of several components, including:
  *  A mechanism to transport firmware images to IoT devices.
  *  A manifest that provides meta-data about the firmware image
     (such as a firmware package identifier, the hardware the package
     needs to run, and dependencies on other firmware packages), as
     well as cryptographic information for protecting the firmware
     image in an end-to-end fashion.
  *  The firmware image itself.

RFC 4108 provides a manifest format that uses the Cryptographic Message
Syntax (CMS) to protect firmware packages.

More than ten years have passed since the publication of RFC 4108, and
greater experience with IoT deployments has lead to additional
functionality, requiring the work done with RFC 4108 to be revisited.
The purpose of this group is to produce a second version of RFC 4108
that reflects the current best practices.  This group will focus on
defining a firmware update solution for Class 1 devices, as defined in
RFC 7228, that is -- IoT devices with ~10 KiB RAM and ~100 KiB flash.
This group will not define any transport mechanisms.

In June of 2016 the Internet Architecture Board organized a workshop on
'Internet of Things (IoT) Software Update (IOTSU)', which took place at
Trinity College in Dublin, Ireland.  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 is a lack of regulatory requirements, which
contributes to challenges associated with misaligned incentives.  It is
nevertheless seen as important to create standard building blocks that
help interested parties implement and deploy a solid firmware update
mechanism.

In particular this group aims to publish three documents, namely:
  *  An IoT firmware update architecture that includes a description of
     the involved entities, security threats, and assumptions.
  *  The manifest format.
  *  A revision to RFC 4108 that reflects the current best practices.

This group will use draft-moran-fud-architecture as a starting point for
discussion of the "Architecture" document.

This group will use draft-moran-fud-manifest as a starting point for
discussion of the "Manifest Format" specification.

This group does not aim to create a standard for a generic software
update mechanism for use by rich operating systems, like Linux, but
instead this group will focus on software development practices in the
embedded industry.  "Software update solutions that target updating
software other than the firmware binary (e.g. updating scripts) are
also out of scope.

This group will aim to develop a close relationship with silicon vendors
and OEMs that develop IoT operating systems.

Milestones:

Dec 2017     Submit RFC 4108bis document as WG item.

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 RFC 4108bis document to the IESG for publication as
             a Proposed Standard.

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 tools as open
             source.

Jun 2018     Release first IoT OS implementation of firmware update
             mechanisms as open source.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 4 Oct 2017 15:54:01 +0200

Hi Chris,

my intention is to describe a reasonable starting point that helps solve
a security problem in the IoT world.

You have to start somewhere and I am sure there is more work to be done
and charters can be extended over time as progress is being made.
Furthermore, nothing is saying at the work will not be useful for other
areas as well but it should at least define the core problem.

I hope my clarification makes sense.

Ciao
Hannes

On 10/01/2017 04:11 PM, Chris Rouland wrote:
> 
> Hi,
> 
> I do think that locking into the firmware binary itself could exclude a
> significant part of the problem set around updating embedded IOT
> operating systems that would not technically be classified as FW.
> 
>> On Oct 1, 2017, at 3:20 AM, Emmanuel Baccelli
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi Hannes,
>>
>> On Fri, Sep 29, 2017 at 1:00 PM, Hannes Tschofenig
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>
>> To no surprise, I really like SUIT, but if the WG focuses only on
>> firmware and excludes other types of software updates, we should
>> probably keep that name for another working group ;)
>>
>> "Software update solutions that target updating software other than
>> the firmware binary (e.g. updating scripts) are out of scope".
>>
>> Cheers
>>
>> Emmanuel
>>  
>> [email-masked] <mailto:[email-masked]>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 4 Oct 2017 20:31:21 +0300

Hi Russ, 

I had a comment about a possible misunderstanding of the FUD/suit WG being misunderstood as the rfc4108 bug fixing and tweaking WG. I'm not sure that had been addressed. I'm mostly offline in the next seven days or so. 

Sent from mobile

> On 3. Oct 2017, at 16:43, Russ Housley <[email-masked]> wrote:
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 9 Oct 2017 10:24:21 +0200

Hi Carsten

I had provided a response to your comment and asked whether it clarifies
things.

I don't believe you have responded.

So far, I haven't heard you saying anything about what you would like to
see done in this working group. I would also like to know what you see
wrong with bug fixing and tweaking?

Ciao
Hannes

On 10/04/2017 07:31 PM, Carsten Bormann wrote:
> Hi Russ, 
> 
> I had a comment about a possible misunderstanding of the FUD/suit WG
> being misunderstood as the rfc4108 bug fixing and tweaking WG. I'm not
> sure that had been addressed. I'm mostly offline in the next seven days
> or so. 
> 
> Sent from mobile
> 
> On 3. Oct 2017, at 16:43, Russ Housley <[email-masked]
> <mailto:[email-masked]>> wrote:
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 10 Oct 2017 10:41:39 +0200

> I don't believe you have responded.

Sorry, I’m way behind in my mail.

> see done in this working group.

I think the discussion has evolved towards focusing on data formats for describing software update packages and their applicability in a secure way.  Being able for a set of managing entities (for the device owner, for the device manufacturer, for authorized third parties) to properly authorize the update of a (potentially low-resource) device with firmware that is fresh, appropriate for the device and its configuration, and appropriate for the usage situation that device is in.

> I would also like to know what you see

Nothing is wrong with that if what is being fixed and tweaked is solving the problem after finishing the fixing and tweaking.  Not sure we are in that position.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 10 Oct 2017 11:08:04 +0200

Hi Carsten,

> I think the discussion has evolved towards focusing on data formats for describing software update packages and their applicability in a secure way.  Being able for a set of managing entities (for…

I wouldn't say it has evolved but it is now more clearly described.

But if you like the current text then I am happy.

Ciao
Hannes