Subject: Re: [Suit] SUIT rechartering: proposed text

From: Russ Housley <[email-masked]>
Date: Sun, 31 Oct 2021 16:27:00 -0400

Dear SUIT WG:

I have not seen any new comments since August.  I would like to send this to the IESG.  Any last minute concerns?

For the WG Chairs,
  Russ

= = = = = = = =

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 no modern interoperable
approach allowing secure updates to firmware in IoT devices. In June 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.

The SUIT WG is defining a firmware update solution (taking into account past
learnings from RFC 4108 and other proprietary firmware update solutions) that
are 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.  The SUIT WG is not defining any new transport or discovery mechanisms,
but may describe how to use existing mechanisms within the architecture.

The SUIT WG has already completed work on two documents:
* An IoT firmware update architecture.
* An information model for the SUIT manifest.

Now that the information model is complete, the SUIT WG has selected the CBOR
serialization format and the associated COSE cryptographic mechanisms to
encode the SUIT manifest. The SUIT WG may consider a small number of additional
formats in the future; however, to reduce the complexity of a firmware
management solution, a very small number of formats is preferred to enable SUIT
maifest integration and interoperability with other IoT technologies and
ecosystems.  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.

To support the SUIT manifest format, the SUIT WG is also defining formats
that enable a SUIT Status Tracker to determine if a particular manifest
could be successfully deployed to a device and determine if an operation
was successful.

In addition, the SUIT WG will work with the RATS WG to specify claims related
to the SUIT Status Tracker that can be used to provide evidence in support of
the architecture that has already been defined by the RATS WG.

The SUIT WG will continue to work with silicon vendors and OEMs that
develop IoT operating systems to produce implementations based on SUIT
WG specifications.  In particular, the SUIT WG plans to continue to
participate in IETF Hackathons.

The SUIT WG document deliverables are:
* A SUIT manifest format specification using CBOR.
* Extensions to the SUIT manifest for optional capabilities, including
  firmware encryption.
* A secure method for an IoT device to report on firmware update status.
* A SUIT manifest extension to include a MUD file as defined in RFC 8520.

In addition, either the SUIT WG or the RATS WG will produce:
* A set of claims for attesting to firmware update status.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 31 Oct 2021 18:09:47 -0400

Russ Housley <[email-masked]> wrote:
    > I have not seen any new comments since August.  I would like to send
    > this to the IESG.  Any last minute concerns?

I remember that, I remember asking for past-tense on completed items.
I see that in the text.  I am happy with the changes.

> * A secure method for an IoT device to report on firmware update status.

I'm unclear if we have proposals for this at this point.

I also thought that transports for firmware updates would be in scope after the
core work was done.

There is really good work done by Cenk Gündoğan,Christian Amsüss,Thomas
C. Schmidt, and Matthias Wählisch.  https://arxiv.org/pdf/2108.09555.pdf
It was presented at the CORE virtual interim two weeks ago.
(I think. Maybe I'm confused.)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Dave Thaler <[email-masked]>
Date: Sun, 31 Oct 2021 22:40:55 +0000

As an individual, I think it's ready.  As a co-chair, I'm listening if anyone else
has edits or concerns.

To respond to Michael: As for report on firmware update status,
we have https://datatracker.ietf.org/doc/draft-ietf-suit-report/
which is already a WG document.

Dave

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Michael Richardson
Sent: Sunday, October 31, 2021 3:10 PM
To: Russ Housley <[email-masked]>; suit <[email-masked]>
Subject: Re: [Suit] SUIT rechartering: proposed text

I also thought that transports for firmware updates would be in scope after the core work was done.

There is really good work done by Cenk Gündoğan,Christian Amsüss,Thomas C. Schmidt, and Matthias Wählisch.  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Farxiv.org%2Fpdf%2F2108.09555.pdf&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C6253df2eb3c9439cdb4d08d99cbb3108%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637713150562408565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=TRoKEsSlYIjcPXJxl%2Bq8wTEc%2BO7Ps1%2F5EA4cZ5SyAM4%3D&amp;reserved=0
It was presented at the CORE virtual interim two weeks ago.
(I think. Maybe I'm confused.)

---

From: Michael Richardson <[email-masked]>
Date: Sun, 31 Oct 2021 19:02:52 -0400

> which is already a WG document.

This is a data format, but lacks a transport, or a security model.

I think that it should be interacting with (i.e. being embedded in) the RATS
integration and/or the SBOM report in order for this to get signed.

    mcr> I also thought that transports for firmware updates would be in
    mcr> scope after the core work was done.