Hi Hannes,
thank you for bringing this up again. If the issue is not specific to
SUIT (and only highlighted by SUIT and addressed there is a timely
manner), it seems useful to generalize any mitigation in a dedicated
COSE document. This would also allow to point to different mitigation
methods that address a similar issue in the COSE scope, such as
cose-cek-hkdf-sha256.
In summary, if I did not misunderstood you:
* a general problem is addressed in SUIT and cose-cek-hkdf-sha256
* a generic bcp is required to address it in general instead of two
specific places
Viele Grüße,
Henk
On 08.09.25 10:40, Tschofenig, Hannes 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 <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 <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:
1. 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/ and
thereby fix the vulnerability for the firmware encryption use case
with ephemeral-static DH?
2. 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
<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]
To unsubscribe send an email to [email protected]
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
