A Firmware Update Architecture for Internet of Things
RFC 9019
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2021-04-30
|
16 | (System) | Received changes through RFC Editor sync (created alias RFC 9019, changed abstract to 'Vulnerabilities in Internet of Things (IoT) devices have raised the need … Received changes through RFC Editor sync (created alias RFC 9019, changed abstract to 'Vulnerabilities in Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism suitable for devices with resource constraints. Incorporating such an update mechanism is a fundamental requirement for fixing vulnerabilities, but it also enables other important capabilities such as updating configuration settings and adding new functionality. In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates.', changed pages to 25, changed standardization level to Informational, changed state to RFC, added RFC published event at 2021-04-30, changed IESG state to RFC Published) |
|
2021-04-30
|
16 | (System) | RFC published |
|
2021-04-27
|
16 | (System) | RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9019">AUTH48-DONE</a> from AUTH48 |
|
2021-03-24
|
16 | (System) | RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9019">AUTH48</a> |
|
2021-03-01
|
16 | Russ Housley | Added to session: IETF-110: suit Thu-1530 |
|
2021-02-25
|
16 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
|
2021-02-11
|
16 | Tero Kivinen | Closed request for Telechat review by SECDIR with state 'Overtaken by Events' |
|
2021-02-11
|
16 | Tero Kivinen | Assignment of request for Telechat review by SECDIR to Rich Salz was marked no-response |
|
2021-01-28
|
16 | (System) | RFC Editor state changed to EDIT |
|
2021-01-28
|
16 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
|
2021-01-28
|
16 | (System) | Announcement was received by RFC Editor |
|
2021-01-27
|
16 | (System) | IANA Action state changed to No IANA Actions from In Progress |
|
2021-01-27
|
16 | (System) | IANA Action state changed to In Progress |
|
2021-01-27
|
16 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
|
2021-01-27
|
16 | Cindy Morgan | IESG has approved the document |
|
2021-01-27
|
16 | Cindy Morgan | Closed "Approve" ballot |
|
2021-01-27
|
16 | Cindy Morgan | Ballot approval text was generated |
|
2021-01-27
|
16 | Roman Danyliw | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
|
2021-01-27
|
16 | Hannes Tschofenig | New version available: draft-ietf-suit-architecture-16.txt |
|
2021-01-27
|
16 | (System) | New version approved |
|
2021-01-27
|
16 | (System) | Request for posting confirmation emailed to previous authors: Brendan Moran <brendan.moran@arm.com>, David Brown <david.brown@linaro.org>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Milosch Meriac … Request for posting confirmation emailed to previous authors: Brendan Moran <brendan.moran@arm.com>, David Brown <david.brown@linaro.org>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Milosch Meriac <milosch@meriac.com>, suit-chairs@ietf.org |
|
2021-01-27
|
16 | Hannes Tschofenig | Uploaded new revision |
|
2021-01-17
|
15 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2021-01-17
|
15 | Hannes Tschofenig | New version available: draft-ietf-suit-architecture-15.txt |
|
2021-01-17
|
15 | (System) | New version approved |
|
2021-01-17
|
15 | (System) | Request for posting confirmation emailed to previous authors: Brendan Moran <brendan.moran@arm.com>, David Brown <david.brown@linaro.org>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Milosch Meriac … Request for posting confirmation emailed to previous authors: Brendan Moran <brendan.moran@arm.com>, David Brown <david.brown@linaro.org>, Hannes Tschofenig <hannes.tschofenig@arm.com>, Milosch Meriac <milosch@meriac.com>, suit-chairs@ietf.org |
|
2021-01-17
|
15 | Hannes Tschofenig | Uploaded new revision |
|
2020-11-05
|
14 | Dave Thaler | Added to session: IETF-109: suit Fri-1430 |
|
2020-11-05
|
14 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
|
2020-11-05
|
14 | Robert Wilton | [Ballot comment] Thank you for this document. I found it informative and interesting. One minor comment: 7. Securing Firmware Updates The … [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 |
|
2020-11-05
|
14 | Robert Wilton | Ballot comment text updated for Robert Wilton |
|
2020-11-05
|
14 | Robert Wilton | [Ballot comment] Thank you for this document. I found it informative and interesting. I minor comment: 7. Securing Firmware Updates The … [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 |
|
2020-11-05
|
14 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
|
2020-11-05
|
14 | Benjamin Kaduk | [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 … [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. |
|
2020-11-05
|
14 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
|
2020-11-05
|
14 | Éric Vyncke | [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 … [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 |
|
2020-11-05
|
14 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
|
2020-11-04
|
14 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
|
2020-11-04
|
14 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
|
2020-11-04
|
14 | Alvaro Retana | [Ballot comment] I was surprised to see that there no Normative references -- are there no other documents required to be read to understand the … [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). |
|
2020-11-04
|
14 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
|
2020-11-02
|
14 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
|
2020-11-01
|
14 | Barry Leiba | [Ballot comment] Nice work on this; thanks. I have a bunch of comments, but all minor. — Section 1 — Firmware updates can help … [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 <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 |
|
2020-11-01
|
14 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
|
2020-10-29
|
14 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Rich Salz |
|
2020-10-29
|
14 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Rich Salz |
|
2020-10-28
|
14 | Martin Duke | [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 … [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. |
|
2020-10-28
|
14 | Martin Duke | Ballot comment text updated for Martin Duke |
|
2020-10-28
|
14 | Martin Duke | [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. … [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. |
|
2020-10-28
|
14 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
|
2020-10-23
|
14 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
|
2020-10-22
|
14 | Roman Danyliw | IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup |
|
2020-10-22
|
14 | Cindy Morgan | Placed on agenda for telechat - 2020-11-05 |
|
2020-10-22
|
14 | Roman Danyliw | Ballot has been issued |
|
2020-10-22
|
14 | Roman Danyliw | [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw |
|
2020-10-22
|
14 | Roman Danyliw | Created "Approve" ballot |
|
2020-10-22
|
14 | Roman Danyliw | Ballot writeup was changed |
|
2020-10-21
|
14 | Brendan Moran | New version available: draft-ietf-suit-architecture-14.txt |
|
2020-10-21
|
14 | (System) | New version approved |
|
2020-10-21
|
14 | (System) | Request for posting confirmation emailed to previous authors: Milosch Meriac <milosch@meriac.com>, suit-chairs@ietf.org, David Brown <david.brown@linaro.org>, Brendan Moran <brendan.moran@arm.com>, … Request for posting confirmation emailed to previous authors: Milosch Meriac <milosch@meriac.com>, suit-chairs@ietf.org, David Brown <david.brown@linaro.org>, Brendan Moran <brendan.moran@arm.com>, Hannes Tschofenig <hannes.tschofenig@arm.com> |
|
2020-10-21
|
14 | Brendan Moran | Uploaded new revision |
|
2020-10-20
|
13 | Mohit Sethi | Request for Telechat review by IOTDIR Completed: Ready with Nits. Reviewer: Mohit Sethi. Sent review to list. |
|
2020-10-16
|
13 | Samita Chakrabarti | Request for Telechat review by IOTDIR is assigned to Mohit Sethi |
|
2020-10-16
|
13 | Samita Chakrabarti | Request for Telechat review by IOTDIR is assigned to Mohit Sethi |
|
2020-10-16
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2020-10-16
|
13 | Brendan Moran | New version available: draft-ietf-suit-architecture-13.txt |
|
2020-10-16
|
13 | (System) | New version approved |
|
2020-10-16
|
13 | (System) | Request for posting confirmation emailed to previous authors: Milosch Meriac <milosch@meriac.com>, suit-chairs@ietf.org, Brendan Moran <brendan.moran@arm.com>, David Brown <david.brown@linaro.org>, … Request for posting confirmation emailed to previous authors: Milosch Meriac <milosch@meriac.com>, suit-chairs@ietf.org, Brendan Moran <brendan.moran@arm.com>, David Brown <david.brown@linaro.org>, Hannes Tschofenig <hannes.tschofenig@arm.com> |
|
2020-10-16
|
13 | Brendan Moran | Uploaded new revision |
|
2020-10-16
|
12 | Éric Vyncke | Requested Telechat review by IOTDIR |
|
2020-09-17
|
12 | Roman Danyliw | IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup::AD Followup |
|
2020-09-17
|
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2020-09-17
|
12 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
|
2020-09-17
|
12 | Brendan Moran | New version available: draft-ietf-suit-architecture-12.txt |
|
2020-09-17
|
12 | (System) | New version approved |
|
2020-09-17
|
12 | (System) | Request for posting confirmation emailed to previous authors: David Brown <david.brown@linaro.org>, Hannes Tschofenig <hannes.tschofenig@arm.com>, suit-chairs@ietf.org, Milosch Meriac <milosch@meriac.com>, … Request for posting confirmation emailed to previous authors: David Brown <david.brown@linaro.org>, Hannes Tschofenig <hannes.tschofenig@arm.com>, suit-chairs@ietf.org, Milosch Meriac <milosch@meriac.com>, Brendan Moran <brendan.moran@arm.com> |
|
2020-09-17
|
12 | Brendan Moran | Uploaded new revision |
|
2020-08-27
|
11 | Rich Salz | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Rich Salz. Sent review to list. |
|
2020-08-19
|
11 | Roman Danyliw | IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup |
|
2020-08-14
|
11 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
|
2020-08-12
|
11 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
|
2020-08-12
|
11 | Sabrina Tanamal | (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 … (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 |
|
2020-08-09
|
11 | Bob Briscoe | Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Bob Briscoe. Sent review to list. |
|
2020-08-09
|
11 | Reese Enghardt | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Theresa Enghardt. Sent review to list. |
|
2020-08-06
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Rich Salz |
|
2020-08-06
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Rich Salz |
|
2020-08-04
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Sheng Jiang |
|
2020-08-04
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Sheng Jiang |
|
2020-07-31
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Theresa Enghardt |
|
2020-07-31
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Theresa Enghardt |
|
2020-07-31
|
11 | David Waltermire | Added to session: IETF-108: suit Fri-1100 |
|
2020-07-27
|
11 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Bob Briscoe |
|
2020-07-27
|
11 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Bob Briscoe |
|
2020-07-24
|
11 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
|
2020-07-24
|
11 | Amy Vezza | The following Last Call announcement was sent out (ends 2020-08-14):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: draft-ietf-suit-architecture@ietf.org, housley@vigilsec.com, … The following Last Call announcement was sent out (ends 2020-08-14):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: draft-ietf-suit-architecture@ietf.org, housley@vigilsec.com, rdd@cert.org, suit-chairs@ietf.org, Russ Housley <housley@vigilsec.com>, suit@ietf.org Reply-To: last-call@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-suit-architecture-11.txt> (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' <draft-ietf-suit-architecture-11.txt> 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. |
|
2020-07-24
|
11 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
|
2020-07-24
|
11 | Amy Vezza | Last call announcement was changed |
|
2020-07-24
|
11 | Roman Danyliw | Last call was requested |
|
2020-07-24
|
11 | Roman Danyliw | Last call announcement was generated |
|
2020-07-24
|
11 | Roman Danyliw | Ballot approval text was generated |
|
2020-07-24
|
11 | Roman Danyliw | Ballot writeup was generated |
|
2020-07-24
|
11 | Roman Danyliw | IESG state changed to Last Call Requested from Publication Requested |
|
2020-07-24
|
11 | Roman Danyliw | AD Review: https://mailarchive.ietf.org/arch/msg/suit/C4Az0vxz32FfwcOfdD_tTgPVNwU/ |
|
2020-06-09
|
11 | Russ Housley | 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 … 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. |
|
2020-06-09
|
11 | Russ Housley | Responsible AD changed to Roman Danyliw |
|
2020-06-09
|
11 | Russ Housley | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
|
2020-06-09
|
11 | Russ Housley | IESG state changed to Publication Requested from I-D Exists |
|
2020-06-09
|
11 | Russ Housley | IESG process started in state Publication Requested |
|
2020-06-09
|
11 | Russ Housley | 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 … 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. |
|
2020-05-27
|
11 | Hannes Tschofenig | New version available: draft-ietf-suit-architecture-11.txt |
|
2020-05-27
|
11 | (System) | New version approved |
|
2020-05-27
|
11 | (System) | Request for posting confirmation emailed to previous authors: David Brown <david.brown@linaro.org>, Hannes Tschofenig <hannes.tschofenig@arm.com>, suit-chairs@ietf.org, Brendan Moran <brendan.moran@arm.com>, … Request for posting confirmation emailed to previous authors: David Brown <david.brown@linaro.org>, Hannes Tschofenig <hannes.tschofenig@arm.com>, suit-chairs@ietf.org, Brendan Moran <brendan.moran@arm.com>, Milosch Meriac <milosch@meriac.com> |
|
2020-05-27
|
11 | Hannes Tschofenig | Uploaded new revision |
|
2020-05-27
|
10 | Russ Housley | Intended Status changed to Informational from None |
|
2020-05-27
|
10 | Russ Housley | Changed consensus to Yes from Unknown |
|
2020-05-27
|
10 | Hannes Tschofenig | New version available: draft-ietf-suit-architecture-10.txt |
|
2020-05-27
|
10 | (System) | New version approved |
|
2020-05-27
|
10 | (System) | Request for posting confirmation emailed to previous authors: suit-chairs@ietf.org, Milosch Meriac <milosch@meriac.com>, David Brown <david.brown@linaro.org>, Brendan Moran <brendan.moran@arm.com>, … Request for posting confirmation emailed to previous authors: suit-chairs@ietf.org, Milosch Meriac <milosch@meriac.com>, David Brown <david.brown@linaro.org>, Brendan Moran <brendan.moran@arm.com>, Hannes Tschofenig <hannes.tschofenig@arm.com> |
|
2020-05-27
|
10 | Hannes Tschofenig | Uploaded new revision |
|
2020-05-26
|
09 | David Waltermire | Notification list changed to Russ Housley <housley@vigilsec.com> |
|
2020-05-26
|
09 | David Waltermire | Document shepherd changed to Russ Housley |
|
2020-05-22
|
09 | Brendan Moran | New version available: draft-ietf-suit-architecture-09.txt |
|
2020-05-22
|
09 | (System) | New version approved |
|
2020-05-22
|
09 | (System) | Request for posting confirmation emailed to previous authors: David Brown <david.brown@linaro.org>, Brendan Moran <brendan.moran@arm.com>, Hannes Tschofenig <hannes.tschofenig@arm.com>, suit-chairs@ietf.org, … Request for posting confirmation emailed to previous authors: David Brown <david.brown@linaro.org>, Brendan Moran <brendan.moran@arm.com>, Hannes Tschofenig <hannes.tschofenig@arm.com>, suit-chairs@ietf.org, Milosch Meriac <milosch@meriac.com> |
|
2020-05-22
|
09 | Brendan Moran | Uploaded new revision |
|
2020-05-22
|
08 | (System) | Document has expired |
|
2020-02-19
|
08 | Dave Thaler | Added to session: interim-2020-suit-01 |
|
2019-12-04
|
08 | Russ Housley | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
|
2019-11-19
|
08 | Hannes Tschofenig | New version available: draft-ietf-suit-architecture-08.txt |
|
2019-11-19
|
08 | (System) | New version accepted (logged-in submitter: Hannes Tschofenig) |
|
2019-11-19
|
08 | Hannes Tschofenig | Uploaded new revision |
|
2019-11-17
|
07 | David Waltermire | Added to session: IETF-106: suit Tue-1330 |
|
2019-10-21
|
07 | Hannes Tschofenig | New version available: draft-ietf-suit-architecture-07.txt |
|
2019-10-21
|
07 | (System) | New version approved |
|
2019-10-20
|
07 | (System) | Request for posting confirmation emailed to previous authors: Hannes Tschofenig <hannes.tschofenig@arm.com>, Milosch Meriac <milosch@meriac.com>, David Brown <david.brown@linaro.org>, Brendan Moran … Request for posting confirmation emailed to previous authors: Hannes Tschofenig <hannes.tschofenig@arm.com>, Milosch Meriac <milosch@meriac.com>, David Brown <david.brown@linaro.org>, Brendan Moran <brendan.moran@arm.com> |
|
2019-10-20
|
07 | Hannes Tschofenig | Uploaded new revision |
|
2019-09-13
|
06 | Hannes Tschofenig | New version available: draft-ietf-suit-architecture-06.txt |
|
2019-09-13
|
06 | (System) | New version approved |
|
2019-09-13
|
06 | (System) | Request for posting confirmation emailed to previous authors: Hannes Tschofenig <hannes.tschofenig@arm.com>, Milosch Meriac <milosch@meriac.com>, David Brown <david.brown@linaro.org>, Brendan Moran … Request for posting confirmation emailed to previous authors: Hannes Tschofenig <hannes.tschofenig@arm.com>, Milosch Meriac <milosch@meriac.com>, David Brown <david.brown@linaro.org>, Brendan Moran <brendan.moran@arm.com> |
|
2019-09-13
|
06 | Hannes Tschofenig | Uploaded new revision |
|
2019-07-12
|
05 | Russ Housley | Added to session: IETF-105: suit Wed-1000 |
|
2019-04-09
|
05 | Hannes Tschofenig | New version available: draft-ietf-suit-architecture-05.txt |
|
2019-04-09
|
05 | (System) | New version approved |
|
2019-04-09
|
05 | (System) | Request for posting confirmation emailed to previous authors: Brendan Moran <brendan.moran@arm.com>, suit-chairs@ietf.org, Milosch Meriac <milosch@meriac.com>, David Brown <david.brown@linaro.org>, … Request for posting confirmation emailed to previous authors: Brendan Moran <brendan.moran@arm.com>, suit-chairs@ietf.org, Milosch Meriac <milosch@meriac.com>, David Brown <david.brown@linaro.org>, Hannes Tschofenig <hannes.tschofenig@arm.com> |
|
2019-04-09
|
05 | Hannes Tschofenig | Uploaded new revision |
|
2019-03-27
|
04 | Russ Housley | IETF WG state changed to In WG Last Call from WG Document |
|
2019-03-27
|
04 | Hannes Tschofenig | New version available: draft-ietf-suit-architecture-04.txt |
|
2019-03-27
|
04 | (System) | New version approved |
|
2019-03-27
|
04 | (System) | Request for posting confirmation emailed to previous authors: Brendan Moran <brendan.moran@arm.com>, suit-chairs@ietf.org, Milosch Meriac <milosch@meriac.com>, David Brown <david.brown@linaro.org>, … Request for posting confirmation emailed to previous authors: Brendan Moran <brendan.moran@arm.com>, suit-chairs@ietf.org, Milosch Meriac <milosch@meriac.com>, David Brown <david.brown@linaro.org>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net> |
|
2019-03-27
|
04 | Hannes Tschofenig | Uploaded new revision |
|
2019-03-11
|
03 | Hannes Tschofenig | New version available: draft-ietf-suit-architecture-03.txt |
|
2019-03-11
|
03 | (System) | New version approved |
|
2019-03-11
|
03 | (System) | Request for posting confirmation emailed to previous authors: Brendan Moran <brendan.moran@arm.com>, suit-chairs@ietf.org, Milosch Meriac <milosch@meriac.com>, David Brown <david.brown@linaro.org>, … Request for posting confirmation emailed to previous authors: Brendan Moran <brendan.moran@arm.com>, suit-chairs@ietf.org, Milosch Meriac <milosch@meriac.com>, David Brown <david.brown@linaro.org>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net> |
|
2019-03-11
|
03 | Hannes Tschofenig | Uploaded new revision |
|
2019-03-04
|
02 | Dave Thaler | Added to session: IETF-104: suit Wed-0900 |
|
2019-01-16
|
02 | Hannes Tschofenig | New version available: draft-ietf-suit-architecture-02.txt |
|
2019-01-16
|
02 | (System) | New version approved |
|
2019-01-16
|
02 | (System) | Request for posting confirmation emailed to previous authors: Brendan Moran <brendan.moran@arm.com>, suit-chairs@ietf.org, Milosch Meriac <milosch@meriac.com>, David Brown <david.brown@linaro.org>, … Request for posting confirmation emailed to previous authors: Brendan Moran <brendan.moran@arm.com>, suit-chairs@ietf.org, Milosch Meriac <milosch@meriac.com>, David Brown <david.brown@linaro.org>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net> |
|
2019-01-16
|
02 | Hannes Tschofenig | Uploaded new revision |
|
2019-01-03
|
01 | (System) | Document has expired |
|
2018-11-04
|
01 | Dave Thaler | Added to session: IETF-103: suit Thu-0900 |
|
2018-07-17
|
01 | Dave Thaler | Added to session: IETF-102: suit Wed-0930 |
|
2018-07-02
|
01 | Hannes Tschofenig | New version available: draft-ietf-suit-architecture-01.txt |
|
2018-07-02
|
01 | (System) | New version approved |
|
2018-07-02
|
01 | (System) | Request for posting confirmation emailed to previous authors: suit-chairs@ietf.org, Milosch Meriac <milosch@meriac.com>, Brendan Moran <brendan.moran@arm.com>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net> |
|
2018-07-02
|
01 | Hannes Tschofenig | Uploaded new revision |
|
2018-06-15
|
00 | Russ Housley | Added to session: interim-2018-suit-03 |
|
2018-06-03
|
00 | Dave Thaler | This document now replaces draft-moran-suit-architecture instead of None |
|
2018-06-03
|
00 | Hannes Tschofenig | New version available: draft-ietf-suit-architecture-00.txt |
|
2018-06-03
|
00 | (System) | WG -00 approved |
|
2018-06-03
|
00 | Hannes Tschofenig | Set submitter to "Hannes Tschofenig <hannes.tschofenig@gmx.net>", replaces to draft-moran-suit-architecture and sent approval email to group chairs: suit-chairs@ietf.org |
|
2018-06-03
|
00 | Hannes Tschofenig | Uploaded new revision |