1) Most of 9053 is OK. It’s only ECDH-with-key-wrap (alg ids -29…-34) that’s a problem.
2) You are right, that implementations can solve this by rejecting non-AEAD. I’ve submitted errata for 9053 to say this. Is there a better way to inform in a timely way? 3) I’m also hoping for a lot of clarification to 9053 around CIS so that mere mortals can securely and successfully implement. 4) Not directly related to this message — we still have to decide on a data structure for COSE-HPKE. LL On Aug 3, 2024, at 10:03 AM, Michael Jones <[email protected]> wrote: Chair hat off, none of these mitigations are needed if authenticated encryption algorithms are used. The simplest mitigation isn’t a data structure change but prohibiting the use of unauthenticated encryption in contexts where it’s not needed. Normal COSE implementations not wanting to use unauthenticated encryption can simply verify that the content encryption algorithm is authenticated, and we’re done. -- Mike From: lgl island-resort.com <[email protected]> Sent: Saturday, August 3, 2024 9:43 AM To: cose <[email protected]> Subject: [COSE] AlgorithmID in RFC 9053 Context Information Structure 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. Been spending some time with Context Information Structure (CIS), particularly AlgorithmID. Most of the content key distribution methods in RFC 9053 section 6<https://www.rfc-editor.org/rfc/rfc9053.html#section-6> use HKDF with the CIS as input. AlgorithmID is part of CIS and says what algorithm the output of HKDF is to be used with. In all but ECDH-with-key-wrap (-29…-34) that algorithm is the content encryption algorithm. So: Direct_Key_with_KDF (-10… -13) —> NOT vulnerable to AEAD downgrade Direct_ECDH (-25… -28) —> NOT vulnerable to AEAD downgrade These are already doing the equivalent of draft-tschofenig-cose-cek-hkdf-sha256. 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>. If it had specified the content encryption algorithm for all uses, there would be no AEAD downgrade attack. It would be already doing the equivalent of draft-tschofenig-cose-cek-hkdf-sha256. (Maxwell Smart: “missed it by that much”<https://www.youtube.com/watch?v=g2vZonSDUgk>) We can’t change the meaning of CIS AlgorithmID for ECDH-with-key-wrap (-29…-34) because it is a published standards track document, but we can define new key distribution algorithm IDs where the CIS AlgorithmID always identifies the content encryption algorithm. This would be an AEAD downgrade remedy with a small amount of change to RFC text and code. Note that there is no need to protect the key wrap algorithm ID with CIS because it is securely identified in ECDH-with-key-wrap identifiers. I think this would be better than draft-tschofenig-cose-cek-hkdf-sha256 because it is just a small adjustment. 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? Adding HKDF to Direct_key (-6) just turns it into Direct_Key_with_KDF (-10… -13). No need to replicate that. Also a pure symmetric-key-only option is necessary for use cases that do key distribution outside of COSE. So, nothing to be done with -6, IMO. My thought for AES_key_wrap (-3… -5) is to leave it alone even though it is vulnerable. If we did fix it, I’d like to do so by defining a new alg ID for it. That is, create AES_key_wrap_with_KDF. I am not advocating a particular AEAD downgrade solution yet, because I want to do more thinking about the rest of CIS. LL
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
