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

["lgl island-resort.com" <[e-mail]>]

This<https://github.com/cose-wg/HPKE/pull/58> is my attempt at the outcome of the discussion between Ori, Illari and myself on the list.

I went back to “next_alg" so it can be used with multiple layers of COSE_Recipient, but specify that it is always for the next COSE layer down. It is expected that when a COSE_Recipient employs multiple algorithms like HPKE and -29 do that they lock down all the algorithms they use internally, so it makes sense that this is for the next COSE layer. It was unclear what the alg ID in COSE_KDF_Context was for.

I haven't implemented this, but I'm pretty confident about doing so. I also haven't updated the examples.

I believe it will be possible to re-use Recipient_structure for the -29 replacement.

LL


On Mar 25, 2024, at 2:42 AM, Ilari Liusvaara <[e-mail]> wrote:

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

_______________________________________________
COSE mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/cose