Re: [COSE] [jose] HPKE PartyU / PartyV

[Ilari Liusvaara <[e-mail]>]

On Sun, Mar 24, 2024 at 05:49:37PM -0500, Orie Steele wrote:
> Essentially, every case where we use COSE KDF context to derive a key that
> does not commit to the content encryption algorithm, we would need to use a
> new context that did commit to the content encryption algorithm, and we
> would want to deprecate all the algorithms that were vulnerable to the
> cross mode attack at the same time.

Unfortunately, that would mean deprecating some algorithms with no
replacement (mainly Key Transport and Key Wrap class).


Doing what CMS did would work as well.

Basically, add new header parameter (I call it "pcm" for Per-Cipher
Material):

- Specifies a KDF to apply.
- Derives the key to use for symmetric algorithm from input key.
- If base iv is required, also derives that.
- There is no explicit key length, so recipient algorithm MUST NOT
  be Direct Key Agreement or Direct Key with KDF.
- The KDF context looks something like:

  * context: tstr
  * depth: uint/null (null for COSE_Encrypt0)
  * alg: int/tstr (from headers)
  * salt: bstr (from headers)
  * keyflag: bool (true for keys, false for iv)
  * length: uint (number of bytes of key material).


This would also be useful for using Direct Key for bulk encryption.
Currently, there is no great way to do that in COSE (all AEAD algorithms
are unsafe, AES-KW is very slow, and dir+KDF is another layer).


> We might as well fully specify the new entries at that rate as well.
> 
> ECDH-ES+A128KW+A128GCM
> ECDH-ES+HKDF-256+A128GCM
> 
> Or fully specified:
> 
> ECDH-ES-P384+A128KW+A128GCM
> ECDH-ES-P384+HKDF-256+A128GCM
> 
> That's a lot of work, and certainly belongs in a separate draft, which I
> would be happy to review, but probably don't have time to author at this
> point.

A fundamental assumption in COSE is that algorithms can be mixed and
matched in any way that has sensible keyflow.

This would break that assumption, making this extremely bad idea.




-Ilari