The draft describes a means by which firmware - as identified by a SUIT manifest - might have confidentiality protection added. Though this is not entirely clear from the draft, a reason that this might be useful is where the distribution system operates at a lower level of trust to the source of firmware (the author) and the devices that will run it. For those cases where encryption keys use symmetric ciphers (AES-KW), this assumes that there is a parallel (but unspecified and unmentioned) system for the distribution of content keys to devices; the use of asymmetric cryptography might permit a more direct means of wrapped keys, but that means the creation of per-key (likely per-device) manifests. This leads to the first issue: the design in the draft leads to some intermingling of the functions performed by the roles of author and distributor (a term I will use instead of "distribution system" as it has fewer characters for me to type). This occurs due to the fact that encryption parameters being covered by the signature that covers the manifest. Two options are considered: * The author needs to obtain a complete list of the keys held by devices that will receive the firmware. This means having the author take on many of the responsibilities of the distributor. * The distributor needs to generate a fresh manifest for each recipient with per-device encryption keys. This means giving the distributor access to the plaintext of the manifest. This is not really addressed in the security considerations. It's not clear to me who the encryption protects against in that case. Note that the latter also means giving the distributor a signing key, but any risk there is managed by the use of a two-layer manifest, as described in draft-ietf-suit-trust-domains. Ultimately, the effect of this choice is to largely eliminate any useful distinction between the roles of author and distributor, which leads me to question the value of building up the edifice in the first place. The lack of a threat model makes it hard to know whether the design meets the design goals. Is the goal to protect against the distributor, or are there unspecified others that the encryption is deployed against? The draft does not really make it clear why an alternative design is infeasible. That is, one where integrity information based on the *plaintext* of the firmware is delivered as part of the manifest (a hash would suffice) and encryption keys are delivered separately, such that there is no need to re-sign the manifest when the keys change. In particular, this would be compatible with the non-AEAD usage in the document. I don't know a lot about COSE, but it seems like the unprotected field of COSE_Sign would do the job here. In Section 5, the draft says that it redefines the write and copy directives, but doesn't actually say what the redefinition is in any concrete terms. It really only offers specification by way of examples, which isn't ideal. I would have expected something like: Where suit-directive-write instructs the device to take content and write it to a specific location, that directive is changed to perform decryption of the indicated content while executing the write operation, using the information provided in suit-parameter-encryption-info. This introduces new failure modes for the operation if the encryption method uses an AEAD (if the input content cannot be successfully authenticated) or a CBC (if the padding is invalid). Also in Section 5, the draft describes the use of suit-parameter-image-digest for a referenced image, but equivocates about whether this applies to the ciphertext or the plaintext. That sort of equivocation has no place in a specification. While it might be possible to check a digest both before and after decryption, it is relatively easy to specify which. If the ordering of parameters determines which, say that, though I suspect that this would be inadvisable due to the way that the processing model writes override parameters. UPDATE: I just found Section 8. Yikes. Why is this hidden so far down? That's better, but still not very clear. There is an ordering that applies here and this does not establish that. The implication is that the digest applies AFTER the decryption if they are part of the same directive, but the text never actually says that. The draft defines the use of AES-CBC. I see no value in using that scheme. AES-CTR has value in that it doesn't change the size of the ciphertext. An AEAD has the advantage of being able to bind additional context and perform data origin authentication in exchange for the extra padding. CBC modes offer none of those advantages, but expand the size by almost the same amount. The draft does not set constraints on the size of the ciphertext. It should. For battery exhaustion attacks, it seems like having to obtain - and maybe process - the entire image before being able to authenticate any part of it is a big part of why there is a problem. Presumably it is not always possible to hold an entire image at once, so if the digest were able to be incrementally validated, that would be a useful defense. Note that in the absence of a key-committing AEAD, I'm not sure that having multiple AEAD tags would be a useful defense, though it might be of some help in narrowing the attack profile. The lack of key commitment makes me uncertain about Q3 in the flow chart in Section 8.2; I believe than attacker that can modify the CEK (again: threat model? what are the capabilities of the adversary?) is able to produce a variant key that will pass AEAD validation on a given ciphertext. I'd suggest a simple list of hashes with a chunk size parameter (which could be some cardinal multiple of the sector size if you prefer), rather than a single hash. Nits: Section 6 introduces notation that looks like function invocations, except that it is not. In LaTeX, I would write CEK(R, S) with a subscript as $\mathsf{CEK}_{R,S}$. This is somewhat confusing as ENC(K, V) is a function. I recommend the use of square brackets. For example, 6.1.2 would have: 1. Fetch KEK[*, S] 2. Generate CEK 3. ENC(CEK, KEK[*, S]) 4. ENC(payload, CEK). Note also that there is a established convention whereby the first parameter to a PRF or encryption function is the key; this draft inverts that, which could be confusing when both inputs are keys of one form or other. The draft consistently fails to use for section references to other RFCs or drafts. This is just as easy to type as what is there, but it makes someone else do a bunch of work. Fixing it should be easy enough too. Section 12 has a wonderful table that is drawn using ascii art, which is then converted to an SVG. Please use a table. For the fancy diagrams showing the cipher modes (which are entirely unnecessary, in my view, there are citations you can use) aasvg recognizes ⊕, which would make the SVG more comprehensible; presently it is not. Figure 11 references the previous diagram for a legend. That diagram (Figure 1) does not include a legend; the next one (Figure 14) does. As far as legends go, it might be better to have those in text, rather than the figure. Many of the CDDL or diagnostic output figures are wider than the 72 column format permits. In Section 7, "For these ciphers the Enc_structure, shown in Figure 8, MUST NOT be used because the Additional Authenticated Data (AAD) byte string is only consumable by AEAD ciphers." -> s/MUST NOT/cannot/ In Section 7.3.1 (CBC), I don't understand this statement: "The numbering of sectors in a slot MUST start with zero (0) and MUST increase by one with every sector till the end of the slot is reached. The IV follows this numbering." There is a single IV input to AES-CBC. Section 7.3.1 also mentions AES-CTR-128, despite being about CBC.