A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices
draft-ietf-suit-information-model-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-01-26
|
13 | Gunter Van de Velde | Request closed, assignment withdrawn: Carlos Martínez Last Call OPSDIR review |
2024-01-26
|
13 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2021-12-20
|
13 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-08-18
|
13 | (System) | RFC Editor state changed to AUTH48 |
2021-08-06
|
13 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2021-07-28
|
13 | Dave Thaler | Changed document external resources from: None to: github_repo https://github.com/suit-wg/information-model |
2021-07-09
|
13 | (System) | RFC Editor state changed to EDIT |
2021-07-09
|
13 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2021-07-09
|
13 | (System) | Announcement was received by RFC Editor |
2021-07-09
|
13 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2021-07-09
|
13 | (System) | IANA Action state changed to In Progress |
2021-07-09
|
13 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2021-07-09
|
13 | Cindy Morgan | IESG has approved the document |
2021-07-09
|
13 | Cindy Morgan | Closed "Approve" ballot |
2021-07-09
|
13 | Cindy Morgan | Ballot approval text was generated |
2021-07-09
|
13 | Roman Danyliw | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2021-07-08
|
13 | (System) | Removed all action holders (IESG state changed) |
2021-07-08
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-07-08
|
13 | Hannes Tschofenig | New version available: draft-ietf-suit-information-model-13.txt |
2021-07-08
|
13 | (System) | New version accepted (logged-in submitter: Hannes Tschofenig) |
2021-07-08
|
13 | Hannes Tschofenig | Uploaded new revision |
2021-05-26
|
12 | Roman Danyliw | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup |
2021-05-24
|
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-05-24
|
12 | Brendan Moran | New version available: draft-ietf-suit-information-model-12.txt |
2021-05-24
|
12 | (System) | New version accepted (logged-in submitter: Brendan Moran) |
2021-05-24
|
12 | Brendan Moran | Uploaded new revision |
2021-05-23
|
11 | Russ Housley | Added to session: interim-2021-suit-01 |
2021-04-16
|
11 | Roman Danyliw | Remaining IESG review feedback: https://mailarchive.ietf.org/arch/msg/suit/DIdz3STHUWASzLxQxv10mVNCNSY/ |
2021-04-16
|
11 | Roman Danyliw | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup |
2021-04-06
|
11 | Hannes Tschofenig | New version available: draft-ietf-suit-information-model-11.txt |
2021-04-06
|
11 | (System) | New version approved |
2021-04-06
|
11 | (System) | Request for posting confirmation emailed to previous authors: Brendan Moran , Hannes Tschofenig , Henk Birkholz , suit-chairs@ietf.org |
2021-04-06
|
11 | Hannes Tschofenig | Uploaded new revision |
2021-03-19
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-03-19
|
10 | Hannes Tschofenig | New version available: draft-ietf-suit-information-model-10.txt |
2021-03-19
|
10 | (System) | New version approved |
2021-03-19
|
10 | (System) | Request for posting confirmation emailed to previous authors: Brendan Moran , Hannes Tschofenig , Henk Birkholz , suit-chairs@ietf.org |
2021-03-19
|
10 | Hannes Tschofenig | Uploaded new revision |
2021-03-01
|
09 | Russ Housley | Added to session: IETF-110: suit Thu-1530 |
2021-02-24
|
09 | Roman Danyliw | See https://mailarchive.ietf.org/arch/msg/suit/JJIfQkjoMelojLjJjSWEfwhHU9Y/. Further discussion on approach will occur at IETF 110. |
2021-02-24
|
09 | (System) | Changed action holders to Hannes Tschofenig, Henk Birkholz, Brendan Moran (IESG state changed) |
2021-02-24
|
09 | Roman Danyliw | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup |
2021-02-22
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-02-22
|
09 | Hannes Tschofenig | New version available: draft-ietf-suit-information-model-09.txt |
2021-02-22
|
09 | (System) | New version approved |
2021-02-22
|
09 | (System) | Request for posting confirmation emailed to previous authors: Brendan Moran , Hannes Tschofenig , Henk Birkholz , suit-chairs@ietf.org |
2021-02-22
|
09 | Hannes Tschofenig | Uploaded new revision |
2020-12-03
|
08 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2020-12-03
|
08 | Cindy Morgan | Changed consensus to Yes from Unknown |
2020-12-03
|
08 | Alissa Cooper | [Ballot comment] General comment: I find the repetition of "Manifest Element:" in all the section headers redundant and would suggest removing it. = Section 3.3.1 … [Ballot comment] General comment: I find the repetition of "Manifest Element:" in all the section headers redundant and would suggest removing it. = Section 3.3.1 = s/Vendor A creates a UUID based on their domain name:/Vendor A creates a UUID based on a domain name it controls:/ = Section 3.8 = "This element is REQUIRED and MUST be present" --> second normative keyword is redundant = Section 4.2.11 = The term "Owner," which is not defined in draft-ietf-suit-architecture, is sometimes capitalized as a term of art, and sometimes not. It seems like it should either be defined in this document and capitalized consistently, or not capitalized anywhere. (There is also one instance in Section 4.2.16). Network Operator is also not consistently capitalized. = Section 4.3.2 = "Devices MUST know with fine granularity" --> this requirement doesn't seem actionable as written, maybe re-phrase without the normative language? = Section 4.5 = In general I think it's preferable for normative statements to indicate which party is responsible for fulfilling them. Saying "It MUST be possible" can leave things ambiguous about who is supposed to take responsibility. It would be better to say "Manifest authors MUST ..." or something along those lines. |
2020-12-03
|
08 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-12-03
|
08 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. It is easy to read and the examples are useful. Please find below some … [Ballot comment] Thank you for the work put into this document. It is easy to read and the examples are useful. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits. I draw authors' attention to my comment on section 4. Stephen Farrel, in copy, also did a IOT directorate review available at https://datatracker.ietf.org/doc/review-ietf-suit-information-model-08-iotdir-telechat-farrell-2020-12-02/ Thank you again Stephen Please address/reply to all his points. I hope that this helps to improve the document, Regards, -éric == COMMENTS == As usual, I find a little suprizing that an information model is "standards track" rather than "informational" (e.g., RFC 8454, draft-ietf-babel-information-model, draft-ietf-detnet-flow-information-model). Data models are of course "standards track". There are exceptions though: RFC 5477, 7012, and 8193 are informational model in standards track. Why is the word "manifest" absent of the title ? The companion data model document has it. -- Section 1 -- Two pedantic comments/questions: 1) "The information model describes all the information elements required..." should "relationships" be included in the sentence ? 2) "The information model does not define the serialization, encoding, ordering, or structure of information elements, only their semantics." is nearly a pleonasm as it should be obvious for an information model as opposed to a data model. -- Section 2.1 -- How much this section about "REQUIRED", ... definitions contradicts/overlaps with section 1 definition of those terms ? -- Section 3.1 -- "manifest format" does it refer to draft-ietf-suit-manifest, if so, then a reference is required and how is this format is described ? -- Section 3.2 -- "A monotonically increasing sequence number" should this number be unsigned ? What about rollover ? -- Section 3.1.1 & 3.4.2 & 3.4.4 (and possibly others) -- s/vendorId = UUID5(DNS, "vendor-a.com")/vendorId = UUID5(DNS, "vendor-a.exmaple.com")/ -- Section 3.8 -- Should the type of "format" be specified in the information model ? (e.g., as an enum or a string or ...) especially when Vendor ID element is very detailed as UUID. -- Section 3.13 -- While I am not a security expert, I would associate "integrity" (and not "authenticity") with a "digest" that is not a HMAC. But, I am trusting your SEC AD and his review ;-) -- Section 4 -- The train has left the station of course but I really wonder what is the relationship of this section to an information model. NB: I do like the content though ;-) -- Section 7.1 -- I wonder whether the reference to draft-ietf-suit-architecture (informational) is really normative. == NITS == There are a couple of missing ',' after some words "but" "instead" "e.g." "for example" "typically" "therefore" ;-) -- Section 3.5 -- Would "prerequisite" be more suitable than "precursor" ? |
2020-12-03
|
08 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-12-03
|
08 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2020-12-03
|
08 | Robert Wilton | [Ballot comment] Thank you for your work on this document. Generally I found this document to fairly easy to read, although it did feel somewhat … [Ballot comment] Thank you for your work on this document. Generally I found this document to fairly easy to read, although it did feel somewhat back to front, although this is probably just personal style. I.e., I think that I would have preferred for the security considerations section to describe the threat model and threats, but for all the requirements and user stories to be documented early in the document before the manifest elements are described. Other than the document structure, I also have a question regarding Vendor ID and Class ID. Both of these use UUIDs, but it wasn't really clear to me why UUIDs are better than using a domain and a string. I appreciate that the stated goal is that these don't need to be human readable, but does this mean that it is only the device and device owner who is able to determine whether a particular firmware is compatible with a particular device. Is it not potentially helpful to provide a hint to the user as to whether the firmware described by a manifest might be suitable for a given device, or is that information available in some other way? Regards, Rob |
2020-12-03
|
08 | Robert Wilton | Ballot comment text updated for Robert Wilton |
2020-12-03
|
08 | Robert Wilton | [Ballot comment] Thank for your work on this document. Generally I found this document to fairly easy to read, although it did feel somewhat back … [Ballot comment] Thank for your work on this document. Generally I found this document to fairly easy to read, although it did feel somewhat back to front, although this is probably just personal style. I.e., I think that I would have preferred for the security considerations section to describe the threat model and threats, but for all the requirements and user stories to be documented early in the document before the manifest elements are described. Other than the document structure, I also have a question regarding Vendor ID and Class ID. Both of these use UUIDs, but it wasn't really clear to me why UUIDs are better than using a domain and a string. I appreciate that the stated goal is that these don't need to be human readable, but does this mean that it is only the device and device owner who is able to determine whether a particular firmware is compatible with a particular device. Is it not potentially helpful to provide a hint to the user as to whether the firmware described by a manifest might be suitable for a given device, or is that information available in some other way? Regards, Rob |
2020-12-03
|
08 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2020-12-02
|
08 | Murray Kucherawy | [Ballot comment] The "Special consideration ..." paragraph in Section 3.7 seems to be improperly split. In Section 3.8, isn't "This element is REQUIRED and MUST … [Ballot comment] The "Special consideration ..." paragraph in Section 3.7 seems to be improperly split. In Section 3.8, isn't "This element is REQUIRED and MUST be present" redundant? (Also in Section 3.10, possibly later too.) Is it legitimate that Section 4.4.3 satisfies itself? |
2020-12-02
|
08 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2020-12-02
|
08 | Benjamin Kaduk | [Ballot comment] (I did not attempt to cross-check that the forward- and backward- references among threats and mitigating requirements and manifest (envelope) elements are consistent. … [Ballot comment] (I did not attempt to cross-check that the forward- and backward- references among threats and mitigating requirements and manifest (envelope) elements are consistent. That said, I did by accident find one instance of apparent inconsistency, noted inline, so a dedicated pass to check these seems in order.) I'll also briefly mention here that I left a longer note about the delegation chain appearing to be a bit underspecified; that's probably the most important of my comments (the document in general is in good shape). Section 1 The information model describes all the information elements required to secure firmware updates of IoT devices from the threats described in Section 4.1 and enables the user stories captured in Section 4.4. The Introduction has to stand on its own, without the context of the Abstract. So, having the document start off like this is not great writing style; there's no previous discussion to justify the definite article in "the information model", for one, and we start off by just forward-referencing that other sections will do some things. Including the entire abstract contents wholesale before this would be a decent start, though additional editing is expected to be in order (the abstract and introduction play different roles and generally the one is not a strict subset of the other). Section 2 Secure time and secure clock refer to a set of requirements on time sources. For local time sources, this primarily means that the clock must be monotonically increasing, including across power cycles, firmware updates, etc. [...] But it doesn't have to be anywhere close to an actual reference time source, just monotonic? Section 3.3 identically named entities from different geographic regions from colliding in their customer's infrastructure. Recommended practice is to use [RFC4122] version 5 UUIDs with the vendor's domain name and the DNS name space ID. Other options include type 1 and type 4 UUIDs. We should probably pick one of 'version' and 'type' when referring to the UUID constructions. Section 3.4 Does "more granular" mean more fine-grained or more coarse-grained? Section 3.6 When a payload applies to multiple versions of a firmware, the required image version list specifies which versions must be present for the update to be applied. This allows the update author to It's really hard for me to parse "which versions must be present" as anything other than "there can be multiple versions present at the same time and all of the listed versions must be present", even though I suspect that the intent is that "the single version that is currently installed must be in the list of required versions". Section 3.10.2 A device supports a full filesystem. The Author chooses to use the nit: I suggest "full-featured filesystem", since "full filesystem" can be used to mean "a filesystem with no free space". Section 3.12 Where is "the resource" defined? I don't see it in this doc or in the architecture doc. The antepenultimate paragraph suggests that it is intended to be synonymous with the 'payload'... Section 3.15 This element is REQUIRED in non-dependency manifests and represents the foundation of all security properties of the manifest. Manifests which are included as dependencies by another manifest SHOULD include a signature so that the recipient can distinguish between different actors with different permissions. nit: maybe add a few more words to clarify that the actors being distinguished are the signers (authors?) of the various manifest contents? Section 3.16 I assume since this is IoT that the "additional installation instructions" will need to be machine-readable, but "install on sunday at 0200" and other examples could lead the reader to expect something human readable, especially when "run a script" is included as a separate option. It might be worth a bit of clarification. Section 3.18 A list of other manifests that are required by the current manifest. Manifests are identified an unambiguous way, such as a digest. "cryptographic digest" might be needed to ensure the desired property. Section 3.21 I'm not entirely sure what unqualified "source" and "destination" are intended to refer to in the context of loading a firmware image. Section 3.24 I don't think the text here is enough to give a picture of what the delegation chain is supposed to do. Later discussion suggests that it is a way to change or augment the set of entities authorized to sign (top-level) manifests, but this text seems to just talk about "authorization functionality" and not what is being authorized. (It also doesn't talk about what trust anchor the crypto chains to and whether it needs to be the same thing that the manifest signatures chain to, but that is perhaps excusable in an information model.) Section 4 We should probably mention the URI security considerations (RFC 3986) somewhere, as well as that remote resources need to receive an equal amount of cryptographic protection as the manifest itself, when dereferencing URIs. We might also discuss the risks when a device believes that it possesses a source of secure time but the timesource is actually flawed. It might also be worth reiterating the topic that came up during one of the other review threads: firmware update is *by definition* remote code execution, so if you trust an entity to provide your firmware, you are trusting them to do the right thing. Many classes of attack involving malicious or modified payloads then become irrelevant, so we are left with just needing to verify that it did come from a trusted party and is not going backwards, topics that are covered quite well already (including TOCTOU). Section 4.2 A bit of intro for the format of each subsection might be helpful; e.g., the optional presence of the "Threat Escalation" portion took me some time to understand. Section 4.2.9 If an attacker can install their firmware on a device, by manipulating either payload or metadata, then they have complete This feels like an "e.g." kind of thing, with payload and metadata modification not necessarily being an exhaustive list of ways to get an attacker's firmware on a device. Section 4.2.11.1 This is a denial of service because it can render devices inoperable. This is an elevation of privilege because it allows the attacker to make installation decisions that should be made by the Operator. In this example it seems like the decision was supposed to have been made by the Network Operator specifically, but perhaps I misunderstand. Section 4.3.4 The authenticity of an update MUST be demonstrable. Typically, this means that updates must be digitally authenticated. Because the manifest contains information about how to install the update, the manifest's authenticity MUST also be demonstrable. To reduce the overhead required for validation, the manifest contains the digest of the firmware image, rather than a second digital signature. The authenticity of the manifest can be verified with a digital signature or Message Authentication Code. The authenticity of the firmware image is tied to the manifest by the use of a digest of the firmware image. I suggest "cryptographic digest" here as well (twice). Section 4.3.5 Implemented by: Payload Format (Section 3.8), Storage Location (Section 3.10) I know I said I didn't try to cross-check these (which is true!), but I did notice that "Storage Location" was a bit funny for implementing an authenticated payload type, and indeed §3.10 does not mention REQ.SEC.AUTH.IMG_TYPE. Section 4.3.16 Status reports from the device to any remote system SHOULD be performed over an authenticated, confidential channel in order to prevent modification or spoofing of the reports. Why is this only SHOULD (not MUST)? Sections 4.3.16-4.3.20 None of these have "Implemented by" lines. Should they? Section 4.4.1 o Use a table of hashes to ensure that each block of the payload is validate before writing. nit: either "valid" or "validated". Section 4.4.7 As a firmware author, I want to prevent confidential information from being disclosed during firmware updates. It is assumed that channel security or at-rest encryption is adequate to protect the manifest itself against information disclosure. This is the "image confidentiality" section, so I'm not sure why we're talking about protecting the manifest itself. Section 4.5.3 Implemented by Manifest Element: Dependencies, StorageIdentifier, ComponentIdentifier (nit?) should this just be "Implemented by:"? Section 4.5.3.1 An IoT device with multiple microcontrollers in the same physical device (HeSA) will likely require multiple payloads with different component identifiers. Please expand HeSA. Section 4.5.9 systems. This requires the manifest to specify the digest of each statically linked dependency. In addition, the manifest format MUST I don't understand how this follows. Aren't statically linked dependencies incorporated into the image itself, in which case knowing their individual digest values serve no purpose? (Also, "cryptographic digest" again.) Section 4.5.12 The structure of the manifest MUST be simple to parse, without need for a general-purpose parser. I'm not sure what constitutes a "general-purpose parser" for this purpose. Section 7.1 RFCs 5652 and 8152 are in the context of a "such as" qualifier (even though it's for an overall MAY requirement), and as such probably don't strictly need to be classified as normative. |
2020-12-02
|
08 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2020-12-02
|
08 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-12-02
|
08 | Stephen Farrell | Request for Telechat review by IOTDIR Completed: Ready with Issues. Reviewer: Stephen Farrell. Sent review to list. |
2020-12-01
|
08 | Barry Leiba | [Ballot comment] This is good work, and thanks for doing it. I only have a few very minor comments: — Section 3.3.1 — vendorId … [Ballot comment] This is good work, and thanks for doing it. I only have a few very minor comments: — Section 3.3.1 — vendorId = UUID5(DNS, "vendor-a.com") Please use a BCP 32 domain name reserved for examples in documentation, here and throughout. I suggest “vendor-a.example” here. — Section 3.15 — It is NOT REQUIRED for a serialization to authenticate multiple manifests with a single Signature element. “NOT REQUIRED” is not a BCP 14 key word. I suggest just making the two words lower case. Also in Section 3.24. — Section 4.5.11 — It MUST be possible to place a payload in the same structure as the manifest. This MAY place the payload in the same packet as the manifest. The MAY appears to be a statement, not a protocol option, and should be “may” (or “might”). |
2020-12-01
|
08 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-11-30
|
08 | Erik Kline | [Ballot comment] [[ comments ]] [ section 3.20 ] * Is "XIP" eXecute In Place? I don't see this in abbrev.expansion.txt so perhaps it's … [Ballot comment] [[ comments ]] [ section 3.20 ] * Is "XIP" eXecute In Place? I don't see this in abbrev.expansion.txt so perhaps it's worth an expansion on first use. |
2020-11-30
|
08 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2020-11-30
|
08 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-11-20
|
08 | Samita Chakrabarti | Request for Telechat review by IOTDIR is assigned to Stephen Farrell |
2020-11-20
|
08 | Samita Chakrabarti | Request for Telechat review by IOTDIR is assigned to Stephen Farrell |
2020-11-20
|
08 | Éric Vyncke | Requested Telechat review by IOTDIR |
2020-11-18
|
08 | Derrell Piper | Request for Last Call review by SECDIR Completed: Not Ready. Reviewer: Derrell Piper. Sent review to list. |
2020-11-15
|
08 | Roman Danyliw | Placed on agenda for telechat - 2020-12-03 |
2020-11-15
|
08 | Roman Danyliw | IESG state changed to IESG Evaluation from Waiting for Writeup |
2020-11-15
|
08 | Roman Danyliw | Ballot has been issued |
2020-11-15
|
08 | Roman Danyliw | [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw |
2020-11-15
|
08 | Roman Danyliw | Created "Approve" ballot |
2020-11-15
|
08 | Roman Danyliw | Ballot writeup was changed |
2020-11-11
|
08 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2020-11-10
|
08 | Tim Evens | Request for Last Call review by GENART Completed: Ready. Reviewer: Tim Evens. Sent review to list. |
2020-11-10
|
08 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2020-11-10
|
08 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-suit-information-model-08, 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-information-model-08, 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-11-05
|
08 | Dave Thaler | Added to session: IETF-109: suit Fri-1430 |
2020-11-03
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martínez |
2020-11-03
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martínez |
2020-10-30
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Tim Evens |
2020-10-30
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Tim Evens |
2020-10-29
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Derrell Piper |
2020-10-29
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Derrell Piper |
2020-10-28
|
08 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2020-10-28
|
08 | Amy Vezza | The following Last Call announcement was sent out (ends 2020-11-11): From: The IESG To: IETF-Announce CC: suit@ietf.org, rdd@cert.org, suit-chairs@ietf.org, dthaler@microsoft.com, Dave … The following Last Call announcement was sent out (ends 2020-11-11): From: The IESG To: IETF-Announce CC: suit@ietf.org, rdd@cert.org, suit-chairs@ietf.org, dthaler@microsoft.com, Dave Thaler , draft-ietf-suit-information-model@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (An Information Model for Firmware Updates in IoT Devices) to Informational RFC The IESG has received a request from the Software Updates for Internet of Things WG (suit) to consider the following document: - 'An Information Model for Firmware Updates in IoT Devices' 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-11-11. 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 reliable and secure firmware update mechanism that is also suitable for constrained devices. Ensuring that devices function and remain secure over their service life requires such an update mechanism to fix vulnerabilities, to update configuration settings, as well as adding new functionality. One component of such a firmware update is a concise and machine- processable meta-data document, or manifest, that describes the firmware image(s) and offers appropriate protection. This document describes the information that must be present in the manifest. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-suit-information-model/ No IPR declarations have been submitted directly on this I-D. |
2020-10-28
|
08 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2020-10-28
|
08 | Roman Danyliw | Last call was requested |
2020-10-28
|
08 | Roman Danyliw | Last call announcement was generated |
2020-10-28
|
08 | Roman Danyliw | Ballot approval text was generated |
2020-10-28
|
08 | Roman Danyliw | Ballot writeup was generated |
2020-10-28
|
08 | Roman Danyliw | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2020-10-28
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-10-28
|
08 | Brendan Moran | New version available: draft-ietf-suit-information-model-08.txt |
2020-10-28
|
08 | (System) | New version approved |
2020-10-28
|
08 | (System) | Request for posting confirmation emailed to previous authors: suit-chairs@ietf.org, Henk Birkholz , Brendan Moran , Hannes Tschofenig |
2020-10-28
|
08 | Brendan Moran | Uploaded new revision |
2020-09-17
|
07 | Roman Danyliw | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2020-09-17
|
07 | Roman Danyliw | AD Review: https://mailarchive.ietf.org/arch/msg/suit/PCNgwoCRh_h0POes7ZYh6opYMJ8/ |
2020-07-31
|
07 | David Waltermire | Added to session: IETF-108: suit Fri-1100 |
2020-07-24
|
07 | Roman Danyliw | IESG state changed to AD Evaluation from Publication Requested |
2020-06-04
|
07 | Dave Thaler | Document shepherd writeup for draft-ietf-suit-information-model-07: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? … Document shepherd writeup for draft-ietf-suit-information-model-07: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Informational. Why is this the proper type of RFC? Document covers threat model and resulting requirements. The corresponding standards track document is the still-in-progress draft-ietf-suit-manifest. Is this type of RFC indicated in the title page header? Yes. (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. Ensuring that devices function and remain secure over their service life requires such an update mechanism to fix vulnerabilities, to update configuration settings, as well as adding new functionality One component of such a firmware update is a concise and machine- processable meta-data document, or manifest, that describes the firmware image(s) and offers appropriate protection. This document describes the information that must be present in the manifest. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Nothing worth noting. Consensus was straightforward, and a large number of participants provided feedback on earlier versions, as noted in the Acknowledgements section. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? This document is a set of threats and requirements and as such is not implemented directly. There are implementations of draft-ietf-suit-manifest which is one specification that meets the requirements in this document. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? This document has gone through many reviews with incremental changes over time. Section 6 (acknowledgments) contains a long list of those who have reviewed this document over time. If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? N/A Personnel: Who is the Document Shepherd? Dave Thaler Who is the Responsible Area Director? Roman Danyliw (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 manual review of the doc, and also checked it against id-nits. (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. Nothing specific needed. The primary purpose is a threat model document and resulting security requirements and this was done in a security area working group. (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? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None filed. (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? This document has solid WG consensus, with many reviewers. (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.) None. (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. ID nits warnings: == There are 168 instances of lines with non-RFC2606-compliant FQDNs in the document. All of these are false positives. Requirements and use cases are named with a format like 'REQ.USE.PARSE' which is not an FQDN and ID-notes reports "Found possible FQDN". Verified that it is clear there are not FQDNs. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A (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? draft-ietf-suit-architecture-11 will be submitted at the same time (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. No (16) Will publication of this document change the status of any existing RFCs? No 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. N/A (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 8126). This document does not require any actions by IANA. Document shepherd verified that none 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. None 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, YANG modules, etc. N/A. No formal languages used. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? N/A. No YANG module here. |
2020-06-04
|
07 | Dave Thaler | Responsible AD changed to Roman Danyliw |
2020-06-04
|
07 | Dave Thaler | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2020-06-04
|
07 | Dave Thaler | IESG state changed to Publication Requested from I-D Exists |
2020-06-04
|
07 | Dave Thaler | IESG process started in state Publication Requested |
2020-06-04
|
07 | Dave Thaler | Per WG charter |
2020-06-04
|
07 | Dave Thaler | Intended Status changed to Informational from None |
2020-06-04
|
07 | Dave Thaler | Per WG charter |
2020-06-04
|
07 | Dave Thaler | Intended Status changed to Informational from None |
2020-06-04
|
07 | Dave Thaler | Document shepherd writeup for draft-ietf-suit-information-model-07: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? … Document shepherd writeup for draft-ietf-suit-information-model-07: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Informational. Why is this the proper type of RFC? Document covers threat model and resulting requirements. The corresponding standards track document is the still-in-progress draft-ietf-suit-manifest. Is this type of RFC indicated in the title page header? Yes. (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. Ensuring that devices function and remain secure over their service life requires such an update mechanism to fix vulnerabilities, to update configuration settings, as well as adding new functionality One component of such a firmware update is a concise and machine- processable meta-data document, or manifest, that describes the firmware image(s) and offers appropriate protection. This document describes the information that must be present in the manifest. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Nothing worth noting. Consensus was straightforward, and a large number of participants provided feedback on earlier versions, as noted in the Acknowledgements section. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? This document is a set of threats and requirements and as such is not implemented directly. There are implementations of draft-ietf-suit-manifest which is one specification that meets the requirements in this document. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? This document has gone through many reviews with incremental changes over time. Section 6 (acknowledgments) contains a long list of those who have reviewed this document over time. If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? N/A Personnel: Who is the Document Shepherd? Dave Thaler Who is the Responsible Area Director? Roman Danyliw (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 manual review of the doc, and also checked it against id-nits. (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. Nothing specific needed. The primary purpose is a threat model document and resulting security requirements and this was done in a security area working group. (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? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None filed. (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? This document has solid WG consensus, with many reviewers. (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.) None. (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. ID nits warnings: == There are 168 instances of lines with non-RFC2606-compliant FQDNs in the document. All of these are false positives. Requirements and use cases are named with a format like 'REQ.USE.PARSE' which is not an FQDN and ID-notes reports "Found possible FQDN". Verified that it is clear there are not FQDNs. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A (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? draft-ietf-suit-architecture-11 will be submitted at the same time (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. No (16) Will publication of this document change the status of any existing RFCs? No 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. N/A (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 8126). This document does not require any actions by IANA. Document shepherd verified that none 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. None 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, YANG modules, etc. N/A. No formal languages used. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? N/A. No YANG module here. |
2020-06-02
|
07 | Hannes Tschofenig | New version available: draft-ietf-suit-information-model-07.txt |
2020-06-02
|
07 | (System) | New version approved |
2020-06-02
|
07 | (System) | Request for posting confirmation emailed to previous authors: Henk Birkholz , Brendan Moran , Hannes Tschofenig , suit-chairs@ietf.org |
2020-06-02
|
07 | Hannes Tschofenig | Uploaded new revision |
2020-06-01
|
06 | Hannes Tschofenig | New version available: draft-ietf-suit-information-model-06.txt |
2020-06-01
|
06 | (System) | New version approved |
2020-06-01
|
06 | (System) | Request for posting confirmation emailed to previous authors: Hannes Tschofenig , Henk Birkholz , suit-chairs@ietf.org, Brendan Moran |
2020-06-01
|
06 | Hannes Tschofenig | Uploaded new revision |
2020-05-26
|
05 | David Waltermire | Notification list changed to Dave Thaler <dthaler@microsoft.com> |
2020-05-26
|
05 | David Waltermire | Document shepherd changed to Dave Thaler |
2020-02-19
|
05 | Dave Thaler | Added to session: interim-2020-suit-01 |
2020-01-20
|
05 | Brendan Moran | New version available: draft-ietf-suit-information-model-05.txt |
2020-01-20
|
05 | (System) | New version approved |
2020-01-20
|
05 | (System) | Request for posting confirmation emailed to previous authors: suit-chairs@ietf.org, Henk Birkholz , Brendan Moran , Hannes Tschofenig |
2020-01-20
|
05 | Brendan Moran | Uploaded new revision |
2019-11-17
|
04 | David Waltermire | Added to session: IETF-106: suit Tue-1330 |
2019-11-17
|
04 | David Waltermire | IETF WG state changed to In WG Last Call from WG Document |
2019-10-30
|
04 | Brendan Moran | New version available: draft-ietf-suit-information-model-04.txt |
2019-10-30
|
04 | (System) | New version approved |
2019-10-30
|
04 | (System) | Request for posting confirmation emailed to previous authors: suit-chairs@ietf.org, Henk Birkholz , Brendan Moran , Hannes Tschofenig |
2019-10-30
|
04 | Brendan Moran | Uploaded new revision |
2019-07-12
|
03 | Russ Housley | Added to session: IETF-105: suit Wed-1000 |
2019-07-08
|
03 | Brendan Moran | New version available: draft-ietf-suit-information-model-03.txt |
2019-07-08
|
03 | (System) | New version approved |
2019-07-08
|
03 | (System) | Request for posting confirmation emailed to previous authors: suit-chairs@ietf.org, Henk Birkholz , Brendan Moran , Hannes Tschofenig |
2019-07-08
|
03 | Brendan Moran | Uploaded new revision |
2019-03-04
|
02 | Dave Thaler | Added to session: IETF-104: suit Wed-0900 |
2019-01-18
|
02 | Hannes Tschofenig | New version available: draft-ietf-suit-information-model-02.txt |
2019-01-18
|
02 | (System) | New version approved |
2019-01-18
|
02 | (System) | Request for posting confirmation emailed to previous authors: suit-chairs@ietf.org, Henk Birkholz , Brendan Moran , Hannes Tschofenig |
2019-01-18
|
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-information-model-01.txt |
2018-07-02
|
01 | (System) | New version approved |
2018-07-02
|
01 | (System) | Request for posting confirmation emailed to previous authors: Jaime Jimenez , suit-chairs@ietf.org, Henk Birkholz , Brendan Moran , Hannes Tschofenig |
2018-07-02
|
01 | Hannes Tschofenig | Uploaded new revision |
2018-06-15
|
00 | Russ Housley | Added to session: interim-2018-suit-03 |
2018-06-04
|
00 | Dave Thaler | This document now replaces draft-moran-suit-architecture instead of None |
2018-06-04
|
00 | Hannes Tschofenig | New version available: draft-ietf-suit-information-model-00.txt |
2018-06-04
|
00 | (System) | WG -00 approved |
2018-06-04
|
00 | Hannes Tschofenig | Set submitter to "Hannes Tschofenig ", 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 |