Telechat Review of draft-ietf-suit-mti-18
review-ietf-suit-mti-18-secdir-telechat-nystrom-2025-06-30-00

Title.
- Some algorithms (profiles) are intended to be mandatory. Why not just remove
"recommendations"?

1. Introduction
-       "This document defines algorithm profiles for SUIT manifest parsers and
authors to promote interoperability in constrained node software update
scenarios. These profiles specify sets of mandatory-to-implement (MTI)
algorithms tailored to the evolving security landscape, acknowledging that
cryptographic requirements may change over time. To accommodate this,
algorithms are grouped into profiles, which may be updated or deprecated as
needed." a)      Why "parsers and authors" and not "authors and recipients" or
only "parsers"? Why are not recipients mentioned here when they are elsewhere
in the doc? Also, AFAICT, this is the only mention of the term “parsers.” b)   
  Not all profiles are MTI. c)      It is odd to only in the last sentence
describe the profiles' purpose. Instead, I suggest something like: "To promote
interoperability in constrained node software update scenarios, this document
defines cryptographic algorithms for SUIT manifest authors and recipients. To
accommodate an evolving security landscape where cryptographic requirements may
change over time, algorithms are grouped into profiles, which may be updated or
deprecated as needed.”

-       Since not all profiles are MTI – in fact, no single profile is MTI
since recipients can choose (Section 3: “Recipients MAY choose…”), it seems
better not to call them MTI profiles and instead just call them profiles, e.g.
“One symmetric profile.” -       See comment below on the use of “Current” and
“Future.” -       I still don’t understand what “FIPS validated” means. Did you
intend to say that the implementation of the algorithm must be FIPS certified
in accordance with FIPS 140-3? Or something else?

3. Profiles
-       My comment on the use of the “MTI profile” term is as above. Suggest
removing “MTI.” -       “Recipients MAY choose not to implement encryption and
the corresponding key exchange algorithms if they do not intend to support
encrypted payloads. … Authors MUST implement all MTI profiles.” - I still fail
to understand how interoperability will be achieved if recipients only support
a single profile. Are authors able to learn, through some other mechanism, what
profile a given recipient support? It seems easier if the requirements were the
other way around, i.e., recipients support all profiles since then, regardless
of what profile an author uses, the recipient will be able to validate (and
possibly decrypt) the message.

-       I suggest removing “Current” as a prefix for those profiles that use it
and replace “Future” with “Post-quantum” for those profiles that use that term
since: a)      What is considered “current” and “future” varies over time b)   
  Post-quantum is what it appears that you refer to with the use of “future.”
This would also suggest updating the corresponding sentence in Section 1.

5. Security Considerations
-       “The primary function of payload in SUIT is to act as a defense against
passive IP and PII snooping. By encrypting payloads, confidential IP and PII
can be protected during distribution. However, payload encryption of firmware
or software updates of a commodity device is not a cybersecurity defense
against targetted attacks on that device.” a)      The acronyms “IP” and “PII”
have not been explained b)      (nit) “targetted” -> “targeted” c)      Please
explain why encryption of a payload cannot be a cybersecurity defense. If the
payload is a security patch for a vulnerability not publicly known, sending the
payload in plan text discloses to the world the existence of that
vulnerability. Contrary to what is stated in Section 5.1, this does not require
the ability to “extract code from physical devices” – you get the code just by
intercepting the unencrypted payload.