[jose] Re: draft-ietf-jose-hpke-encrypt-01

[Ilari Liusvaara <[e-mail]>]

On Mon, Jul 08, 2024 at 09:05:58PM -0500, Orie Steele wrote:
> 
> I'd love to learn the history of why ECDH-ES+A128KW is not ECDH-ES+A128GCM
> ... but this ship has sailed, "ECDH-ES+A128KW" is mixed into the concat kdf.
> ... the logical equivalent of that happens internally to HPKE, here:
> https://datatracker.ietf.org/doc/html/rfc9180#section-5.1-9

That is because AES-GCM requires a nonce and breaks badly if it is reused,
making it not great for key wrapping. Whereas AES-KW does not even need an
IV.

JOSE does have the (rather broken) A*GCMKW algorithms, which perform Key
Wrapping using AES-GCM.

The easiest way to get around the GCM nonce issue is to generate both key
and nonce together using KDF.


> The difference is that HPKE doesn't give a different algorithm name for
> A128KW and A128GCM... it treats them as both 0x0001 see
> https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-ids

HPKE never uses AES-KW. HPKE always uses AES in GCM mode. It gets around
the problem with nonce as said above.


> HPKE doesn't know if it's encrypting a content encryption key or not...
> If you want to ensure that in higher order systems this distinction is
> authenticated, you need to use setup info or aead aad, see
> https://datatracker.ietf.org/doc/html/rfc9180#name-auxiliary-authenticated-app
> 
> This leads us back to the current proposal...
> 
> - alg: HPKE-P256-SHA256-A128GCM ... enc: A128GCM // in separate headers ->
> key encryption
> - alg: HPKE-P256-SHA256-A128GCM,  enc: A128GCM   // in the same header  ->
> integrated encryption

This does not work because JWE unions recipient headers.

 
> hpke-info = empty
> hpke-aad = protected (.aad) // how the distinction is authenticated

... And this does the wrong thing with Key Encryption (and causes
implementation problems).


> An alternative proposal:
> 
> - alg: HPKE-P256-SHA256+A128KW ... enc: A128GCM // -> key encryption
> - alg: HPKE-P256-SHA256,  enc: A128GCM          // -> integrated encryption
> 
> This doubles the registrations and does not appear to do anything useful.
> ... unless these different alg values are used as hpke-info to force
> different key schedules:
> https://datatracker.ietf.org/doc/html/rfc9180#section-5.1-10
> ... similar to how ECDH-ES and ECDH-ES+A128KW work in concat kdf today.

This is also prohibited by draft-ietf-jose-fully-specified-algorithms
(It requires what alg to be independent of enc).




-Ilari