Hi Ilari, I built a table of all the types of COSE Recipients IANA registered and attached it below to be sure everything is discussed. You can divide it into two groups:
1) Uses KDF & CIS - Headers protected - Immunity from AEAD downgrade except ECDH-with-key-wrap (alg ids -29…-34) which “missed it by that much" 2) Doesn’t use KDF & CIS - NO header protection at all I don’t think it makes sense to use draft-tschofenig-cose-cek-hkdf-sha256 to add a second KDF layer to group 1. That results in unnecessary double KDF. I’d rather define a new alg ID that fixes ECDH-with-key-wrap, the only one that needs fixing. But what about group 2? The design intent was clearly NOT to protect any headers and we were OK with that at the time. I think maybe the AEAD downgrade attack changes this, but we should have some discussion. If we did fix these with a KDF, an alternate to draft-tschofenig-cose-cek-hkdf-sha256 would be to extend RFC 9052 8.5 with two new classes, “key wrap with KDF” and “key transport with KDF”. That would of course result in new COSE_Recipient alg IDs. That seems more in the spirit of COSE to me. Note that “Direct Key" is already fixed that way with “Direct Key with KDF”. Creating new algorithm IDs that fully specify everything in COSE_Recipient processing seems more in line with preferences for fully specified these days than a boolean header to indicate a bolt-on KDF or not. LL > On Aug 4, 2024, at 4:27 AM, Ilari Liusvaara <[email protected]> wrote: > > On Sat, Aug 03, 2024 at 04:43:13PM +0000, lgl island-resort.com wrote: >> 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. > > What about all the Key Wrap and Key Transport algorithms? > > - The first can be AE, which does not allow binding the algorithm. > - The second has no way of binding the algorithm by definition. > > >> 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>. > > What about those cases where the Key Agreement with Key Wrap uses unsafe > key wrap? One really does not want to assign a codepoint for a security > problem. I guess one could specify that the algorithm is the combined > algorithm (at least that would be explicit). > > >> I think this would be better than draft-tschofenig-cose-cek-hkdf-sha256 >> because it is just a small adjustment. > > There are cases where one actually needs something like that draft. > > >> 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? > > There is also Key Transport (-40, -41 and -42). I don't see a way to add > a context to that. > > > > > -Ilari > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected]
COSE_Recipient_Types.pdf
Description: COSE_Recipient_Types.pdf
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
