Subject: [Suit] WG Action: Rechartered Software Updates for Internet of Things (suit)

From: The IESG <[email-masked]>
Date: Fri, 17 Dec 2021 10:33:19 -0800

The Software Updates for Internet of Things (suit) WG in the Security Area of
the IETF has been rechartered. For additional information, please contact the
Area Directors or the WG Chairs.

Software Updates for Internet of Things (suit)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
  Dave Thaler <[email-masked]>
  David Waltermire <[email-masked]>
  Russ Housley <[email-masked]>

Assigned Area Director:
  Roman Danyliw <[email-masked]>

Security Area Directors:
  Benjamin Kaduk <[email-masked]>
  Roman Danyliw <[email-masked]>

Mailing list:
  Address: [email-masked]
  To subscribe: https://www.ietf.org/mailman/listinfo/suit
  Archive: https://mailarchive.ietf.org/arch/search/?email_list=suit

Group page: https://datatracker.ietf.org/group/suit/

Charter: https://datatracker.ietf.org/doc/charter-ietf-suit/

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
learning 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 enable SUIT Status Tracker functionality (per RFC9019), the SUIT WG is
also defining extensions 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 RATS architecture.

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,
  - trust domains,
  - update management, and
  - inclusion of a file in the MUD format (RFC 8520).
* A secure method for an IoT device to report on firmware update status.

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

Milestones:

  Dec 2021 - Adopt SUIT Manifest update management document as WG item

  Dec 2021 - Adopt SUIT Manifest trust domains document as WG item

  Dec 2021 - Adopt SUIT Manifest MUD extension document as WG item

  Mar 2022 - Decide with RATS WG in which working group the 'set of claims
  for attesting to firmware update status' document should be produced

  Aug 2022 - Submit firmware encryption document to the IESG for publication
  as a Proposed Standard

  Sep 2022 - Submit SUIT Status Tracker document to the IESG for publication
  as a Proposed Standard

  Nov 2022 - Submit SUIT Manifest update management document to the IESG for
  publication as a Proposed Standard

  Nov 2022 - Submit SUIT Manifest trust domains document to the IESG for
  publication as a Proposed Standard

  Dec 2022 - Submit SUIT Manifest MUD extension document to the IESG for
  publication as a Proposed Standard

---

From: Russ Housley <[email-masked]>
Date: Wed, 22 Dec 2021 17:14:36 -0500

Brendan:

We were trying to do things in parallel.  Now that the re-charter is approved, the adoption of the MUD document can take place.  Please post draft-ietf-suit-mud-00.
 
For the SUIT WG Chairs,
   Russ

> On Dec 17, 2021, at 1:33 PM, The IESG <[email-masked] <mailto:[email-masked]>> wrote:
> 
> The Software Updates for Internet of Things (suit) WG in the Security
> Area of the IETF has been rechartered. For additional information,
> please contact the Area Directors or the WG Chairs.
> 
>  Dave Thaler <[email-masked] <mailto:[email-masked]>>
>  David Waltermire <[email-masked] <mailto:[email-masked]>>  Russ Housley
> <[email-masked] <mailto:[email-masked]>>
> 
> Assigned Area Director:
>  Roman Danyliw <[email-masked] <mailto:[email-masked]>>
> 
> Security Area Directors:
>  Benjamin Kaduk <[email-masked] <mailto:[email-masked]>>
>  Roman Danyliw <[email-masked] <mailto:[email-masked]>>
> 
> Mailing list:
>  Address: [email-masked] <mailto:[email-masked]>
>  To subscribe: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww>.
> ietf.org <http://ietf.org/>%2Fmailman%2Flistinfo%2Fsuit&amp;data=04%7C01%7Cdthaler%40micr
> osoft.com <http://osoft.com/>%7C72a959d09aa84170b33f08d9c18e8aaa%7C72f988bf86f141af91ab2d7
> cd011db47%7C1%7C0%7C637753640242000556%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp
> ;sdata=6V6lh1wdN%2FMIroEcyAt3So2A8ifE46sWFDNMxebzS58%3D&amp;reserved=0
>  Archive: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail>
> archive.ietf.org <http://archive.ietf.org/>%2Farch%2Fsearch%2F%3Femail_list%3Dsuit&amp;data=04%7C
> 01%7Cdthaler%40microsoft.com <http://40microsoft.com/>%7C72a959d09aa84170b33f08d9c18e8aaa%7C72f9
> 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753640242000556%7CUnknown%7C
> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> I6Mn0%3D%7C3000&amp;sdata=7kAfFvfyMR7y1RSEsSVPVkqlLrxuSpA4J6Ejrc%2FOlk
> g%3D&amp;reserved=0
> 
> Group page: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata>
> tracker.ietf.org <http://tracker.ietf.org/>%2Fgroup%2Fsuit%2F&amp;data=04%7C01%7Cdthaler%40micros
> oft.com <http://oft.com/>%7C72a959d09aa84170b33f08d9c18e8aaa%7C72f988bf86f141af91ab2d7cd
> 011db47%7C1%7C0%7C637753640242000556%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;s
> data=nykpu2G3gJbI0uQGo1bnaM6uo8fTN3yJyxdjcWiwlZw%3D&amp;reserved=0
> 
> Charter: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata>
> tracker.ietf.org <http://tracker.ietf.org/>%2Fdoc%2Fcharter-ietf-suit%2F&amp;data=04%7C01%7Cdthal
> er%40microsoft.com <http://40microsoft.com/>%7C72a959d09aa84170b33f08d9c18e8aaa%7C72f988bf86f141
> af91ab2d7cd011db47%7C1%7C0%7C637753640242000556%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000&amp;sdata=YnBkFLPYC5Nld83i1STFJnDUDNgmkiy3JCa3JQfwEfA%3D&amp;res
> erved=0
> 
> 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 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 SUIT WG is defining a firmware update solution (taking into
> account past learning 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.
> 
> 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 enable SUIT Status Tracker functionality (per RFC9019), the SUIT WG
> is also defining extensions 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 RATS architecture.
> 
> 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.
> 
>  Mar 2022 - Decide with RATS WG in which working group the 'set of
> claims  for attesting to firmware update status' document should be
> produced
> 
>  Aug 2022 - Submit firmware encryption document to the IESG for
>  Sep 2022 - Submit SUIT Status Tracker document to the IESG for
>  Nov 2022 - Submit SUIT Manifest update management document to the
> IESG for  publication as a Proposed Standard
> 
>  Nov 2022 - Submit SUIT Manifest trust domains document to the IESG
> for  publication as a Proposed Standard
> 
>  Dec 2022 - Submit SUIT Manifest MUD extension document to the IESG
> for  publication as a Proposed Standard
>