[Suit] Benjamin Kaduk's No Objection on draft-ietf-suit-architecture-14: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-suit-architecture-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.