Re: [Suit] SUIT rechartering: proposed text

[Roman Danyliw <[e-mail]>]

Hi!

To make it easier to reference it and perform diffs against prior text, I've upload the charter text from the WG into the datatracker.  

For the full text, see https://datatracker.ietf.org/doc/charter-ietf-suit/

For the diff from the last approved charter, see https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-suit%2Fwithmilestones-01.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-suit%2Fwithmilestones-01-00.txt

I support the spirit of the additional scope.  We need tighten up some of the language to get it through the review process.

(a) Editorial.  Be clearer on the motivation.

OLD
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.

NEW
To enable the SUIT Status Tracker, 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.

(b) We need to be consistent on the approach taken to describe the scope of extensions.  Specifically:

-- We have both a generic clause for scope on "Extensions to the SUIT manifest for optional capabilities ...", but then the bullet concludes with a specific instance with " ... including firmware encryption".

-- There is a stand-alone bullet on making a MUD extension, "A SUIT manifest extension to include a MUD file as defined in RFC 8520"

Should we have both caveated support of optional capabilities?  Is there a threshold we need, say "... when there is broad applicability"?  or limited to specific applications/utility?

Should we enumerate the extensions were already want to work on here (firmware encryption, MUD, Software IDs/SBOM, multiple trust domains?)

(c) Should be provide a milestone for deciding on where the joint RATS-SUIT work will happen?

(d) We also need milestones for the new scope.  Judging from what's in the current document list (https://datatracker.ietf.org/wg/suit/documents/) is that:

(previously defined, still open milestone)
Feb 2022  Submit an initial manifest serialization format to the IESG for publication as a Proposed Standard.

(new milestones)
MMM-YYYY Submit a SUIT Manifest firmware encryption extension document to the IESG for publication as a Proposed Standard (draft-ietf-suit-firmware-encryption)
MMM-YYYY Submit a SUIT ??? (draft-ietf-suit-report-00)
MMM-YYYY Submit a SUIT Manifest MUD extension document to the IESG for publication as a Proposed Standard (draft-moran-suit-mud)
MMM-YYYY Submit a SUIT Manifest extension that enables support for multiple domains document to the IESG for publication as a Proposed Standard (draft-moran-suit-trust-domains)
MMM-YYYY Submit a SUIT Manifest extension for ??? to the IESG for publication as a Proposed Standard (draft-moran-suit-update-management)

The currently unadopted document could also have a corresponding milestone of "Adopt ..."

Regards,
Roman

> -----Original Message-----
> From: Suit <[e-mail]> On Behalf Of Russ Housley
> Sent: Sunday, October 31, 2021 4:27 PM
> To: suit <[e-mail]>
> Subject: Re: [Suit] SUIT rechartering: proposed text
> 
> 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.
> 
> _______________________________________________
> Suit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/suit