A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices
draft-ietf-suit-information-model-13

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

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?

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" ?

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.

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”).

(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.

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