Skip to main content

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