I’m replying to my own email with a list of things in COSE_KDF_Context and their purposes. I think we need to understand to decide what to do. I may not have the purpose right for some, so please comment.
Algorithm ID Binds the output key material of the HKDF to the algorithm that key material will be used with. The purpose is explained fairly well in RFC 9053. This binding doesn’t occur any other place in COSE so this is not optional. The value of this comes algorithm IDs in other parts of the COSE protocol. HPKE takes care of this internally for COSE-HPKE single recipient mode, but not for multiple recipient mode. This seems valuable even if there is no HKDF (e.g. plain AES Key Wrap), but you’d have to do an explicit alg ID comparison rather than rely on KDF perturbing the key. Sender/Receiver Info (e.g. Party U) Appendix B of NIST SP800-56A gives the rationale referencing some papers describing attacks. This is fairly esoteric for me so far so I can't give a plain explanation. I’m still kind of looking for good guidance on how / when to use this. It seems like this is defense-in-depth rather than essential unless your use case is poorly constructed in some way. However, I think the bottom line is that is best practice nowadays, so for example COSE libraries should really support it. HPKE SealBase() doesn’t provide this. Sender and Receiver Info Nonce A means, among many, to bind to a particular individual message between the sender and receiver. This is very optional, but also not difficult to provide. The same security effects can be obtained by using the salt (and the salt seems simpler so I think it would be preferred). HPKE doesn’t provide this. SuppPubInfo.keyDataLength The output of the KDF is a key used by some algorithm like AES-GCM or AES Key Wrap. This is the number of bits in the key needed for that algorithm. RFC 9053 seems to say this is needed when the target algorithm allows multiple key sizes, however we don’t seem to use such algorithms. I don’t see any symmetric algorithms registered for COSE that have variable key size. The Algorithm ID above is enough so far. Never, the less, this is mandatory per RFC 9053 and thus must be implemented. HPKE provides this internally for COSE-HPKE single recipient, but not for COSE-HPKE multiple recipient. (Rhetorical question — Why is this in SuppPubInfo and not a peer to AlgorithmID in the CBOR encoding or why is AlgorithmID not in SuppPubInfo?) SuppPubInfo.protected This is the super-important part that protects the protected COSE header parameters. Absolutely not optional. In COSE-HPKE draft-05, this is taken care of by using an Enc_structure with context “Enc_Recipient”, but we could (should) change COSE-HPKE to line up better with the rest of COSE. For some COSE, like AES Key Wrap that has no AEAD or HKDF there is no protection here. Other — Hash of ciphertext Hannes has proposed that a hash of the SUIT_Digest be included here. In practice I think this is a hash of ciphertext in the COSE_Encrypt. I’d like to call this into question because I don’t see this in the list in NIST SP800-56A section 5.8.1.2. Implementing it adds complexity and computational cost because it is a hash over something the size of the payload. HPKE could have done this internally, but I don’t think it does. The question is, what attack does this prevent? I would assume this is specific to firmware encryption because if it were a general attack, then COSE, HPKE and/or NIST SP800-56A would have addressed it. (I confess to not reading NIST SP800-56A so much yet so maybe I’m missing something). Based on this, I conclude that COSE-HPKE must support most of the above. Probably that is by using COSE_KDF_Context instead of Enc_structure with context “Enc_Recipient”. Specifically, because: * Binding to the content encryption algorithm and its key length for multiple recipient HPKE is not optional in COSE * Need to provide PartyU and PartyV like the rest of COSE and also like JOSE and to support NIST SP800-56A which seems to be best practice * General consistency with COSE All that said, this seems like defense-in-depth to me. If none of this were implemented, most COSE-secured protocols still seem hard to break. This isn’t like using a bad RNG or like using counter mode wrong. However, it’s best practice so we should support most of it. LL On May 31, 2023, at 10:13 AM, Laurence Lundblade <[email protected]<mailto:[email protected]>> wrote: It seems to me that RFC 9052 section 5.3 defines an Enc_structure with context “Enc_Recipient”, but nothing in RFC 9052 or 9053 makes use of it. I’m 75% confident that Jim’s code does the same. This is confusing and seems a dark corner of COSE that needs illuminating. The purpose of Enc_structure with context “Enc_Recipient” would seem to be for COSE_Recipients that are used in COSE_Encrypt. It’s how the integrity protection of the protected headers is achieved, how the COSE_Recipient is bound into a COSE_Encrypt (so it can’t be cut/paste into a COSE_Mac) and how Externally Supplied Data is double-protected (previous HPKE-related discussion about this). BUT, all the ECDH + HKDF key agreement methods use RFC 9053 section 5.2 COSE_KDF_Context (AKA Info struct) instead. COSE_KDF_Context definitely covers the protected headers. It also provided binding to sender/receiver and some other bindings. Look at all the encrypt key agreement methods in 9053 section 6 and see none use Enc_structure: - ECDH + HKDF — COSE_KDF_Context is always the input to the info parameter for HKDF - Key wrap — Not possible to protect the headers, so nothing, no use of Enc_structure or COSE_KDF_Context - Direct — Same as key wrap In HPKE we defined use of Enc_structure with context “Enc_Recipient” as the “info” parameter to SealBase. I now believe that was wrong and it should be COSE_KDF_Context instead. I don’t think the extensive context hashing in HPKE provides everything that COSE_KDF_Context does (maybe HPKE Auth mode does, but Base mode doesn’t bind to sender/receiver). I’m almost convinced that Enc_structure with context “Enc_Recipient” should never be used and that we should always use COSE_KDF_Context because it provides a lot more. OR THIS — Get rid of COSE_KDF_Context. Replace it with a bunch of protected header parameters to hold the similar values. Use Enc_structure with context “Enc_Recipient” and feed that into the info parameter of HKDF and SealBase. That would be much cleaner and in line with the rest of COSE. Implementations could just reuse parameter encoding/decoding code. Probably too incompatible with published RFCs for this change though. Basically, some of the key agreement methods have an “info” parameter that can protect additional data (HKDF and Seal) and some don’t (keywrap and direct) (some new-fangled key wrap could have this though). COSE_KDF_Context is too-specifically associated with HKDF when it probably should be general and/or turned into COSE header parameters (I believe COSE_KDF_Context is cloned from previous CMS-related work). LL _______________________________________________ COSE mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
