Re: [Suit] Éric Vyncke's No Objection on draft-ietf-suit-architecture-14: (with COMMENT)

[Hannes Tschofenig <[e-mail]>]

Hi Eric,

Brendan has addressed most of the review comments from Mohit listed at
https://datatracker.ietf.org/doc/review-ietf-suit-architecture-13-iotdir-telechat-sethi-2020-10-20/

I wanted to provide a few minor remarks nevertheless.

Mohit wrote:

"
How about rephrasing the text: "are expected to work automatically, i.e. without user involvement. Automatic updates that do not require human intervention are key to a scalable solution for fixing software vulnerabilities." to "are o a large extent expected to work automatically, i.e. with minimal human interaction. Automatic updates that require minimal or no interaction are key to a ....". The reason for requesting this change is simple: in many scenarios you would want user approval before the actual update. For example, updating lights at night during dinner is perhaps not ideal. The draft does discuss the importance of device operator approval in some circumstances so updating the text would make sense.
"

It is true that someone has to initiate the update and different decisions will influence on when this happens. In many systems the user of the device is asked by the device to download the update and to apply it. With devices that are have user interfaces this is often the case. Bob Briscoe shared his experience with BIOS updates on desktop systems that wasn't smooth despite having a great user interface. The IoT ecosystem is quite broad and there will be cases that can work fine with non-automated software updates. When you want to update a large number of unattended devices then there is, however, a challenge. We are addressing the latter rather than the former.

I changed the text to
"
Firmware updates  for IoT devices are **largely** expected to work automatically, i.e. without user involvement.
"
If there is a better way to get this story across, please let me know.


Mohit asked

"
I wonder if you want to state the difference between software and firmware update. Are they the same thing for this document? The text in the draft at some point says "Moreover, this architecture is not limited to managing software updates". But most of the other text talks about "firmware updates".
"

Since this was a question that surfaced in the group before we have (in previous versions of the draft) expanded the description about what a firmware image is. Here is the text:

"
   -  Firmware Image: The firmware image, or image, is a binary that may
      contain the complete software of a device or a subset of it.  The
      firmware image may consist of multiple images, if the device
      contains more than one microcontroller.  Often it is also a
      compressed archive that contains code, configuration data, and
      even the entire file system.  The image may consist of a
      differential update for performance reasons.

      The terms, firmware image, firmware, and image, are used in this
      document and are interchangeable.  We use the term application
      firmware image to differentiate it from a firmware image that
      contains the bootloader.  An application firmware image, as the
      name indicates, contains the application program often including
      all the necessary code to run it (such as protocol stacks, and
      embedded operating system).
"

Software is a very generic term. Comparing firmware with software would require us to go into the details of a specific piece of software. Software that is distributed at higher layers has typically their own software distribution system and unique security challenges based on the environment it is run in.

The reference to "Moreover, this architecture is not limited to managing software updates" was introduced because we use SUIT also for TEEP where trusted applications run in a special mode of the processor.

Mohit also writes:

"
I think most readers will be more familiar with the term Original Equipment Manufacture (OEM) rather than Original Design Manufacturer (ODM). I understand that ARM has a slightly complicated ecosystem and business model. So perhaps the text could say "in some cases, the OEM or the ODM act as a TPA and may decide to remain in full control...."
"

This is not terminology we came up with. On the surface, the manufacturing process for embedded devices looks quite simple but in practice this is not the case. This is why there is now so much interest in supply chain security today because the final product is created with so many different components that all come from different parties. This process is a by-product of how the economy works where specialization is common.

Another item is:

"
The draft uses TAs for trusted applications (TAs). But RFC 6024 referenced by this document uses TAs for Trust anchors. Can we avoid using TA abbreviations for trusted applications for ?
"

2- and 3-letter acronymous will lead to collisions, as we have the case here. Since we cannot change the acronymous I hope we made clear in the context which one we talk about.

Ciao
Hannes

-----Original Message-----
From: Éric Vyncke via Datatracker <[e-mail]>
Sent: Thursday, November 5, 2020 10:38 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Russ Housley <[e-mail]>; [e-mail]; [e-mail]
Subject: Éric Vyncke's No Objection on draft-ietf-suit-architecture-14: (with COMMENT)

Éric Vyncke 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:
----------------------------------------------------------------------

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



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.