Subject: [Suit] SUIT Architecture document review

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 8 Oct 2019 19:14:48 -0400

Hello,

I know I am late with a review, but since it has not gone to IETF last call
yet, I'd like to submit these comments.  I know another version is expected
soon, so some of these comments/nits may have been addressed already.

The document as a whole reads very well, thanks for all your work on it.  I
do hope it enjoys wide adoption.

Abstract:
I thought one of the goals was to update firmware for IoT, but also to
scale up to larger systems as well.  The abstract seems very specific to
constrained devices.  Should the language be adjusted or has the focus
changed?

Introduction:
If the scope does include larger devices, then this is a problem for them
as well for both security and inconsistency across platforms.  It's harder
than it needs to be and that's amplified when you think about IoT.

Section 2:
For the Firmware definition, is the last sentence referring to both
"firmware" and "image" as interchangeable or something else?  I think
adjusting the last couple of sentences may be helpful to some readers.

Section 3.2:
If not link, network, or transport layer security, what does this rely
upon?  If it is object-level security and I am assuming it is, please
state that explicitly possibly referring to where confidentiality
protection is specified.

Section 3.3:

Current text:
"The use of post-quantum secure signature mechanisms, such as hash-
   based signatures, should be explored."
Since this is the architecture document, if they are defined elsewhere, the
document should point to that rather than saying "should be explored".

Some other well received architecture documents provided pointers to the
related documents that filled out stated components of the architecture.
If the WG were to hold this to be published until other document were
complete, this could provide the same mapping between the requirements,
architecture, and implementation of the architecture with the various
specifications.

Section 3.6
I think this is the first time "fw" is used.  Maybe just spell out firmware
with a search and replace?

Section 3.11:
Typo in the following sentence:
   "TEEs may obtain TAs from different authors and those TAs may
   require personalization data, such as payment information, to be
   securely be conveyed to the TEE."
s/to be securely be conveyed/to be securely conveyed/

Section 4;
Typo in the following sentence:
   "The credential used to must be directly or indirectly
   related to the trust anchor installed at the device by the Trust
   Provisioning Authority."
s/The credential used to must/The credential used must/

Section 8
This says downloads can be large, so I think that's to accommodate more
than IoT, is that right and the abstract/intro can be updated?

The following sentence is readable, but super long:
   If the application image contains the firmware consumer
   functionality, as described above, then it is necessary that a
   working image is left on the device to ensure that the bootloader can
   roll back to a working firmware image to re-do the firmware download
   since the bootloader itself does not have enough functionality to
   fetch a firmware image plus manifest from a firmware server over the
   Internet.
Perhaps break it up?

Security considerations:
Should this mention the end-to-end encryption?  Is it provided at the
object level?

Also, if the intent is to scale above constrained devices, the text should
state that as this section also specifies IoT.

Thank you for all of your work on the document.  It's easy to read and
comprehensive.

Best regards,
Kathleen

---

From: Dave Thaler <[email-masked]>
Date: Tue, 8 Oct 2019 23:33:56 +0000

Thanks Kathleen, I added this as a github issue on the doc:
https://github.com/suit-wg/architecture/issues/5

Dave

From: Suit <[email-masked]> On Behalf Of Kathleen Moriarty
Sent: Tuesday, October 8, 2019 4:15 PM
To: [email-masked]
Subject: [Suit] SUIT Architecture document review

Hello,

I know I am late with a review, but since it has not gone to IETF last call yet, I'd like to submit these comments.  I know another version is expected soon, so some of these comments/nits may have been addressed already.

The document as a whole reads very well, thanks for all your work on it.  I do hope it enjoys wide adoption.

Abstract:
I thought one of the goals was to update firmware for IoT, but also to scale up to larger systems as well.  The abstract seems very specific to constrained devices.  Should the language be adjusted or has the focus changed?

Introduction:
If the scope does include larger devices, then this is a problem for them as well for both security and inconsistency across platforms.  It's harder than it needs to be and that's amplified when you think about IoT.

Section 2:
For the Firmware definition, is the last sentence referring to both "firmware" and "image" as interchangeable or something else?  I think adjusting the last couple of sentences may be helpful to some readers.

Section 3.2:
If not link, network, or transport layer security, what does this rely upon?  If it is object-level security and I am assuming it is, please state that explicitly possibly referring to where confidentiality protection is specified.

Section 3.3:

Current text:
"The use of post-quantum secure signature mechanisms, such as hash-
   based signatures, should be explored."
Since this is the architecture document, if they are defined elsewhere, the document should point to that rather than saying "should be explored".

Some other well received architecture documents provided pointers to the related documents that filled out stated components of the architecture.  If the WG were to hold this to be published until other document were complete, this could provide the same mapping between the requirements, architecture, and implementation of the architecture with the various specifications.

Section 3.6
I think this is the first time "fw" is used.  Maybe just spell out firmware with a search and replace?

Section 3.11:

Section 4;

Section 8
This says downloads can be large, so I think that's to accommodate more than IoT, is that right and the abstract/intro can be updated?

Security considerations:
Should this mention the end-to-end encryption?  Is it provided at the object level?

Also, if the intent is to scale above constrained devices, the text should state that as this section also specifies IoT.

Thank you for all of your work on the document.  It's easy to read and comprehensive.

Best regards,
Kathleen

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 Oct 2019 09:13:56 +0000

Hi Kathleen,

Thanks for the review.
A few remarks below:

Abstract:
I thought one of the goals was to update firmware for IoT, but also to scale up to larger systems as well.  The abstract seems very specific to constrained devices.  Should the language be adjusted or has the focus changed?
[Hannes] When you say “larger systems” what do you mean? There are Windows, Linux and mobile devices out there that already have a perfectly fine software update mechanism and we are not trying to replace it with this work. For those devices that run regular operating systems the lightweight design of the software update mechanism is apparently less of a concern compared to the design of a firmware update mechanism for low end IoT devices, as you have witnessed in the discussions on this list. When you say “large system” are you then referring to a system that runs Windows, Linux or something similar or do you have some other system in mind?

Introduction:

[Hannes] See above.

Section 2:

[Hannes] Corrected the definition to refer to firmware image, firmware, and image.

Section 3.2:

[Hannes] Clarified that we are talking about protecting the manifest and firmware rather than the underling transport of them. Here is the new text I came up with:

------

## Friendly to broadcast delivery

This architecture does not specify any specific broadcast protocol.
However, given that broadcast may be desirable for some networks,
updates must cause the least disruption possible both in metadata
and firmware transmission.

For an update to be broadcast friendly, it cannot rely on link
layer, network layer, or transport layer security. A solution has
to rely on security protection applied to the manifest and firmware image
instead. In addition,
the same manifest must be deliverable to many devices, both those
to which it applies and those to which it does not, without a
chance that the wrong device will accept the update. Considerations
that apply to network broadcasts apply equally to the use of
third-party content distribution networks for payload distribution.

------

Section 3.3:

Current text:

[Hannes] I changed the text in the following way:

------

## Use state-of-the-art security mechanisms

End-to-end security between the author and the device is shown in
{{architecture}}.

Authentication ensures that the device can cryptographically identify
the author(s) creating firmware images and manifests. Authenticated
identities may be used as input to the authorization process.

Integrity protection ensures that no third party can modify the manifest
or the firmware image.

For confidentiality protection of the firmware image, it must be done in such a
way that every intended recipient can decrypt it. The information
that is encrypted individually for each device must maintain
friendliness to Content Distribution Networks, bulk storage, and
broadcast protocols.

A manifest specification must support different cryptographic algorithms
and algorithm extensibility. Because of the nature of
unchangeable code in ROM for use with bootloaders the use of
post-quantum secure signature mechanisms, such as hash-based
signatures {{I-D.ietf-cose-hash-sig}}, are attractive because they
maintain security in presence of quantum computers.

A mandatory-to-implement set of algorithms has to be defined offering
a key length of 112-bit symmetric key or security or more, as outlined
in Section 20 of RFC 7925 {{RFC7925}}. This corresponds to a 233 bit
ECC key or a 2048 bit RSA key.
------

Section 3.6

[Hannes] Changed the figure where I abbreviated “Firmware Consumer” with “fw consumer”.

Section 3.11:

[Hannes] Fixed.

Section 4;

[Hannes] Fixed.

Section 8

[Hannes] I replaced the term “large” with the following explanatory text:

“
(*) Because firmware images are often multiple kilobytes, sometimes
exceeding one hundred kilobytes, in size for low end IoT devices and even
several megabytes large for IoT devices running full-fletched operating systems
like Linux the protocol mechanism for retrieving these images needs
to offer features like congestion control, flow control, fragmentation
and reassembly, and mechanisms to resume interrupted or corrupted transfers.
 “

The point I was trying to get across is that you actually need to implement a number of
transport protocol features to transfer a firmware image.

[Hannes] Here is a try:

“
If the application image contains the firmware consumer
functionality, as described above, then it is necessary that a
working image is left on the device. This allows the bootloader to
roll back to a working firmware image to execute a firmware download
if the bootloader itself does not have enough functionality to
fetch a firmware image plus manifest from a firmware server over the
Internet.  A multi-stage bootloader may soften this requirement at
the expense of a more sophisticated boot process.
“

Security considerations:

[Hannes] Encryption is now discussed in the requirements section, as explained in one of my earlier comments.

Best regards,
Kathleen

Ciao
Hannes

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: Kathleen Moriarty <[email-masked]>
Date: Wed, 16 Oct 2019 07:28:58 -0400

Hi Hannes,

Sent from my mobile device

> On Oct 16, 2019, at 5:14 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> 
> Hi Kathleen,
>  
> Thanks for the review.
> A few remarks below:
>  
> Abstract:

Yes, bios or other firmware updates across numerous platforms that may have methods that are secure, but not consistent could be interesting.  This is for larger than IoT, but not OS or software to your point as this is difficult for enterprises that have to manage the diverse sets of systems using different processes.  It might include devices, appliances, servers, desktops, and storage.

> [Hannes] Corrected the definition to refer to firmware image, firmware, and image.
Thank you.

> third-party content distribution networks for payload distribution.

That’s a little better, thank you.
> ECC key or a 2048 bit RSA key.
Great, thank you.
> [Hannes] Changed the figure where I abbreviated “Firmware Consumer” with “fw consumer”.
Thank you.
> transport protocol features to transfer a firmware image.

The explanation does improve that point, thank you.
> the expense of a more sophisticated boot process.

That’s better, thanks.
> [Hannes] Encryption is now discussed in the requirements section, as explained in one of my earlier comments.

Thank you, 
Kathleen

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 Oct 2019 14:02:31 +0000

Hi Kathleen,

Thanks for the quick response.

I will focus on this issue only:

[Hannes] So far, most people in the group have focused on unattended, low end IoT devices. Technically, this does not mean that a lightweight firmware update mechanism cannot be used for updating a bios or firmware on storage devices. Doing that work will IMHO require us to get the experts for those technologies into the group. Speaking for myself, I don’t know, for example, what the requirements for a Bios update are. Hence, I believe the question you are raising is really for the group as a whole (or even wider) to find out whether we can leverage the technology also in adjacent domains.

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Oct 2019 16:04:21 +0200

Hannes Tschofenig <[email-masked]> wrote:
    > [Hannes] When you say “larger systems” what do you mean? There are
    > Windows, Linux and mobile devices out there that already have a
    > perfectly fine software update mechanism and we are not trying to
    > replace it with this work. For those devices that run regular operating
    > systems the lightweight design of the software update mechanism is
    > apparently less of a concern compared to the design of a firmware
    > update mechanism for low end IoT devices, as you have witnessed in the
    > discussions on this list. When you say “large system” are you then
    > referring to a system that runs Windows, Linux or something similar or
    > do you have some other system in mind?

I believe that it would be applicable to Things based upon things that look
the RPI, running Android IoT or OpenWRT.  While there are package systems, a
random assortment of packages is undesireable, and can not easily be attested
to.

This is what I think that Kathleen is talking about.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 16 Oct 2019 16:41:04 +0200

Hi Micheal,
hi thread,

at Kathleen's keynote address in TCG, the "not new" notion that SUIT 
refers to (S)oftware was raised, which - to the audience - seemed to be 
in contradiction with the content being produced.

That said, in theory the SUIT manifest could be used to update basically 
things of any size - not only constrained nodes. But I agree with your 
point that this is just a "title" problem. There are solutions, such as 
package systems,  in place that would require a quite more complex and 
elaborate attestation infrastructure and that is not the scope SUIT is 
targeting, I think.

m2c: wrt to number of secrets and endorsements that would have to be 
maintained per device we also want to be as minimalist as we can be 
while remaining feasible, I think.

Viele Grüße,

Henk

On 16.10.19 16:04, Michael Richardson wrote:
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 16 Oct 2019 11:07:09 -0400

> in contradiction with the content being produced.

Yes, but just to be clear, I did say the group was focused on firmware, but
FUIT didn't sound good.

> elaborate attestation infrastructure and that is not the scope SUIT is

Agreed, I am not asking for all types of updates.  Having consistency for
firmware and maybe bios updates for larger systems would be helpful to the
customer.  The same principles for secure updates are applied similarly
anyway across solutions.  The architecture document is a framing one, which
is why I made the comment.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Oct 2019 17:48:24 +0200

Henk Birkholz <[email-masked]> wrote:
    > things of any size - not only constrained nodes. But I agree with your point
    > that this is just a "title" problem. There are solutions, such as package
    > systems,  in place that would require a quite more complex and elaborate
    > attestation infrastructure and that is not the scope SUIT is targeting, I
    > think.

An Android IoT device is effectively an RPI running Android code.
Yes, it has a Linux kernel and file system, and yes, it can load "apps", but
in practice, one would always want to replace the entire system as a unit.

A Mozilla IoT device is also an RPI running Raspbian, with nodejs running
the application code.  It has apt for packaging, etc. and that's useful
during development, but shipping that would be dumb.  Ship a signed file
system image.

Just remember that RPIs are as big and powerful as the laptop you had ten
years ago.

    > maintained per device we also want to be as minimalist as we can be while
    > remaining feasible, I think.

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 16 Oct 2019 17:57:39 +0200

Hi Michael,
hi list,

if you treat a complex composite, such as an OS utilizing a package 
system, as a binary blob, the manifest can be used to update that. That 
is correct :-)

Viele Grüße,

Henk