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"? -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
