Hi Magnus,
Thank you for your review.
Applied the changes and submitted the revised draft suit-mti-18.
Thank you for your review.
Applied the changes and submitted the revised draft suit-mti-18.
On Thu, Jun 12, 2025 at 7:43 PM Hannes Tschofenig <hannes.tschofenig@xxxxxxxx> wrote:
Hi Magnus,
thanks for your detailed review.
I have created a PR based on your feedback, see
https://github.com/suit-wg/suit-mti/pull/41, and this PR has already
been merged by the draft authors.
Let me provide you feedback below.
Am 04.06.2025 um 01:22 schrieb Magnus Nyström via Datatracker:
> 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.
While there is nothing that requires that an introduction does not
contain normative text, I have updated the introduction to avoid
normative language.
> - "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?
We fixed this issue based on a previous review already.
> - Would be good to clarify here or elsewhere what "Current" and "Future" means
I added text:
"
The terms "current" and "future" distinguish between traditional
cryptographic algorithms and those believed to be secure against both
classical and quantum computer-based attacks, respectively.
"
>
> "At least one MTI algorithm in each category MUST be FIPS qualified"
> - What does "qualified" mean? Not defined.
I removed this statement because it does not add any value. The
background for how the current algorithms combinations were selected is
not relevant at this point in time.
>
> "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.
I also removed this statement without loss of functionality.
> "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.
I changed the description in this paragraph. It refers to text in the
firmware encryption draft.
> 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?
Good point. I changed the title of the document to make this clear.
>
> Section 3.
>
> - What does "recognized" mean? Not defined.
I deleted the term.
>
> Section 3.6
>
> "deep trees are RECOMMENDED"
>
> - "deep" is not defined. If defined elsewhere, please provide references.
I added text. The "tree" concept refers to HSS-LMS functionality. Here
is the new text:
"
A note regarding the use of HSS-LMS: The decision as to how deep the
tree is, is a decision that affects authoring tools only (see
[RFC8778]).
"
> Section 4.
>
> - "Manifest Recipients Response" is not defined. Please provide reference.
> - "closest equivalent" is ambiguous. Needs a definition.
I have modified the text in this PR:
https://github.com/suit-wg/suit-mti/pull/46
>
> Section 5 and Section 5.1
The purpose of this document is not to explain the value of firmware
encryption.
The draft references another specification that defines firmware
encryption, which provides this background.
I added text to improve wording and removed text where we attempted to
summarize these drafts in a few lines.
Here is the PR:
https://github.com/suit-wg/suit-mti/pull/45
>
> "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"?
>
>
Ciao
Hannes
> _______________________________________________
> Suit mailing list -- suit@xxxxxxxx
> To unsubscribe send an email to suit-leave@xxxxxxxx
>
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
