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

[Ilari Liusvaara <[e-mail]>]

On Tue, Jul 09, 2024 at 02:02:01PM -0700, Les Hazlewood wrote:
> I agree, `alg` and `enc` (when present) have always been related: other
> than "alg": "dir", `alg` must always produce a key compatible with `enc`,
> and therefore it must 'know about' things relevant to `enc.  It doesn't
> make any sense to me to claim `alg` must be independent of `enc`.

Since "enc" is required to be symmetric AEAD, the only compatibility
requirement is key being of correct length.

As consequence, currently the only ways in JWE where value of "enc"
affects what "alg" does in any way are (both related to Direct Key
Agreement):

1) For DKA, the AlgorithmID in KDF context is "enc" value.
2) For DKA, the KDF output length is "enc" key length.


> This feels a whole lot like trying to force-fit existing 10-year
> well-defined headers to support entirely new concepts that were never
> intended to be used in such headers (`alg` has never required anything
> about *content* encryption, only key encryption); see my preceding response
> in this thread.

That is pretty much what is going on.

JWE was always intended to perform bulk encryption itself, it was never
intended to delegate that task to anything else.


> Anyway, conceptually at the highest level HPKE is a 3 phase process: (key
> encapsulation) --> (key derivation) --> (content encryption), so the `alg`
> value should contain all the (key encapsulation) -> (key derivation) parts
> first because that's the 'key management' stuff.

Separating key managment and bulk encryption in HPKE requires using the
Secret Export interface.

It is possible to use HPKE Secret Export as Direct Key Agreeement in
JWE.


> But for JOSE, the first two phases aren't just KEM-->KDF.  It's KEM-->KDF
> optionally followed by a key encryption/wrap algorithm. In other words, the
> JOSE CEK is still derived - it's just derived using both the RFC 9180
> KEM->KDF phase, potentially followed by a key encryption/wrap phase.  It's
> all still "key derivation", but just a potential extra step beyond what RFC
> 9180 defines.

That is not correct:

- JOSE requires key encryption to be the first step.
- HPKE does not allow adding any extra steps beyond RFC9180.

One can construct JWE Key Encryption by just calling the single-shot
HPKE encrypt/decrypt interfaces to encrypt/decrypt the CEK.

 
> This implies the only way to really represent a polymorphic KDF identifier
> for JOSE would be either:
> - a standard HKDF identifier for integrated encryption e.g. "$hkdf_id"
> - a standard HKDF identifier concatenated with the `+` character followed
> by the key encryption algorithm identifier, e.g. "$hkdf_id+$kealg_id"
> 
> This is all still part of the JOSE 'key derivation' phase and identifier
> strings should be tightly associated as such (combined) before any content
> encryption identifier.

The whole point of Integrated Encryption is to erase the distinction
between 'key derivation' and 'bulk encryption'. 

 
> There doesn't seem to be a good way to avoid the explosion of registrations
> Orie is hoping to avoid.  Based on
> https://www.iana.org/assignments/hpke/hpke.xhtml and the existing JWA RFC,
> there are (currently):
> - 10 KEM algs
> - 3 KDF algs
> - 6 key encryption algs (A128KW...A256GCMKW)
> - 6 JOSE content AEAD algorithms
> 
> implying a whopping 1080 permutations!
> 
> Removing the content AEAD algorithm from the alg identifier (and keeping it
> only in `enc`) drops the permutations to 180.  Still quite large.

Even registering absolutely everything HPKE has would only be 90
permutations (10 KEMs, 3 KDFs, 3 AEADs).

Dropping combos that make little sense reduces that to 20, and dropping
"non-standard" stuff reduces that to 10.




-Ilari