COSE_KDF_Context is mandatory depending on protected headers

[OR13]

It needs to be computed consistently by both sender and receiver.
If related protected header parameters are present, it must be computed and used.

If no relevant protected header parameters are present, it SHOULD NOT be used.

[dajiaji]

Previously, I posted the following message to the COSE mailing list:

https://mailarchive.ietf.org/arch/msg/cose/XjOlXbTvMRqxhdXhovv5K3fYNnw/

In my understanding, it was a mistake in the first place for RFC9053 to define the COSE_KDF_Context structure. There was no need to use the PartyU and PartyV structures in the "Extract-and-Expand" key derivation function.

I believe that in COSE-HPKE, the use of COSE_KDF_Context should be explicitly prohibited to eliminate redundant context binding processes.

I think it will be easier to discuss based on a specific proposal, so I will create a pull request to update the descriptions related to COSE_KDF_Context. I would be happy if you could review it.

[laurencelundblade]

I think Enc_structure with context "COSE_Recipient" can be an alternative to mandatory use of COSE_KDF_Context. One of the two MUST be mandatory so that the protected headers in the COSE_Recipient are protected.

I don't agree with
https://mailarchive.ietf.org/arch/msg/cose/XjOlXbTvMRqxhdXhovv5K3fYNnw/

COSE_KDF_Context clearly provides protection against the lamps attack for COSE_Recipient with algorithm -25.

[OR13]

Yes, for -25, the AEAD Algorithm ID is mixed into the kdf via COSE_KDF_Context.

For -29, the key wrapping algorithm (A128KW) is mixed into the kdf via COSE_KDF_Context.

The key wrapping algorithm wraps a key that can be used for A128GCM or A128CBC... thats the problem

[selfissued]

I would prohibit the use of non AEAD Algorithms such as CBC.

…

________________________________ From: Orie Steele ***@***.***> Sent: Sunday, March 3, 2024 6:49:16 AM To: cose-wg/HPKE ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [cose-wg/HPKE] COSE_KDF_Context is mandatory depending on protected headers (Issue #53) Yes, for -25, the AEAD Algorithm ID is mixed into the kdf via COSE_KDF_Context. For -29, the key wrapping algorithm (A128KW) is mixed into the kdf via COSE_KDF_Context. The key wrapping algorithm wraps a key that can be used for A128GCM or A128CBC... thats the problem — Reply to this email directly, view it on GitHub<#53 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB2KJ7WMR7PT2U5W3R3SNH3YWMZ6ZAVCNFSM6AAAAABDXO3FT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZVGE4DMNZQGQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[laurencelundblade]

I think binding of the level 0 algorithm ID in with the COSE_Recipient is more than just defending against the lamps attack. It is current security practice:

• HPKE internally does it. HPKE thoroughly binds all algorithm IDs
• COSE_KDF_Context does it
• It anticipated and defeated the lamps attack and may anticipate and defeat others we don’t know of yet.

Binding the alg ID is a more universal and sound practice than excluding non-AEAD modes.

COSE-HPKE should come out of the gate secure, complete and without implementors having to make complicated security decisions like those to do with COSE_KDF_Context. It should address the lamps attack and use current security practice.

There are also use cases for non AEAD algorithms.