Hello COSE WG! I raised my hand at IETF 121 and promised Hannes and the authors of draft-tschofenig-cose-cek-hkdf-sha256-02 a review!
I am deeply sorry for the late review, I think it is late to do any meaningful change in time to the written draft, but at least it might help oral discussion for IETF 122. Also, disclaimer, I am not up-to-date with all the inners of the referenced documents. But maybe in the future I will, and I can have another review if needed. So, here are my comments (I mix editorial and content comments) : --------------- Section 1. Introduction , --------------- "content-encryption key" Maybe put the acronym the first time we mention it (was also mentioned in the abstract)? --> "content-encryption key (CEK)" "The use of this mechanism provides protection against where the attacker" I think we are missing a noun? "protection against SOMETHING" e.g., "protection against attacks where.." "against where" sounds bad to me but I am no native english speaker. Precondition 1. "such as AES-GCM to AES-CBC" ---> " such as AES-CCM or AES-GCM " ? Reading rfc9709 and the attack referenced on it RS2023, it seems that the downgrade attack only works for an AEAD mode of AES, if this is correct then we should NOT put AES-CBC here (as an example)? (and on the wording of rfc9709 they explicitly say "either AES-CCM or AES-GCM" ). For (plain) AES-CBC will be a mix-up but in that case as there is no authentication there will be no "error" response message so the attack does not work. ABOUT the "HKDF" function name: In line with RFC9709, the function "CEK' = HKDF(CEK, COSE_Encrypt.alg)" can be named to something like "CEK' = COSE_CEK_HKDF_SHA256(CEK, COSE_Encrypt.alg)" And then, also have an equivalent Appendix to "Appendix B. CMS_CEK_HKDF_SHA256 Function Examples" --------------- Section 3. Updated Encryption Flow for each Content Key Distribution Method --------------- Very useful section, shall some of the "content key distribution methods" be referenced as Informative references? (for instance COSE-HPKE https://datatracker.ietf.org/doc/html/draft-ietf-cose-hpke-11 ?). I understand that this countermeasure is independent of the Key derivation method in particular, and shall work even for those which will exist in the future, however it is very useful to know about the different "archetypes" of CEK/eCEK generation (as is the goal of this section). Figure 1 --> For COSE-HPKE instead of "open" should be "seal" Figure 2 label "Payload Encryption Flow for each Content Key Distribution Method" , comment in the same line as before, are these all the Content Key Distribution Methods that exist as of March 2025 for COSE, or just a few examples? So maybe clarify at the beginning of the section, something like "we are showing the current methods just as examples" "TODO: provide an example binary (in appendix?)" --> Yes! Binary or CDDL? OK for appendix. --------------- Section 5 Use of of HKDF with SHA-256 to Derive Encryption Keys --------------- Ok, here I position myself in the mind of an engineer that will implement this on real hardware/sw. I am about to feed/call the HKDF-Extract and HKDF-Expand functions . Does the information we have is enough that both sender and receiver will feed the same thing? Maybe I am overthinking it but.. In particular: * alg === "COSE_Key algorithm identifier" ; I know is defined in IANA and can be tstr / int , and unequivocally take the type/value defined in "COSE Algorithms" , so we feed directly the binary representation as is (so actually no ambiguity here, sorry) * salt === "CBOR Object Signing and Encryption" ; so we feed an ASCII representation of this string? (In C language when we define an array of chars they are always NULL terminated, so can be a source of error depending on how this is implemented on both sender/receiver) do we want to be more rigorous of how we will feed the bits of this salt? (maybe a CBOR string?) In any case, an example in the appendix will disperse any possible ambiguity. --------------- END --------------- That's all from my side! sorry for the quite late feedback... Saludos, Renzo _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
