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]
