A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices
draft-ietf-suit-information-model-13
Yes
Roman Danyliw
No Objection
(Alvaro Retana)
(Deborah Brungard)
(Magnus Westerlund)
Note: This ballot was opened for revision 08 and is now closed.
Roman Danyliw
Yes
Erik Kline
No Objection
Comment
(2020-11-30 for -08)
Sent
[[ 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.
Murray Kucherawy
No Objection
Comment
(2020-12-02 for -08)
Sent
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?
Éric Vyncke
No Objection
Comment
(2020-12-03 for -08)
Sent
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" ?
Alissa Cooper Former IESG member
No Objection
No Objection
(2020-12-03 for -08)
Sent
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.
Alvaro Retana Former IESG member
No Objection
No Objection
(for -08)
Not sent
Barry Leiba Former IESG member
No Objection
No Objection
(2020-12-01 for -08)
Sent
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”).
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2020-12-02 for -08)
Sent
(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.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -08)
Not sent
Magnus Westerlund Former IESG member
No Objection
No Objection
(for -08)
Not sent
Robert Wilton Former IESG member
No Objection
No Objection
(2020-12-03 for -08)
Sent for earlier
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