BTW, thinking about this a little more, if anyone is to choose not to implement encryption or key exchange algorithms, would not that be the authors, not the recipients? Authors seems to be in the position to determine if they want to encrypt or not? But if they want to, then they would have to be able to rely on recipients supporting them?
On Tue, Jun 3, 2025 at 4:24 PM Magnus Nyström via Datatracker <noreply@xxxxxxxx> wrote:
Document: draft-ietf-suit-mti
Title: Mandatory-to-Implement Algorithms for Authors and Recipients of Software
Update for the Internet of Things manifests Reviewer: Magnus Nyström Review
result: Not Ready
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"?
_______________________________________________
secdir mailing list -- secdir@xxxxxxxx
To unsubscribe send an email to secdir-leave@xxxxxxxx
wiki: https://wiki.ietf.org/group/secdir/SecDirReview
--
-- Magnus
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
