Focusing on ECDH-ES + A128KW, algorithm ID -29, section 6.4.1 of RFC 8949.
Any fix to -29 for non-AEAD algorithms will NOT be compatible with existing
implementations. Adding the layer defined in
draft-tschofenig-cose-cek-hkdf-sha256 will require a large change to any
implementation of -29.
So what we should do instead is define ECDH-ES + A128KWbis, with a new
algorithm ID like -129, that authenticates the algorithm ID properly. The
solution would look a lot like what we did for COSE-HPKE.
I would also like to replace Context Information Structure like we did for
COSE-HPKE.
If you compare complexity:
-29 — medium complex and object code
-29 + draft-tschofenig-cose-cek-hkdf-sha256 — most complex and object code
-129 — least complex and object code
The complexity of -129 is less because we can get rid of all the mostly unused
fields in Context Information Structure.
-129 will also be easier for people to understand because we’ll replace Context
Information Structure with something more sensible and easier to figure out.
LL
> On Sep 8, 2025, at 1:40 AM, Tschofenig, Hannes <[email protected]>
> wrote:
>
> Hi all,
> you might recall that there was an attack against CMS where an attacker
> manipulates the content-encryption algorithm identifier and performs an
> AEAD-to-CBC downgrade attack. Russ worked on the mitigation for CMS and it
> can be found in RFC 9709.
> Russ, Ken and I presented a generic mitigation to this attack applicable to
> COSE. It is based on RFC 9709.
> Here is the draft:
> https://www.ietf.org/archive/id/draft-tschofenig-cose-cek-hkdf-sha256-02.txt
> The draft has not been adopted in COSE until now. One would think that the
> group should be interested to fix it. The minutes from the COSE meeting are
> at the end of this email.
> The problem only appears if there is a non-AEAD algorithm being used with
> COSE. This happens only in selected use cases - the primary use case is
> firmware encryption. In the SUIT firmware encryption draft we have utilized
> the ephemeral-static DH algorithm as a key exchange mechanism and, without a
> protection, it is vulnerable to this type of AEAD-to-CBC downgrade attack.
> Hence, we must do something about it.
> For the work on COSE-HPKE we took actions to fix the situation. The COSE-HPKE
> draft took a while, but I believe we go closer to completion with the
> discussions and decisions from last IETF meeting. The authors of COSE-HPKE
> have been busy updating the draft and writing code. The latest draft snapshot
> is in the WG Github repo, see https://github.com/cose-wg/HPKE
> The solution we came up for COSE-HPKE is different compared to the solution
> described in draft-tschofenig-cose-cek-hkdf-sha256-02.txt. The reason is that
> the integration of HPKE is new to COSE and there has been no existing code to
> consider. For ephemeral-static DH the situation is different since the
> functionality has been in the COSE specification since the beginning.
> So, here are the questions I have:
> Should we (the authors of draft-tschofenig-cose-cek-hkdf-sha256) take the
> content of draft-tschofenig-cose-cek-hkdf-sha256-02.txt and put it in
> datatracker.ietf.org/doc/draft-ietf-suit-firmware-encryption/
> <http://datatracker.ietf.org/doc/draft-ietf-suit-firmware-encryption/> and
> thereby fix the vulnerability for the firmware encryption use case with
> ephemeral-static DH?
> Alternatively, should we continue pursue the publication of
> draft-tschofenig-cose-cek-hkdf-sha256 in the COSE group?
> Please let us know what approach you prefer.
> Ciao
> Hannes
> -----
>
> Here are the notes from the 121 IETF meeting:
> https://datatracker.ietf.org/meeting/121/agenda
>
> [14:10-14:20] draft-tschofenig-cose-cek-hkdf-sha256 - Hannes Tschofenig
>
> Presentation slides
>
> Response to a plaintext recovery attack. This was enabled by
> manipulating individual but related fields in the COSE encoding of a key
> exchange conversation.
>
> Appeal for volunteers to read the draft before we can call for adoption.
>
> 3 volunteers:
>
> Renzo Navas
> Gaetan Feige
> Peter Liu
>
> Brian made observations about the care that needs to be taken in making
> a broad sweeping change to all COSE rather than hardening each
> individual algorithm.
>
> Cedric Fournet asks if including the encryption algorithm is sufficient.
> Hannes opines that there's a lot of historic confusion around key
> exchange and how they've been specified all over the IETF. Maybe we
> should sweep all of those and tidy up before focusing on the details of
> specific documents.
>
> Laurence Lundblade speaks against wedging another key exchange layer in
> saying there are better alternatives. Hannes responds that the
> cryptographers who discovered the attack endorse this solution. Laurence
> agrees that the proposal does solve the problem, but is wasteful, and
> suggested an alternative (which I, the note-taker, missed). Hannes
> responds that the suggested alternative doesn't work. Robust discussion
> ensued around interoperability and document management concerns.
>
> Mike Jones pointed out that this is only relevant if you want to allow
> non-AEAD algorithms (because otherwise the attack doesn't apply) so
> solutions can take that narrower scope into account.
> _______________________________________________
> COSE mailing list -- [email protected] <mailto:[email protected]>
> To unsubscribe send an email to [email protected]
> <mailto:[email protected]>
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
