This<https://github.com/cose-wg/HPKE/pull/58> is my attempt at the outcome of the discussion between Ori, Illari and myself on the list.
I went back to “next_alg" so it can be used with multiple layers of COSE_Recipient, but specify that it is always for the next COSE layer down. It is expected that when a COSE_Recipient employs multiple algorithms like HPKE and -29 do that they lock down all the algorithms they use internally, so it makes sense that this is for the next COSE layer. It was unclear what the alg ID in COSE_KDF_Context was for. I haven't implemented this, but I'm pretty confident about doing so. I also haven't updated the examples. I believe it will be possible to re-use Recipient_structure for the -29 replacement. LL On Mar 25, 2024, at 2:42 AM, Ilari Liusvaara <[email protected]> wrote: On Sun, Mar 24, 2024 at 05:49:37PM -0500, Orie Steele wrote: Essentially, every case where we use COSE KDF context to derive a key that does not commit to the content encryption algorithm, we would need to use a new context that did commit to the content encryption algorithm, and we would want to deprecate all the algorithms that were vulnerable to the cross mode attack at the same time. Unfortunately, that would mean deprecating some algorithms with no replacement (mainly Key Transport and Key Wrap class). Doing what CMS did would work as well. Basically, add new header parameter (I call it "pcm" for Per-Cipher Material): - Specifies a KDF to apply. - Derives the key to use for symmetric algorithm from input key. - If base iv is required, also derives that. - There is no explicit key length, so recipient algorithm MUST NOT be Direct Key Agreement or Direct Key with KDF. - The KDF context looks something like: * context: tstr * depth: uint/null (null for COSE_Encrypt0) * alg: int/tstr (from headers) * salt: bstr (from headers) * keyflag: bool (true for keys, false for iv) * length: uint (number of bytes of key material). This would also be useful for using Direct Key for bulk encryption. Currently, there is no great way to do that in COSE (all AEAD algorithms are unsafe, AES-KW is very slow, and dir+KDF is another layer). We might as well fully specify the new entries at that rate as well. ECDH-ES+A128KW+A128GCM ECDH-ES+HKDF-256+A128GCM Or fully specified: ECDH-ES-P384+A128KW+A128GCM ECDH-ES-P384+HKDF-256+A128GCM That's a lot of work, and certainly belongs in a separate draft, which I would be happy to review, but probably don't have time to author at this point. A fundamental assumption in COSE is that algorithms can be mixed and matched in any way that has sensible keyflow. This would break that assumption, making this extremely bad idea. -Ilari _______________________________________________ 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
