On Sat, Aug 03, 2024 at 04:43:13PM +0000, lgl island-resort.com wrote: > TLDR: CIS correctly protects the content encryption alg ID except for > ECDH-with-key-wrap (alg ids -29…-34). > > TLDR: Changing the meaning of CIS AlgorithmID for ECDH-with-key-wrap > is a low impact solution to the AEAD downgrade attack.
What about all the Key Wrap and Key Transport algorithms? - The first can be AE, which does not allow binding the algorithm. - The second has no way of binding the algorithm by definition. > RFC 9053 section 5.2<https://www.rfc-editor.org/rfc/rfc9180.html#section-5.2> > says how to use the CIS AlgorithmID. The AlgorithmID definition is not > that clear, but the best interpretation of it for ECDH-with-key-wrap > (-29…-34) is that it identifies the key wrap algorithm, not the > content encryption algorithm. That is also what Jim’s code > <https://github.com/cose-wg/COSE-C> does and what is in the > COSE-Examples repository<https://github.com/cose-wg/Examples>. What about those cases where the Key Agreement with Key Wrap uses unsafe key wrap? One really does not want to assign a codepoint for a security problem. I guess one could specify that the algorithm is the combined algorithm (at least that would be explicit). > I think this would be better than draft-tschofenig-cose-cek-hkdf-sha256 > because it is just a small adjustment. There are cases where one actually needs something like that draft. > Going on to complete the discussion of AEAD downgrade for all key > distribution options in section > 6<https://www.rfc-editor.org/rfc/rfc9053.html#section-6>, > Direct_key (-6) and AES_key_wrap (-3… -5) are both vulnerable. Neither > use HKDF and thus don’t use CIS AlgorithmID. Should they be remedied > by draft-tschofenig-cose-cek-hkdf-sha256? There is also Key Transport (-40, -41 and -42). I don't see a way to add a context to that. -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
