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

[Orie Steele <[e-mail]>]

On Tue, Jul 9, 2024 at 10:58 AM Ilari Liusvaara <[e-mail]>
wrote:

> 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.
>

Which part would you change?


>
> > 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).
>

What would you set HPKE AAD to be for Key Encryption?
What would you set HPKE AAD to be for Integrated Encryption?


>
> > 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).
>

Drafts can only be cited as work in progress... it's also in conflict with
RFC7518:

See also: https://datatracker.ietf.org/doc/html/rfc7518#section-4.6.2

      For "ECDH-ES", this is the length of the key used by the "enc"
algorithm.
      For "ECDH-ES+A128KW", "ECDH-ES+A192KW", and "ECDH-ES+A256KW", this
      is 128, 192, and 256, respectively.

So as you can see... "alg" and "enc" are already dependent, as specified in
RFC7518.

We could write:

For "HPKE-P256-SHA256-A128GCM", the length of the content encryption key is
the length of a key used by the "enc" algorithm, note that
"HPKE-P256-SHA256-A128GCM" can be used to encrypt an A256GCM key.

... or someone can propose alternative text that explains how HPKE "alg"
and "enc" values are related.


>
>
>
> -Ilari
>
> _______________________________________________
> jose mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>