Skip to main content

IETF Last Call Review of draft-ietf-suit-mti-16
review-ietf-suit-mti-16-secdir-lc-nystrom-2025-06-03-00

Request Review of draft-ietf-suit-mti
Requested revision No specific revision (document currently at 22)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2025-06-12
Requested 2025-05-29
Authors Brendan Moran , Øyvind Rønningstad , Akira Tsukamoto
I-D last updated 2025-07-10 (Latest revision 2025-07-07)
Completed reviews Secdir IETF Last Call review of -16 by Magnus Nyström (diff)
Artart IETF Last Call review of -16 by Barry Leiba (diff)
Opsdir IETF Last Call review of -18 by Jouni Korhonen (diff)
Genart IETF Last Call review of -17 by Linda Dunbar (diff)
Iotdir Telechat review of -18 by Lorenzo Corneo (diff)
Secdir Telechat review of -18 by Magnus Nyström (diff)
Assignment Reviewer Magnus Nyström
State Completed
Request IETF Last Call review on draft-ietf-suit-mti by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/oyh444tWkLcOvq7BriZx3VYGQOo
Reviewed revision 16 (document currently at 22)
Result Not ready
Completed 2025-06-03
review-ietf-suit-mti-16-secdir-lc-nystrom-2025-06-03-00
Section 1:
- This section has the title "Introduction" yet it is normative. It may be
better to have a short intro section which is not normative and then a separate
section that provides the introductory requirements. Or aLternatively, make it
explicit that the section is normative. - "SUIT will define five choices of
Mandatory To Implement (MTI) profile [sic] specifically for constrained node
software update. These profiles are: One Symmetric MTI profile Two "Current"
Constrained Asymmetric MTI profiles Two "Current" AEAD Asymmetric MTI profiles
One "Future" Constrained Asymmetric MTI profile"

- This seems to be six profiles, not five?
- Would be good to clarify here or elsewhere what "Current" and "Future" means

"At least one MTI algorithm in each category MUST be FIPS qualified"

-  What does "qualified" mean? Not defined.

"Recipients MAY choose which MTI profile they wish to implement...Recipients
MAY implement any number of other profiles"

- Given the second statement, the first statement seems to incorrectly imply
they can only implement one. - As written, a recipient would be compliant not
implement any profile. Therefore, it may be good to modify this to: "Recipients
MUST implement at least one MTI profile." - This makes it clear they have to,
but it also allows them to choose, and the second sentence above can be removed.

"This specification makes use of AES-CTR with a digest algorithm in COSE as
specified in ([RFC9459]). AES-CTR is used because it enables out-of-order
reception and decryption of blocks, which is necessary for some constrained
node use cases. Out-of-order reception with on-the-fly decryption is not
available in the preferred encryption algorithms.

- What is COSE? Acronym introduced w/o explanation.
- "on-the-fly" decryption is not defined
- "preferred" crypto algorithms is not defined.

Section 2.

"Key Exchange Algorithms (OPTIONAL)
 Encryption Algorithms (OPTIONAL)"

- Why does a draft with the title "Mandatory to Implement Algorithms" care to
introduce OPTIONAL algorithms? Also does this mean that the statement in
Section 1 about not implementing encryption algorithms (see below as well)
extends to key exchange algorithms?

Section 3.

- What does "recognized" mean? Not defined.

Section 3.6

"deep trees are RECOMMENDED"

- "deep" is not defined. If defined elsewhere, please provide references.

Section 4.

- "Manifest Recipients Response" is not defined. Please provide reference.
- "closest equivalent" is ambiguous. Needs a definition.

Section 5 and Section 5.1

"payload encryption of firmware or software updates of a commodity device is
not a cybersecurity defense against targetted [sic] attacks on that device"

- Section 5.1 does talk about how attackers may find bugs by code inspection.
If the payload of a firmware update is not encrypted, they could use that to
find bugs in the updated code. Thus, encryption of firmware updates may also
serve as a security defense, contradicting the quote above.

Section 5.2

"Out-of-order decryption must be supported"

- Supported by whom? Does this not contradict both the statement in Section 1
that "Recipients MAY choose not to implement an encryption algorithm if
encrypted payloads will never be used"? (BTW, how would a recipient know that
encrypted payloads never will be used?) - Why is this "must" non-normative?

"the payloads are typically constructed in a relatively secure environment--the
developer's computer"

- Please remove the latter part of this statement. There are an enormous number
of incidents that have occurred due to attackers being able to access a
developer's computer ...

"In short, the plaintext is authenticated prior to encryption"

- Also incorrect, it is not authenticated. It may be trusted, but not
authenticated.

"Content Encryption Keys must be used to encrypt only once."

- Is this a new requirement? If so, why the non-normative "must"?

Thanks,
M

"AES-CTR is an acceptable cipher"

Was this meant to say "AES-CTR without AEAD is an acceptable cipher mode"?