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

From: Roman Danyliw <[email-masked]>
Date: Fri, 5 Nov 2021 13:23:55 +0000

Hi Michael!

> -----Original Message-----
> From: Suit <[email-masked]> On Behalf Of Michael Richardson
> Sent: Sunday, October 31, 2021 7:03 PM
> To: suit <[email-masked]>
> Subject: Re: [Suit] SUIT rechartering: proposed text
> 
> 
> Dave Thaler <[email-masked]> wrote:
>     > 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.
> 
> 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.

Is that a charter or document feedback?

Regards,
Roman

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 5 Nov 2021 15:31:04 +0000

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

> From: Suit <[email-masked]> On Behalf Of Russ Housley
> Sent: Sunday, October 31, 2021 4:27 PM
> To: suit <[email-masked]>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit

---

From: Russ Housley <[email-masked]>
Date: Fri, 5 Nov 2021 12:24:49 -0400

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

Thanks.

> 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 success…

This seems fine to me.

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

At the time that this text was crafted, we did not know how the extensions would get broken up.  We have a first cut at that now, but I think that the base text should allow for further reorganization.

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 MUD file as defined in RFC 8520.
* A secure method for an IoT device to report on firmware update status.

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

I think we can add a milestone if the work lands in SUIT.  I'm guessing it will land in RATS with review in SUIT.

> (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:

I think that you missed that some of the "Done" milestones are new:

   Done      Adopt firmware encryption document as WG item.
   Done      Adopt SUIT Status Tracker document as WG item.

These were already adopted because they fit the old charter, but we failed to create milestones at that time.

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

Sorry, that was a cut-and-paste error on my part:

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.

Feb 2022  Submit an initial manifest serialization format to the IESG for publication as a Proposed Standard.
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.

Thanks,
  Russ

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Nov 2021 14:01:36 -0400

> Is that a charter or document feedback?

Good question.

We have two transport issues: getting images to devices, and getting status
back from the devices.

The architecture document speaks of status trackers as well as distribution
systems, and I understand that in some deployments this is already a
thing. In other places, there is nothing. (or nothing standard)

draft-ietf-suit-report provides a standard content for reporting.
It does not provide a transport to communicating that report to a status tracker.

The ICN work that I mentioned in the thread is a really good standards based
greenfield solution for distribution.   We should adopt that work and
standardize it as an option for those who have nothing else.
At the other end of the spectrum, we'll have devices that will do https:// to
the cloud to yank their image.

Many people would like some intermediate situations to save bandwidth and
speed up deployment:  it could be as simple as HTTP-authenticated https:
proxy to a port 3128 squid3 cache.

Even with all that work, we are lacking a standard status tracker and
transport for this suit-report.

So you are asking: is the problem that the charter isn't simple enough that
suit-report would satisfy it, or is suit-report not tall enough to satisfy
the charter.

My opinion is neither: there is a document missing, and perhaps the charter
needs to more explicitely say that.

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

---

From: Michael Richardson <[email-masked]>
Date: Sat, 06 Nov 2021 18:11:46 -0400

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

I found *the* SUIT Status Tracker jarring.
It sounds like we have a normative document that describes that, while I
thought that was had a palette of existing systems.

Maybe:

+ To enable SUIT Status Tracker functionality, the SUIT WG is also defining extensions...

{having said this, I do think that we should eventually have a greenfield
solution fully defined in RFCs}

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 8 Nov 2021 14:20:43 +0000

Hi Russ!

> From: Russ Housley <[email-masked]>
> Sent: Friday, November 5, 2021 12:25 PM
> To: Roman Danyliw <[email-masked]>
> Cc: suit <[email-masked]>
> > 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%2
> > Fdoc%2Fcharter-ietf-suit%2Fwithmilestones-
> 01.txt&url2=https%3A%2F%2Fda
> > tatracker.ietf.org%2Fdoc%2Fcharter-ietf-suit%2Fwithmilestones-01-00.tx
> > t
> >
> > I support the spirit of the additional scope.  We need tighten up some of the
> language to get it through the review process.
> 
> Thanks.
> 
> > 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.
> 
> This seems fine to me.

Merged into v01-01

> > -- 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?)
> 
> At the time that this text was crafted, we did not know how the extensions
> would get broken up.  We have a first cut at that now, but I think that the base
> text should allow for further reorganization.
> 

Merged into v01-01

> land in RATS with review in SUIT.

I was envisioning a milestone for the decision to do the work in RATS vs. SUIT, not a milestone for the work itself.  For example:

"XXX-2022  Decide with RATS WG on where the 'set of claims for attesting to firmware update status' document should be produced"

> > (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:
> 

These are merged into the live WG milestones.

> > (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)
> >

Add to v01-01 charter.

> publication as a Proposed Standard.

Added to the live (current) charter as this is prior work with a new date.

> publication as a Proposed Standard.

Add to v01-01 charter.

Regards,
Roman

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 8 Nov 2021 14:22:35 +0000

Hi Michael!

> Sent: Saturday, November 6, 2021 6:12 PM
> To: suit <[email-masked]>
> > 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.
> 

Merged it into v01-02.  

> {having said this, I do think that we should eventually have a greenfield solution
> fully defined in RFCs}

I can see that.  I think we should leave that to the WG to talk through in parallel to starting the work.

Regards,
Roman

---

From: Russ Housley <[email-masked]>
Date: Mon, 8 Nov 2021 13:02:38 -0500

> "XXX-2022  Decide with RATS WG on where the 'set of claims for attesting to firmware update status' document should be produced"

Based on the discussion on the call today, Mar 2022 seems like a good date for that milestone.

Russ

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 8 Nov 2021 18:40:13 +0000

Hi Russ!

> Sent: Monday, November 8, 2021 1:03 PM
> >>> (c) Should be provide a milestone for deciding on where the joint
> >>> RATS-SUIT
> >> work will happen?
> >>
> >> I think we can add a milestone if the work lands in SUIT.  I'm
> >> guessing it will land in RATS with review in SUIT.
> >
> > I was envisioning a milestone for the decision to do the work in RATS vs. SUIT,
> not a milestone for the work itself.  For example:
> >
> > "XXX-2022  Decide with RATS WG on where the 'set of claims for attesting to
> firmware update status' document should be produced"
> 

Thanks for closing the loop.  Based on the WG discussion today, I've already made the addition and have the charter up for initial review by the IESG on the next telechat, December 2, 2021.

Roman