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

[Orie Steele <[e-mail]>]

Inline:

On Mon, Jul 8, 2024 at 6:38 PM Les Hazlewood <[e-mail]> wrote:

> Thinking though this a whole lot more I think I was confused on which
> alg/enc parameters were used in which header elements.  To avoid that
> confusion for myself, I'll refer to them using their RFC 7516 names:
>
> Currently with JWE, `enc` algorithms/IDs are all AEAD algorithms, and I
> think this must remain the same. Consistency, no surprises, everything
> stays the same, lowest possible impact to all existing JOSE
> implementations. And actually, having this value be anything other than an
> AEAD algorithm would violate RFC 7516, Section 4.1.2
> <https://datatracker.ietf.org/doc/html/rfc7516#section-4.1.2> as written:
>  "This algorithm MUST be an AEAD algorithm with a specified key length."
>  Many implementations (mine included) make plenty of assertions that this
> must be an AEAD algorithm that requires secret keys, etc.  Changing this to
> be a different type of algorithm would cause a lot of problems on
> implementations, especially those written in typesafe languages.
>
> In the multi-recipient case, I agree, there doesn't need to be an `enc`
> value in the JWE Per-Recipient Unprotected Header because it's always
> implied by the JWE Protected Header.  This must be the same for all
> recipients anyway.  Nor is an JWE Protected Header `alg` value required
> since that will likely be different per recipient.  The union (JWE JOSE
> Header) for a single recipient and/or JWT must have both header parameters
> however.
>
> For HPKE then, it seems that the `alg` value only needs to include the
> first 2 HPKE cipher suite IDs/tokens and exclude the trailing AEAD id as
> Michael Jones said.  But then Ilari said:
>
> "- The first means to use algorithm "HPKE-P256-SHA256" (presumably Direct
>   Key Agreement) to derive key for "A128GCM" (which is defined by
>   RFC7518) bulk encryption."
>
> I'm probably missing something, but I don't believe this is an issue.
> HPKE does not use nor accept direct shared symmetric key IKM (input key
> material).  That is, HPKE is only to be used for public key derivation of a
> shared secret (KEM) which is then tied to context and made
> cryptographically uniform (HKDF), and that output key is used as the AEAD
> symmetric key.
>
> That means if you have an `enc` value, you only need the HPKE ID trailing
> tokens to be a tuple because you already have the 3rd in the `enc` header
> parameter. That is:
>
> header['alg'] + header['enc'] would always
> equal "HPKE-<KEMID>-<HKDFID>-<AEADID>"
>

Yes. Similar to https://datatracker.ietf.org/doc/html/rfc7520#section-5.5.4
 and https://datatracker.ietf.org/doc/html/rfc7518#appendix-C

"alg" + "enc" = "ECDH-ES" + (missing curve name) (concat kdf) + "A128GCM"
"alg" + "enc" = "ECDH-ES" + (missing curve name) (concat kdf) +
"A128CBC-HS256"


> That is unless you're trying to use HPKE as a key encryption/wrapping
> algorithm, which brings me to my next question:
>
> Why is JWE HPKE Key Encryption necessary at all?  Since HPKE requires
> asymmetric keys to be used, what is the use case for encrypting a
> direct/shared symmetric key when the recipient must decrypt with their
> private key anyway?
>

Support for HPKE alongside other recipient encryption schemes, for example:
https://datatracker.ietf.org/doc/html/rfc7520#section-5.13

Or in other words... the ability to use HPKE to wrap keys with post quantum
or hybrid kems, so that traditional recipients which might be subject to
harvest now and decrypt later attacks on elliptic curve discrete log can
have something to migrate to, without changing out the symmetric encryption
layer (we're less worried about Grover, and more worried about Shor).

It's not that meaningful to move from ECDH-ES+A128KW to
HPKE-P256-SHA256+A128KW ... but it would be more significant to move to
HPKE-ML-KEM-1024-SHA256+A256KW

In order to know how to use an HPKE PQ KEM with multiple recipient JWE, we
need to describe how to do HPKE JWE Key Encryption.

We're also trying to avoid registering lots of algorithms.

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

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

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

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.

Hopefully this extra background is helpful.

Thank you for your comments!


> Thanks,
>
> Les
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>