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:
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 [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]
