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

[Ballot comment]
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

[Ballot comment]
Thank you for this document.  I found it informative and interesting.

I 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

[Ballot 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.

[Ballot 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

[Ballot comment]
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).

[Ballot comment]
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  to share ”.  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

[Ballot comment]
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.

[Ballot comment]
Thank you for engaging with the TSVART review.

I think Bob's criticism 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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-suit-architecture-11, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-08-14):

From: The IESG
To: IETF-Announce
CC: draft-ietf-suit-architecture@ietf.org, housley@vigilsec.com, rdd@cert.org, suit-chairs@ietf.org, Russ Housley , suit@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (A Firmware Update Architecture for Internet of Things) to Informational RFC


The IESG has received a request from the Software Updates for Internet of
Things WG (suit) to consider the following document: - 'A Firmware Update
Architecture for Internet of Things'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-08-14. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Vulnerabilities with Internet of Things (IoT) devices have raised the
  need for a solid and secure firmware update mechanism that is also
  suitable for constrained devices.  Incorporating such update
  mechanism to fix vulnerabilities, to update configuration settings as
  well as adding new functionality is recommended by security experts.

  This document lists requirements and describes an architecture for a
  firmware update mechanism suitable for IoT devices.  The architecture
  is agnostic to the transport of the firmware images and associated
  meta-data.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/



No IPR declarations have been submitted directly on this I-D.

Shepherd Write-up for draft-ietf-suit-architecture-11


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Informational.  Yes, the header calls for Informational RFC.


(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

  Vulnerabilities with Internet of Things (IoT) devices have raised the
  need for a solid and secure firmware update mechanism that is also
  suitable for constrained devices.  Firmware updates are needed to fix
  vulnerabilities in previous releases, update configuration settings,
  and add new functionality.  This document lists requirements for a
  firmware update mechanism suitable for IoT devices, and it describes
  an architecture that is agnostic to the transport of the firmware
  images and associated metadata.

  Working Group Summary:

  There is consensus for this document in the SUIT WG.

  Document Quality:

  Projects at the IETF Hackathon have informed this document.
   
  Personnel:

  Russ Housley is the document shepherd.
  Roman Danyliw is the responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  The document shepherd did a thorough review of the document during
  WG Last Call.  All issues that were raised during WG Last Call have
  been resolved.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?  If so, describe the review that took
place.

  No concerns.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.  If not, explain why?

  The authors have explicitly stated that they are unaware of any IPR
  related with the document.

  The authors have explicitly stated that they do not hold any IPR
  related to the document.


(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures were issued against this document.


(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  There is consensus for this document in the SUIT WG.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.


(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.

  There is an unused Reference to 'I-D.ietf-suit-manifest'.  This can
  get resolved along with any IETF Last Call comments.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  No special reviews are needed.


(13) Have all references within this document been identified as either
normative or informative?

  Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  There are no downward normative references.


(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.  Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

  No updates to the IANA registries are needed.


(18) List any new IANA registries that require Expert Review for future
allocations.  Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  No new IANA registries are needed.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None are needed.

Shepherd Write-up for draft-ietf-suit-architecture-11


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Informational.  Yes, the header calls for Informational RFC.


(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

  Vulnerabilities with Internet of Things (IoT) devices have raised the
  need for a solid and secure firmware update mechanism that is also
  suitable for constrained devices.  Firmware updates are needed to fix
  vulnerabilities in previous releases, update configuration settings,
  and add new functionality.  This document lists requirements for a
  firmware update mechanism suitable for IoT devices, and it describes
  an architecture that is agnostic to the transport of the firmware
  images and associated metadata.

  Working Group Summary:

  There is consensus for this document in the SUIT WG.

  Document Quality:

  Projects at the IETF Hackathon have informed this document.
   
  Personnel:

  Russ Housley is the document shepherd.
  Roman Danyliw is the responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  The document shepherd did a thorough review of the document during
  WG Last Call.  All issues that were raised during WG Last Call have
  been resolved.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?  If so, describe the review that took
place.

  No concerns.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.  If not, explain why?

  The authors have explicitly stated that they are unaware of any IPR
  related with the document.

  The authors have explicitly stated that they do not hold any IPR
  related to the document.


(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures were issued against this document.


(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  There is consensus for this document in the SUIT WG.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.


(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.

  There is an unused Reference to 'I-D.ietf-suit-manifest'.  This can
  get resolved along with any IETF Last Call comments.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  No special reviews are needed.


(13) Have all references within this document been identified as either
normative or informative?

  Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  There are no downward normative references.


(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.  Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

  No updates to the IANA registries are needed.


(18) List any new IANA registries that require Expert Review for future
allocations.  Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  No new IANA registries are needed.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None are needed.