A Firmware Update Architecture for Internet of Things
draft-ietf-suit-architecture-16

Thank you for the work put into this document.

Please add reference to LwM2M in Section 1.

Please also address all comments raised by Mohit Sethi during the IoT directorate review (I saw that Brendan has already replied):
https://datatracker.ietf.org/doc/review-ietf-suit-architecture-13-iotdir-telechat-sethi-2020-10-20/

I hope that this helps to improve the document,

Regards,

-éric

I was surprised to see that there no Normative references -- are there no other documents required to be read to understand the architecture?

It seems to me that I-D.ietf-suit-information-model should be a Normative reference because it contains an "in-depth examination of the security considerations of the architecture" (this document).

Nice work on this; thanks.  I have a bunch of comments, but all minor.

— Section 1 —

   Firmware updates can help to fix security vulnerabilities and are
   considered to be an important building block in securing IoT devices.

Nit: “firmware updates” is plural, and “building block” is singular.  I think it’s actually *doing* the updates that’s the building block, not he updates themselves.  And you can just make the statement, without “are considered”.  How do you like this version?:

NEW
   Firmware updates can help to fix security vulnerabilities, and
   performing updates is an important building block in securing
   IoT devices.
END

   Due to rising concerns about insecure IoT devices the Internet
   Architecture Board (IAB) organized a 'Workshop on Internet of Things
   (IoT) Software Update (IOTSU)', which took place at Trinity College
   Dublin, Ireland on the 13th and 14th of June, 2016 to take a look at
   the bigger picture.  A report about this workshop can be found at
   [RFC8240].  The workshop revealed a number of challenges for
   developers and led to the formation of the IETF Software Updates for
   Internet of Things (SUIT) working group.

The details of when and where the workshop happened isn’t important here, and it’s rigt up front in 8240 anyway.  I suggest trimming that, because the important part is pointing people to the worshop report and saying what’s in the next sentence about the formation of the SUIT WG.

NEW
   Due to rising concerns about insecure IoT devices the Internet
   Architecture Board (IAB) organized a 'Workshop on Internet of Things
   (IoT) Software Update (IOTSU)' [RFC8240] to take a look at
   the bigger picture.  The workshop revealed a number of challenges for
   developers and led to the formation of the IETF Software Updates for
   Internet of Things (SUIT) working group.
END

   Firmware updates are not only done to fix bugs, but they can also add
   new functionality, and re-configure

Grammar nit: “Firmware updates are done not only to fix bugs, but also to add new functionality and to reconfigure”

   Unlike higher end devices, like laptops and desktop PCs, many
   IoT devices do not have user interfaces and support for unattended
   updates is, therefore, essential for the design of a practical

My first reading of this was that “many IoT devices do not have user interfaces and support for unattended updates.”  I had to read it again to correctly interpret the sentence.  If you replace “interfaces and” with “interfaces;” it fixes that problem easily.

   using pre-configured hostnames or [RFC6763] DNS-SD.

The citation should go after “DNS-SD”.

— Section 2.1 —

   -  Firmware Image: The firmware image, or image, is a binary

The “or image” seems odd there.  Maybe like this?:

NEW
   -  Firmware Image: The firmware image, or simply the “image”,
       is a binary
END

— Section 2.3 —

      The deployment of status trackers is flexible and may
      be found at
      cloud-based servers, on-premise servers, or may be embedded in
      edge computing devices.

(Odd line-break here...)
Nit: the list is not parallel, and the intro doesnt read right.  Try this?:

NEW
      The deployment of status trackers is flexible: they may
      be found at cloud-based servers or on-premise servers,
      or they may be embedded in edge computing devices.
END

— Section 3 —

   images to the firmware server and to initiate an update him- or
   herself.

Nit: I suggest avoiding the awkwardness by saying “and to initiate an update directly.”

   As a first step in the firmware update process, the status tracker
   client needs to be made aware of the availability of a new firmware
   update by the status tracker server.

Nit: passive voice makes this more awkward than it needs to be, especially as you have a clear subject already (the server).  Why not make it active?:

NEW
   As a first step in the firmware update process, the status tracker
   server needs to inform the status tracker client that a new firmware
   update is available.
END

   -  Using a hybrid approach the server-side of the status tracker
      pushes notifications of availability of an update to the client
      side and requests the firmware consumer to pull the manifest and
      the firmware image from the firmware server.

As written, this is exactly the same as the server-initiated scenario.  In both cases, the server tells the client that an update is available, and the firmware consumer fetches the manifest and image.  What is the difference meant to be?  Do one or both of the descriptions need to be tweaked?  (I’m guessing that the server-initiated description should be changed to say that the server pushes the manifest and image, rather than waiting for the client to fetch it... yes?)

   If the firmware consumer has downloaded a new firmware image and is
   ready to install it, to initiate the installation, it may - either
   need to wait for a trigger from the status tracker, - or trigger the
   update automatically, - or go through a more complex decision making
   process to determine the appropriate timing for an update.

Are those dashes meant to be bullets in a list, and so is this a formatting glitch?

   Devices
   must not fail when a disruption occurs during the update process.
   For example, a power failure or network disruption during the update
   process must not cause the device to fail.

Nit: why not merge these two sentences?:

NEW
   Devices
   must not fail when a disruption, such as a power failure or network
   interruption, occurs during the update process.
END

— Section 4.1 —

   -  The bootloader needs to fetch the manifest (or manifest-alike
      headers) from nonvolatile storage

What are “manifest-alike headers”?

      This allows to share
      information about the current firmware version

“Allows to share” doesn’t work in English: you need a subject, “allows <subject> to share <object>”.  If you don’t have a subject, you can say “allows the sharing of information...”.

— Section 6 —

   A manifest may not only be used to protect firmware images but also
   configuration data such as network credentials

Similar to a comment above, this has “not only” misplaced:

NEW
   A manifest may be used to protect not only firmware images but also
   configuration data such as network credentials
END

Does the XIP case mean that repeated firmware updates would have
potential to cause undue wear on the fixed flash cells that hold the
firmware image?  If so, this might be noted in the security
considerations.

I am not sure that I have fully digested Bob Briscoe's detailed review
comments, but it seems like we may want to continue to reflect on which
portions of the architecture will be optional to implement, and how we
might indicate that in the document.

I also made a pull request for some editorial nits at
https://github.com/suit-wg/architecture/pull/15 .

Section 1

   otherwise difficult.  Firmware updates
   for IoT devices are expected to work automatically, i.e. without user
   involvement.  Conversely, IoT devices are expected to account for
   user preferences and consent when scheduling updates.  Automatic

I can't quite tell if the "Conversely" case is intending to refer to IoT
or non-IoT devices.

   The firmware update process has to ensure that

   -  The firmware image is authenticated and integrity protected.
      [...]

   -  The firmware image can be confidentiality protected so that
      attempts by an adversary to recover the plaintext binary can be
      [...]

Perhaps it's just because Bob Briscoe's comments are fresh in my mind,
but there seems to be something of a mismatch across these texts -- we
"have to ensure" that the firmware *is* authenticated and integrity
protected, but only that the image *can be* confidentiality protected.
Is it really the case that we can ensure that an update process *can be*
confidentiality protected, or is the confidentiality requirement more of
a requirement on the architecture than on actual deployment?

   While the IETF standardization work has been focused on the manifest
   format, a fully interoperable solution needs more than a standardized
   manifest.  For example, protocols for transferring firmware images
   and manifests to the device need to be available as well as the
   status tracker functionality.  Devices also require a mechanism to
   discover the status tracker(s) and/or firmware servers, for example
   using pre-configured hostnames or [RFC6763] DNS-SD.  These building
   blocks have been developed by various organizations under the
   umbrella of an IoT device management solution.  The LwM2M protocol is
   one IoT device management protocol.

We might put some forward references to things we do cover (like status
tracker(s)), and a reference for LwM2M as well.

Section 3

   Hence, the following components are necessary on a device for a
   firmware update solution:
   [...]
   -  a status tracker.

Earlier we said that having the status tracker on the device was fairly
uncommon.

Section 7

   time horizon for quantum-accelerated key extraction.  The worst-case
   estimate, at time of writing, for the time horizon to key extraction
   with quantum acceleration is approximately 2030, based on current
   research [quantum-factorization].

I'm not sure that I see how the reference suports the "approximately
2030" statement.

Thank you for engaging with the TSVART review.

I think Bob's criticism still holds that certain aspects of what is critical, vs. nice-to-have are ambiguous.

For example, in Section 1:

"The firmware update process has to ensure that

   -  The firmware image is authenticated and integrity protected.
      Attempts to flash a maliciously modified firmware image or an
      image from an unknown, untrusted source must be prevented.  In
      examples this document uses asymmetric cryptography because it is
      the preferred approach by many IoT deployments.  The use of
      symmetric credentials is also supported and can be used by very
      constrained IoT devices.

   -  The firmware image can be confidentiality protected so that
      attempts by an adversary to recover the plaintext binary can be
      mitigated or at least made more difficult.  Obtaining the firmware
      is often one of the first steps to mount an attack since it gives
      the adversary valuable insights into the software libraries used,
      configuration settings and generic functionality.  Even though
      reverse engineering the binary can be a tedious process modern
      reverse engineering frameworks have made this task a lot easier."

The construction of this excerpt suggests that confidentiality is mandatory, but I gather from the thread that it is not.

If it is mandatory, than please change the second bullet to read "The firmware image is confidentiality protected..."

If it is not mandatory, I would just combine the first bullet and the opening clause, and make the second bullet an independent paragraph.

Thank you for this document.  I found it informative and interesting.

One minor comment:

7.  Securing Firmware Updates

      The
      information that is encrypted individually for each device/
      recipient must maintain friendliness to Content Distribution
      Networks, bulk storage, and broadcast protocols. 

Although I think that I understand the intent here, I'm not sure whether friendliness is the best choice of term here.  I presume that it means "must be done in a way that is usable with".

Regards,
Rob