On Fri, Jun 02, 2023 at 05:59:30PM +0000, lgl island-resort.com wrote: > 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. > > HPKE takes care of this internally for COSE-HPKE single recipient > mode, but not for multiple recipient mode.
AFAIK, the native ECDH mode in COSE has the same limitation: The COSE_KDF_Context binds the next algorithm. If there is only a single recipient, it is the final bulk encryption, so everything is bound. However, in case of multi-recipient, it is key wrap, leaving the final bulk encryption unbound. > 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. I see two reasons for including the info in the appendix. - The first does not look applicable, because HPKE always generates fresh keys. - The second does look applicable. However, adding it in a way that is neither trivially broken nor highly application-specific seems almost impossible. > 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. This seems highly application-specific. > 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. It does equivalent thing internally. > 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. See above for limitations on algorithm binding. And more severe problem is that for HPKE, there is no sane value to use. HPKE internally runs key derivation with multiple output lengths. > (Rhetorical question — Why is this in SuppPubInfo and not a peer to > AlgorithmID in the CBOR encoding or why is AlgorithmID not in > SuppPubInfo?) I think that was mostly copied from JOSE. > 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. Because HPKE is AEAD-capable, COSE header parameters are already protected by Enc_structure (by RFC9052). Including those into KDF context would lead to double protection, which is silly. And I think taking authentication failure with correct keys is slightly more sound than trying to use wrong keys. > 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. That seems like it would be impossible to implement because of hard cyclic dependency? -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
