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

From: Brendan Moran <[email-masked]>
Date: Mon, 12 Jul 2021 19:48:58 +0000

As mentioned at the virtual interim, there was already some proposed charter text circulated. Here it is again:

To support the manifest format(s) defined by this group, it will also define formats and protocols that enable a Status Tracker to determine if a particular manifest could be successfully deployed to a device and determine if an operation was successful.

Specifications of names or numbers will enable the use of manifests, their precursors, and their successors within existing or future protocols.

This most immediate beneficiary of this charter text is draft-moran-suit-mud.

Given how trivial this draft is, I think it could have reasonably quick milestones, but it is, of course, dependent on draft-ietf-suit-manifest. I’d be appreciative of any suggestions on the timeline for this draft.

Best Regards,
Brendan

On 16 Feb 2021, at 22:39, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Brendan Moran <[email-masked]<mailto:[email-masked]>> wrote:
   bm> As a part of proposing several new drafts, I was asked to propose some new charter text that would enable the working group to address the new drafts.

   bm> The drafts in question are:

   bm> * draft-moran-suit-mud
   bm> * draft-moran-suit-report
   bm> * draft-birkholz-rats-suit-claims (TBD, maybe SUIT, maybe RATS)

As a RATS architecture editor, I prefer to do this document in SUIT.
Sure, RATS should be consulted, but the expertise in getting the claim
written right exists in SUIT, not RATS.

   bm> draft-moran-suit-mud proposes a method to anchor MUDs with the same
   bm> trust and fetch mechanisms as SUIT.

   bm> draft-moran-suit-report proposes a document format for reporting the
   bm> results of applying a SUIT update or secure execution using a SUIT
   bm> manifest.

   bm> draft-birkholz-rats-suit-claims proposes number assignments for EAT
   bm> claims that contain evidence generated during execution of a SUIT
   bm> manifest.

   bm> I would like to add a single paragraph to the charter:

To support the manifest format(s) defined by this group, it will also define
formats that enable precursor or successor operations around the use of
the manifests. Additional specifications of names or numbers will enable
the use of manifests, their precursors, and their successors within
existing or future protocols.

That seems like fine text.
I am not sure that an external reviewer will understand how it implies that
three documents are in scope.  It may be just too abstract for some IESG
members.  The trend seems to be that charters are very specific.
I think that the "precusor or successor operations" is the part that might be
too abstract.  Maybe that part should spell out what you want.

} To support the manifest format(s) defined by this group, it will also
} define formats and protocols that enable a Status Tracker to determine if a
} particular manifest could be successfully deployed to a device, and
} determine if an operation was successful.
} Additional specifications of names or numbers will enable the use of
} manifests, their precursors, and their successors within existing or future protocols.

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

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Russ Housley <[email-masked]>
Date: Mon, 12 Jul 2021 16:29:53 -0400

Milestone thoughts to promote discussion:

	Oct 2021		Adoption:

	Mar 2022		Request Publication on standards track

Russ

> On Jul 12, 2021, at 3:48 PM, Brendan Moran <[email-masked]> wrote:
> 
>> On 16 Feb 2021, at 22:39, Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> Brendan Moran <[email-masked] <mailto:[email-masked]>> wrote:
>> Michael Richardson <[email-masked] <mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit

---

From: Russ Housley <[email-masked]>
Date: Mon, 12 Jul 2021 16:43:39 -0400

Putting the text provided by Brendan and a bit of context to the work that has alrady been done by the WG, I propose the following re-charter text.

Review and comment most welcome.

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

The SUIT WG was already completed work on two documents:
* An IoT firmware update architecture that includes a description of the
  involved entities, security threats, and assumptions.
* An information model for the SUIT manifest.

Now that the information model is complete, the SUIT WG will has selected the
CBOR serialization formats 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 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.

The SUIT WG does not aim to create a standard for a generic application
software update mechanism, but instead the SUIT WG 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.

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

The SUIT WG will specify names or numbers will enable the use of SUIT
manifests, their precursors, and their successors within existing or future
protocols.

The SUIT WG will aim to maintain a close relationship with silicon vendors and
OEMs that develop IoT operating systems.

The SUIT WG aims to publish several additional documents, namely:
* A SUIT manifest format specification using CBOR.
* A firmware encryption specification for use with SUIT manifests.
* A secure for IoT device to reporting on firmware update status.
* A SUIT manifest extension to include a MUD file as defined in RFC 8520.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Jul 2021 21:06:35 -0400

Russ Housley <[email-masked]> wrote:
    > Putting the text provided by Brendan and a bit of context to the work
    > that has alrady been done by the WG, I propose the following re-charter
    > text.

I guess my only comment is that the wording and the tense does not reflect
the work that has already been done.

    } The SUIT WG has focused on defining a firmware update solution,
    } that took into account learnings from RFC 4108 and other proprietary
    } firmware update solutions. The solution is usable on Class 1 (as defined
    } in RFC 7228) devices, i.e., devices with ~10 KiB RAM and ~100 KiB
    } flash.  The solution easily applies to more capable devices as well.  The
    } SUIT WG has not defined any new transport or discovery mechanisms, but
    } is still considering how to use existing mechanisms within the architecture.

...

    > The SUIT WG was already completed work on two documents: * An IoT
    > firmware update architecture that includes a description of the
    > involved entities, security threats, and assumptions.  * An information
    > model for the SUIT manifest.

    } Now that the information model is complete, and the SUIT WG has
    } selected the CBOR serialization formats and the associated COSE
    } cryptographic mechanisms to encode the SUIT manifest, the SUIT WG will
    } now 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 support a wide range of
    } deployment scenarios, the formats have been designed to be expressive enough
    } to allow the use of different firmware sources and permission models.

no change:
    > software update mechanism, but instead the SUIT WG 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.

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

:
    > manifests, their precursors, and their successors within existing or
    > future protocols.

I don't know what this means anymore.

    } The SUIT WG continutes to maintain a close relationship with silicon
    } vendors and OEMs that develop IoT operating systems.

    > The SUIT WG aims to publish several additional documents, namely: * A
    > SUIT manifest format specification using CBOR.  * A firmware encryption
    > specification for use with SUIT manifests.  * A secure for IoT device
    > to reporting on firmware update status.  * A SUIT manifest extension to
    > include a MUD file as defined in RFC 8520.

Maybe past tense for some of these?

I think that at this point, we need some explanation of why the WG isn't done
yet.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

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

---

From: Dave Thaler <[email-masked]>
Date: Fri, 16 Jul 2021 15:52:29 +0000

Michael Richardson wrote:

Sure, RATS should be consulted, but the expertise in getting the claim written right exists in SUIT, not RATS.

[dt] there are two parts of draft-birkholz-rats-suit-claims.

Section 3.1 contains things that are not SUIT specific and should be merged into the EAT document.

The TEEP protocol for example uses them directly, and would even if it didn’t use SUIT.

Section 3.2 contains things that are SUIT specific and I agree putting them in SUIT would be appropriate.

    bm> manifest.

    bm> manifest.

I am not sure that an external reviewer will understand how it implies that three documents are in scope.  It may be just too abstract for some IESG members.  The trend seems to be that charters are very specific.

I think that the "precusor or successor operations" is the part that might be too abstract.  Maybe that part should spell out what you want.

The AD’s suggested phrase to the chairs back in December was along the idea of
“developing and publishing mechanisms to enable SUIT integration and interoperability with other IoT technologies and ecosystems”.
And I think that phrasing would be helpful.

Does anyone else have comments?

Dave

} To support the manifest format(s) defined by this group, it will also } define formats and protocols that enable a Status Tracker to determine if a } particular manifest could be successfully deployed to a device, and } determine if an operation was successful.

} Additional specifications of names or numbers will enable the use of } manifests, their precursors, and their successors within existing or future protocols.

--

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Fri, 16 Jul 2021 16:19:29 +0000

Michael,

I like and agree with most of what Russ has proposed. I believe it is important to reflect that work that has been done, what work remains, and what new work is added. This will help the IESG evaluate the charter changes, and will help new participants in the WG to understand where we are in the effort.

I concur with your comments regarding tense. I like the changes you are suggesting.

I am on the fence about leaving in the charter the statement about "The SUIT WG continues to maintain a close relationship with silicon vendors and OEMs that develop IoT operating systems." This was important initially because there was prior work to consider and the need to have these stakeholders implement what we have produced. We have had a good deal of success in generating implementations through hackathon and external efforts. Perhaps we should replace this text with something that states that we will continue to do this?

Maybe:

} The SUIT WG will continue to work with silicon vendors and OEMs that develop IoT operating systems to produce implementations based on SUIT-related specifications (i.e., Hackathons).

Dave

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Michael Richardson
Sent: Monday, July 12, 2021 9:07 PM
To: Russ Housley <[email-masked]>; suit <[email-masked]>
Subject: Re: [Suit] SUIT rechartering: proposed text

    > that has alrady been done by the WG, I propose the following re-charter

I guess my only comment is that the wording and the tense does not reflect the work that has already been done.

...

I think that at this point, we need some explanation of why the WG isn't done yet.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&amp;data=04%7C01%7Cdavid.waltermire%40nist.gov%7C3f83e01e7cc44561f92708d9459aa2dc%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637617352731763505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=1EjH4tH425e8qp7lO3hxYVwtz9lQtFdoFQfzASfOES4%3D&amp;reserved=0        |   ruby on rails    [

---

From: Russ Housley <[email-masked]>
Date: Tue, 20 Jul 2021 11:13:09 -0400

I have tried to address the comments from Michael, Dave T., and Dave W.  The biggest change is int inclusion to an additional document for set of claims related for attesting to firmware update status.  This covers the SUIT-related claims that ware currently being considered in the RATS WG.

Please review and comment.

Russ

= = = = = = = 

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 that includes a description of the
  involved entities, security threats, and assumptions.
* 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.

The SUIT WG does not aim to create a standard for a generic application
software update mechanism, but instead the SUIT WG is focusing 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.

To support the SUIT manifest format, the SUIT WG is also defining formats and
protocols 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 specify claims related to the SUIT Status Tracker
that can be used to provide evidence in support of the architecture 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.
* A firmware encryption specification for use with SUIT manifests.
* A secure for IoT device to reporting on firmware update status.
* A set of claims related for attesting to firmware update status.
* A SUIT manifest extension to include a MUD file as defined in RFC 8520.

---

From: Dave Thaler <[email-masked]>
Date: Fri, 23 Jul 2021 16:27:01 +0000

> * A secure for IoT device to reporting on firmware update status.

I can't parse the above bullet, maybe a word missing right before "for IoT device"?

> * A set of claims related for attesting to firmware update status.

Remove "related".

Dave

---

From: Russ Housley <[email-masked]>
Date: Fri, 23 Jul 2021 13:54:02 -0400

Dave:

> > …
> I can’t parse the above bullet, maybe a word missing right before “for IoT device”?

Yep, that is messed up.  How about:

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

> Remove “related”.

Yep.

Russ

---

From: Dave Thaler <[email-masked]>
Date: Fri, 23 Jul 2021 18:02:58 +0000

Agree with those fixes.
Thanks Russ.

From: Russ Housley <[email-masked]>
Sent: Friday, July 23, 2021 10:54 AM
To: Dave Thaler <[email-masked]>
Cc: suit <[email-masked]>
Subject: Re: [Suit] SUIT rechartering: proposed text

Remove “related”.

Yep.

Russ

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Sat, 24 Jul 2021 12:00:48 +0000

The charter is looking great with these changes!

Dave

-------- Original Message --------
From: Suit <[email-masked]> on behalf of Dave Thaler <dthaler=[email-masked]>
Date: Fri, July 23, 2021 2:05 PM -0400
To: Russ Housley <[email-masked]>
CC: suit <[email-masked]>
Subject: Re: [Suit] SUIT rechartering: proposed text

Agree with those fixes.
Thanks Russ.

Remove “related”.

Yep.

Russ

---

From: Michael Richardson <[email-masked]>
Date: Sat, 24 Jul 2021 10:31:15 -0400

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

That sounds like it would definitely solve the issues that Brendon has been
worried about.

    >> > * A set of claims related for attesting to firmware update status.

So, how do the two points/goals differ?

I can think of ways to securely report firmware update status that do not
involve attesting, but if you do attesting (b), then you definitely do (a), right?

---

From: Dave Thaler <[email-masked]>
Date: Sat, 24 Jul 2021 17:33:20 +0000

Michael Richardson <[email-masked]>  wrote:
> That sounds like it would definitely solve the issues that Brendon has been worried about.
>
> > * A set of claims for attesting to firmware update status.
>
> I can think of ways to securely report firmware update status that do not involve attesting, but if you do attesting (b), then you definitely do (a), right?

You can attest to current state without attesting to the errors that happened the last time you tried to install something.
(If the errors happened during boot then they may be reported, but post-boot install errors might not be.)

And as you mentioned, you can report status (and errors) without attesting.
So I think they're complementary items that will often but not always be used together.

Dave

---

From: Michael Richardson <[email-masked]>
Date: Sat, 24 Jul 2021 15:08:05 -0400

Dave Thaler <dthaler=[email-masked]> wrote:
    >> I can think of ways to securely report firmware update status that do
    >> not involve attesting, but if you do attesting (b), then you definitely
    >> do (a), right?

    > You can attest to current state without attesting to the errors that
    > happened the last time you tried to install something.

I agree.
So (a) involves providing feedback on failed attempts to upgrade.

    > So I think they're complementary items that will often but not always

I understand now.

---

From: Russ Housley <[email-masked]>
Date: Sat, 31 Jul 2021 16:57:04 -0400

Based on the discussion at IETF 111, I have updated the DRAFT re-charter text.

Russ

= = = = = = =

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

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.

* Extensions to the SUIT manifest for optional capabilities, including
  firmware encryption.

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