Subject: [Suit] Updated Charter Text and Way Forward

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Mon, 4 Dec 2017 21:36:49 +0000

Kathleen, Dave, and I met earlier today to discuss the charter and the way forward. This email includes updated charter text and milestones, and a brief description of the changes we have made based on the input from the mailing list.

The following is updated charter text and milestones based on the mailing list conversation since the BoF. We are posting this text for review on the SUIT mailing list for 1 week, ending on Monday, December 11th at 23:59 UTC. This review is a call for consensus on the full charter. Please indicate if you support this text or if you have any objections or blocking concerns on this text. Please provide comments including proposed text changes ASAP to provide ample time for discussion. 

Kathleen will post updated text to the Datatracker at a future date once we get a sense of the mailing list discussion to follow. This will likely be before we have assessed consensus. We will update the Datatracker and post these updates to the list as needed per agreement on the list.

-- start charter text ---

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 firmware in IoT devices. In June of 2016 the Internet Architecture Board organized a workshop on 'Internet of Things (IoT) Software Update (IOTSU)', and RFC 8240 documents various requirements and challenges that are specific to IoT devices.

A firmware update solution consists of several components, including:
* A mechanism to transport firmware images to compatible 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.

This group will focus on defining a firmware update solution (taking into account past learnings from RFC 4108 and other firmware update solutions) that will be usable on Class 1 (as defined in RFC 7228) devices, i.e., devices with ~10 KiB RAM and ~100 KiB flash.  The solution may apply to more capable devices as well.  This group will not define any new transport or discovery mechanisms, but may describe how to use existing mechanisms within the architecture.

In particular this group aims to publish several documents, namely:
* An IoT firmware update architecture that includes a description of the involved entities, security threats, and assumptions. 
* One or more manifest format specifications.

The initial focus of this group will be development of the information model for the contents of a manifest. Once there is general agreement on the contents, the group will pick a small number of serialization formats such as CBOR and/or ASN.1 (and their associated cryptographic mechanisms) to encode the manifest. A small number of formats is preferred to reduce the complexity of a firmware management solution, where each IoT device would typically only support one format, but the same tool or service might support all such formats. To support a wide range of deployment scenarios, the formats are expected to be expressive enough to allow the use of different firmware sources and permission models.

This group does not aim to create a standard for a generic application software update mechanism, but instead this group will focus on firmware development practices in the embedded industry. Software update solutions that target updating software other than the firmware binaries (e.g., applications) are also out of scope.

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

-- end charter text ---

-- start proposed milestones --
Date	     Milestone
Nov 2018  Submit an initial manifest serialization format to the IESG for publication as a Proposed Standard. 
Jul 2018    Submit manifest information model to the IESG for publication as Informational. 
Jul 2018    Calendar item: Second interoperability event at IETF 102. 
Mar 2018 Calendar item: First interoperability event at IETF 101.
Mar 2018 Adopt a manifest information model as a WG item.
Mar 2018 Adopt initial manifest serialization format(s) as WG item(s).
Jan 2018 Adopt "Architecture" document as WG item.
-- end proposed milestones --

The updated charter and milestones addresses the following concerns raised on the mailing list:
- The text around the IAB workshop on the Internet of Things (IoT) Software Update (IOTSU) has been minimized, with a single sentence left to provide historical backgroud information.
- Bulleted items in the second and fourth paragraphs are now indicated by an asterisk. The formatting is fixed.
- Text about RFC 4108 has been further minimized, with only a reference to RFC 4108 included as a source of past learnings on update solutions along with existing other work on firmware update solutions. This makes RFC 4108 part of the larger body of work to consider as lessons-learned in this space.
- Discussion of defining the use of existing transport or discovery mechanisms is now referenced to be described in the architecture.
- The text on formats has been clarified to be more consistent with the discussions on the mailing list. The new text discusses the development of a manifest information model that describes the manifest contents, and the development of one or more manifest serialization formats and crypto mechanisms. The information model and serialization format split has also been reflected in the milestones. This leaves the actual document organization up to the WG, the milestones do not dictate that documents be separated (or not separated).
- The term "firmware" has been used where appropriate instead of "software" to better reflect the focus of the WG on firmware update mechanisms and to be consistent with the BoF meeting consensus. The milestones have been updated for more consistent use of terminology as well.
- The last paragraph has been rewritten to avoid singling out a single OS or enumerating a larger list of OS's, and instead to focus on the difference between firmware and applications, as discussed at the BoF.

Regards,
Dave Waltermire and Dave Thaler

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 13 Dec 2017 09:29:05 -0800

Hello Chairs

Thanks chairs for sharing the updated charter. My apologies for delay in
responding. I totally lost track of the deadline (my bad)

Here are few concerns regarding the current charter text and would greatly
appreciate if these can be discussed or taken into consideration by the
chairs and the WG.

Major Issue:

Firmware update service discovery and mechanisms to download the firmware

The current charter says

"

This group will not define any new transport or discovery mechanisms,

but may describe how to use existing mechanisms within the architecture

"

Couple of points of concerns

1. From my recollection of BOF discussions, there was support to charter
work to discover the firmware server, the manifest and using existing
mechanisms to download the firmware image.

2. The strength of "may" in the current charter text and lacking explicit
deliverable for this, makes one conclude such a work by the WG is optional.

There are several deployments where the IoT device operating under
restricted network access cannot reach out to the manufacturer's/OEM's
website to download the firmware. Often one does not want to have a device
with unpatched firmware using the open internet to contact the vendor's
website to get a firmware update and instead a local firmware server is
used to cache the firmware.  One can expect to have local firmware server
managed by the enterprise/factory to serve the firmware.

Having charter make explicit provision for discovering such local server &
locate the manifest (and firmware) on that server at a well-known location,
as a WG deliverable, will be super beneficial and helps in a great deal
towards building interoperable solution.

To that extent, may i propose splitting the WG deliverables as below (
including some text suggestions posted by Michael as well, from
https://www.ietf.org/mail-archive/web/suit/current/msg00286.html)

* One or more optional mechanisms will be described that use existing
transport and discovery protocols to locate and transfer the firmware

* The requirements for secure firmware upgrade will be documented

* Define a general architecture the enables secure IoT firmware upgrade
describing involved elements, security threats

* An extensible data model that captures metadata and security properties
about the firmware will be developed and codified in a manifest.

* Define one or more encoding formats for the maifest

Minor Issues

 Below are some of the issues which have been raised on the mailing list
earlier and I haven’t heard consensus either in support or against them. I
feel these issues as unresolved and would love to hear input form the
chairs and the WG how do we proceed further.

1. Manifest Formats

The charter says

"A small number of formats is preferred to reduce the complexity of a
firmware management solution, where each IoT device would typically only
support one format, but the same tool or service might support all such
formats. "

It is not very clear from the charter what tool or service are being
referred to and its influence on the complexity or the number of
serialization formats to constitute as a restriction in the charter
deliverable. Would it be fine if the the charter just says one or more
serialization formats will be developed by the working group and then leave
it to the WG to decide the number and formats based on the use-cases.

2. Relationship to others

The charter says

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

I would like to reiterate that it is quite important that this WG maintain
relationships with the people who build and deploy the IOT devices as well.
Hannes had the following proposal (
https://www.ietf.org/mail-archive/web/suit/current/msg00249.html) and may
we use the same ?

"This group will aim to maintain a close relationship with silicon vendors
and OEMs that develop IoT operating systems. Additionally, the group will
reach out to companies who build and deploy IoT devices."

3. Permission Model involving multiple sources

I think the whole idea of multiple people signing is very unclear on the
requirements and its applicability or its widespread use. Most common
deployments today follow the model of single vendor signing. Would the WG
be open to start with a simple permission model (single vendor based) that
is readily applicable to majority of today deployments and possibly extend
it as necessary.

please let me know your thoughts

On Mon, Dec 4, 2017 at 1:36 PM, Waltermire, David A. (Fed) <
[email-masked]> wrote:

> Kathleen, Dave, and I met earlier today to discuss the charter and the way
> forward. This email includes updated charter text and milestones, and a
> brief description of the changes we have made based on the input from the
> mailing list.
>
> The following is updated charter text and milestones based on the mailing
> list conversation since the BoF. We are posting this text for review on the
> SUIT mailing list for 1 week, ending on Monday, December 11th at 23:59 UTC.
> This review is a call for consensus on the full charter. Please indicate if
> you support this text or if you have any objections or blocking concerns on
> this text. Please provide comments including proposed text changes ASAP to
> provide ample time for discussion.
>
> Kathleen will post updated text to the Datatracker at a future date once
> we get a sense of the mailing list discussion to follow. This will likely
> be before we have assessed consensus. We will update the Datatracker and
> post these updates to the list as needed per agreement on the list.
>
> 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
> firmware in IoT devices. In June of 2016 the Internet Architecture Board
> organized a workshop on 'Internet of Things (IoT) Software Update (IOTSU)',
> and RFC 8240 documents various requirements and challenges that are
> specific 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.
> This group will focus on defining a firmware update solution (taking into
> account past learnings from RFC 4108 and other firmware update solutions)
> that will be usable on Class 1 (as defined in RFC 7228) devices, i.e.,
> devices with ~10 KiB RAM and ~100 KiB flash.  The solution may apply to
> more capable devices as well.  This group will not define any new transport
> or discovery mechanisms, but may describe how to use existing mechanisms
> within the architecture.
>
> * An IoT firmware update architecture that includes a description of the
> involved entities, security threats, and assumptions.
> The initial focus of this group will be development of the information
> model for the contents of a manifest. Once there is general agreement on
> the contents, the group will pick a small number of serialization formats
> such as CBOR and/or ASN.1 (and their associated cryptographic mechanisms)
> to encode the manifest. A small number of formats is preferred to reduce
> the complexity of a firmware management solution, where each IoT device
> would typically only support one format, but the same tool or service might
> support all such formats. To support a wide range of deployment scenarios,
> the formats are expected to be expressive enough to allow the use of
> different firmware sources and permission models.
>
> This group does not aim to create a standard for a generic application
> software update mechanism, but instead this group will focus on firmware
> development practices in the embedded industry. Software update solutions
> that target updating software other than the firmware binaries (e.g.,
> applications) are also out of scope.
>
> This group will aim to maintain a close relationship with silicon vendors
> and OEMs that develop IoT operating systems.
>
> -- end charter text ---
>
> - The text around the IAB workshop on the Internet of Things (IoT)
> Software Update (IOTSU) has been minimized, with a single sentence left to
> provide historical backgroud information.
> - Text about RFC 4108 has been further minimized, with only a reference to
> RFC 4108 included as a source of past learnings on update solutions along
> with existing other work on firmware update solutions. This makes RFC 4108
> part of the larger body of work to consider as lessons-learned in this
> space.
> - Discussion of defining the use of existing transport or discovery
> mechanisms is now referenced to be described in the architecture.
> - The text on formats has been clarified to be more consistent with the
> discussions on the mailing list. The new text discusses the development of
> a manifest information model that describes the manifest contents, and the
> development of one or more manifest serialization formats and crypto
> mechanisms. The information model and serialization format split has also
> been reflected in the milestones. This leaves the actual document
> organization up to the WG, the milestones do not dictate that documents be
> separated (or not separated).
> - The term "firmware" has been used where appropriate instead of
> "software" to better reflect the focus of the WG on firmware update
> mechanisms and to be consistent with the BoF meeting consensus. The
> milestones have been updated for more consistent use of terminology as well.
> - The last paragraph has been rewritten to avoid singling out a single OS
> or enumerating a larger list of OS's, and instead to focus on the
> difference between firmware and applications, as discussed at the BoF.
>
> Regards,
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit
>

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Wed, 13 Dec 2017 19:30:51 +0000

Suhas,

My comments as chair are marked [daw] below.

Regards,
Dave

From: Suhas Nandakumar [mailto:[email-masked]]
Sent: Wednesday, December 13, 2017 12:29 PM
To: Waltermire, David A. (Fed) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Suit] Updated Charter Text and Way Forward

Hello Chairs

Thanks chairs for sharing the updated charter. My apologies for delay in responding. I totally lost track of the deadline (my bad)

Here are few concerns regarding the current charter text and would greatly appreciate if these can be discussed or taken into consideration by the chairs and the WG.

Major Issue:

The current charter says

"

"

1. From my recollection of BOF discussions, there was support to charter work to discover the firmware server, the manifest and using existing mechanisms to download the firmware image.

2. The strength of "may" in the current charter text and lacking explicit deliverable for this, makes one conclude such a work by the WG is optional.

[daw: The charter leaves the WG to figure out how existing discovery mechanisms fit in the architecture and manifest work. This is something you can address by contributing to these efforts under the current charter text.]

There are several deployments where the IoT device operating under restricted network access cannot reach out to the manufacturer's/OEM's website to download the firmware. Often one does not want to have a device with unpatched firmware using the open internet to contact the vendor's website to get a firmware update and instead a local firmware server is used to cache the firmware.  One can expect to have local firmware server managed by the enterprise/factory to serve the firmware.

Having charter make explicit provision for discovering such local server & locate the manifest (and firmware) on that server at a well-known location, as a WG deliverable, will be super beneficial and helps in a great deal towards building interoperable solution.

[daw: I would expect the architecture work to address this concern.]

To that extent, may i propose splitting the WG deliverables as below ( including some text suggestions posted by Michael as well, from https://www.ietf.org/mail-archive/web/suit/current/msg00286.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmail-archive%2Fweb%2Fsuit%2Fcurrent%2Fmsg00286.html&data=02%7C01%7Cdavid.waltermire%40nist.gov%7Cc88eb9b57db74b377cb408d5424f0340%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636487829480785367&sdata=k4REfb02Ao1e%2Fwaw9ufkvYIVw%2BjxPV6Z%2BE92UcDdJFw%3D&reserved=0>)

* One or more optional mechanisms will be described that use existing transport and discovery protocols to locate and transfer the firmware

* Define a general architecture the enables secure IoT firmware upgrade describing involved elements, security threats

* An extensible data model that captures metadata and security properties about the firmware will be developed and codified in a manifest.

[daw: The first 3 bullets represent technical issues that need to be addressed as part of the architecture work that is an identified milestone. This work can even be done in multiple documents if the WG consensus is to do so. Such a choice can be made after we are chartered without impacting the milestones. There has not been consensus that we need this level of granularity defined in the charter. Instead there has been support to complete the chartering process so we can begin the work of documenting these requirements and architectural considerations in the architecture and solution drafts. The sooner we are chartered, the sooner we can get working on what you are asking for.]

Minor Issues

 Below are some of the issues which have been raised on the mailing list earlier and I haven’t heard consensus either in support or against them. I feel these issues as unresolved and would love to hear input form the chairs and the WG how do we proceed further.

1. Manifest Formats

The charter says

"A small number of formats is preferred to reduce the complexity of a firmware management solution, where each IoT device would typically only support one format, but the same tool or service might support all such formats. "

It is not very clear from the charter what tool or service are being referred to and its influence on the complexity or the number of serialization formats to constitute as a restriction in the charter deliverable. Would it be fine if the the charter just says one or more serialization formats will be developed by the working group and then leave it to the WG to decide the number and formats based on the use-cases.

[daw: The text already in the charter allows one or more serialization formats to be developed. It also leaves the WG to decide the number and formats based on use-cases, or any other suitable criteria to be determined by the WG. I don’t see a problem here.]

The charter says

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

I would like to reiterate that it is quite important that this WG maintain relationships with the people who build and deploy the IOT devices as well. Hannes had the following proposal (https://www.ietf.org/mail-archive/web/suit/current/msg00249.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmail-archive%2Fweb%2Fsuit%2Fcurrent%2Fmsg00249.html&data=02%7C01%7Cdavid.waltermire%40nist.gov%7Cc88eb9b57db74b377cb408d5424f0340%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636487829480785367&sdata=nHBRpjsLmO%2FP7aKEX%2FyO4xh9ddRYfFs8jpCDLEHD%2BjM%3D&reserved=0>) and may we use the same ?

"This group will aim to maintain a close relationship with silicon vendors and OEMs that develop IoT operating systems. Additionally, the group will reach out to companies who build and deploy IoT devices."

[daw: Working with implementers and operators is something all IETF WGs should be doing. The chairs talked about this with Kathleen, and we didn’t think there was a strong need to reiterate this in the charter.]

I think the whole idea of multiple people signing is very unclear on the requirements and its applicability or its widespread use. Most common deployments today follow the model of single vendor signing. Would the WG be open to start with a simple permission model (single vendor based) that is readily applicable to majority of today deployments and possibly extend it as necessary.

[daw: This discussion topic needs to be addressed separate from the charter discussion, since the charter is silent on the specifics of this issue. This should be worked out with the group in a separate thread and the consensus can be documented in the requirements/architecture.]

On Mon, Dec 4, 2017 at 1:36 PM, Waltermire, David A. (Fed) <[email-masked]<mailto:[email-masked]>> wrote:
Kathleen, Dave, and I met earlier today to discuss the charter and the way forward. This email includes updated charter text and milestones, and a brief description of the changes we have made based on the input from the mailing list.

-- end charter text ---

Regards,

_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/suit<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cdavid.waltermire%40nist.gov%7Cc88eb9b57db74b377cb408d5424f0340%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636487829480785367&sdata=B0G%2F%2BL%2B3esLehSZTwOYZAUEurNGuyZmJjzgk%2BEqdJ6o%3D&reserved=0>