Re: [jose] HPKE Compact JWE Demo

[Ilari Liusvaara <[e-mail]>]

On Sun, Feb 11, 2024 at 12:13:22PM -0600, Orie Steele wrote:
> 
> On Sun, Feb 11, 2024, 10:17 AM Ilari Liusvaara <[e-mail]>
> wrote:
> 
> > On Sun, Feb 11, 2024 at 06:48:36AM -0600, Orie Steele wrote:
> 
> 
> > That says that the encryption algorithm may be specified in unprotected
> > recipient headers, as long as it is the same for every recipient.
> >
> > If you don't think that is great, I agree.
> >
> 
> In Key Agreement with Key Wrapping:
> 
> All recipients need to support the same content encryption algorithm, so
> they all need to support the same JWE Protected Header.
> 
> Regarding unprotected headers:
> 
> I'm not here to change that behavior, but if we were to do the RFC over I
> would probably say something similar, but with more precision regarding
> tampering with unprotected data.

Right, except the main problem is not unprotected data but incorrect
scope. Maybe the BCP doc could say don't do that? Be conservative what
you send and all.


> > > - Requirement to put "alg" in per-recipient unprotected header for Key
> > > >   Encryption.
> > > >
> > >
> > > It's optional or it's mandatory, which do you think is correct?
> >
> > "alg" is mandatory for every recipient. From JWE decryption procedure:
> >
> > ------------------------------------------------------------------------
> > 6. Determine the Key Management Mode employed by the algorithm
> >    specified by the "alg" (algorithm) Header Parameter.
> > ------------------------------------------------------------------------
> >
> > Which is one of the per-recipient steps, and the following steps make
> > absolutely no sense without knowing KMM.
> >
> 
> With HPKE using Key Encryption, those steps are the same, and the algorithm
> is present in the recipient header.

If all recipients have the same alg, it can also be in global headers
(protected or unprotected).


> With HPKE using Integrated Encryption, the algorithm is in the protected
> header, and there is a single recipient, however, the rest of the steps
> regarding aad, and IV and tag do not apply.

There should be explicit encryption and decryption procedures for the
Integrated Encryption mode. Because the procedures in sections 5.1. and
5.2. no longer make sense.

And there are number of steps in encryption procedure that are still
sensible. E.g., 9 through 14, 16 through 19.

And decryption procedure also has some sensible steps. E.g., 1 through 3,
14, 15, 17 and 18.

And the steps regiarding aad, IV and tag do apply. IV and tag are just
empty (section 7.2.1. explicitly considers these cases).


> > > > And then arguably also requirement to use compact serialization for
> > > > Integrated Encryption.
> > > >
> > >
> > > Integrated encryption is a new mode, as is key encryption ,if you mean
> > that
> > > neither is in JWE that is true.
> >
> > JWE has all serializations be interconvertable, without access to keys,
> > as long as JWE does not require something that target serialization can
> > not represent.
> >
> > This impiles:
> >
> > - Any JWE with one recipient can be converted to flattened JSON
> >   Serialization.
> > - Any JWE can be converted to general JSON serialization.
> >
> >
> > This is kind of thing that can have profound impact on how an
> > implementation is internally structured, and breaking it could have
> > very disruptive consequences.
> >
> 
> Agreed.
> 
> The primary challenge here seems to be the missing IV, tag, and aad values,
> when switching serialization between compact and json.
>
> In integrated encryption, you won't have those values. 

JWE already specifies what to do (omit empty ones).


> If you need those values you MUST use JSON Serialization... You have always
> needed JSON for JWE aad.
> 
> You have not previously been able to omit tag and IV, when doing key
> agreement with key wrapping.

It is not specific to KAwKW. There just has not been any bulk encryption
algorithm that does not use IV nor tag. If there was such thing, it
would have the same behavior.


> > One could imagine JOSE equivalent would be roughly:
> >
> > impl MultiRecipientEncrypt
> > {
> >         pub fn get_key(&self) -> &[u8] { &self.key }
> >         pub fn add_recipient(&mut self, recipient_hdr: &BTreeMap<String,
> > JSON>, ek: &[u8]) { /* ... */ }
> >         /* ... */
> > }
> >
> > I.e. method to export the CEK and method to add arbitrary recipient.
> >
> > Such API supports all current Key Wrap, Key Agreement with Key Wrap and
> > Key Encryption algorithms. And it would compose nicely with another API
> > that had methods for the various Key Wrap, Key Agreement with Key Wrap
> > and Key Encryption algorithms.
> >
> > But this will fail for HPKE algorithms.
> >
> 
> Why?
> 
> Seems like it should be possible to build an API, that given at least 1
> private key for a recipient, can decrypt the CEK and, add a new recipient
> with an encrypted content encryption key.

This API is for creating a new message encrypted to multiple recipients.

And the reason this API does not work is that protected headers are not
available. There might be further calls to modify protected headers, or
those might not be specified until the last method call.

And looking at JWE section 5.1., recipients come first, then the bulk
stuff.

 
> > > I don't have good references to look at for COSE encrypt, so it would be
> > > harder to make progress on it in the same way, but I do think it's work
> > > adding COSE key support for encapsulated keys.
> >
> > COSE-HPKE is almost ready. However, it is easier problem because:
> >
> > - Unprotected headers are always available.
> > - There is no specified encryption mechanism.
> > - Aad is clearly per-layer.
> > - There is only one mode.
> 
> 
> Disagree that COSE encryption is easier in the general case.

It is certainly far more elegant.


> In the context of HPKE I disagree that COSE HPKE should look substantially
> different that COSE ECDH-ES.

The initial throughly overcomplicated versions were actually like that.
It was quickly changed to be its own special type of thing (with it being
a bulk AEAD, this does not cause issues in COSE).


> I've shown that it's possible for ECDH-ES and HPKE to work in JOSE
> together, and too function nearly exactly the same way.

The reason those work together is that from JWE standpoint, HPKE is Key
Encryption, and JWE specifies how KE, KW and KAwKW work together.


> > > And we will still need to put protected headers in aads.
> >
> > Those are cleanly separated in COSE. Complete with crossmode attack
> > protection.
> >
> > (Sadly no CBC/CTR oracle attack protection.)
> >
> 
> I need to start with a multiple recipient ECDH-ES COSE implementation and
> convince myself of this.

The crossmode attack protection is from the Enc_structure.context field.

But there is no requirement for using AE or AEAD on top level, so it is
vulnerable to the attack in that LAMPS slidedeck/RFC. Hell, the
algorithms used in that attack are even registered!

 
> Key Encryption is already defined by JWE (RFC 7516).
> >
> 
> And is our use of the term consistent?

Yes. Except I think there are some instances of KAwKW should be KE.


> > > > And some changes to JWE are required in order to add the Integrated
> > > > Encryption mode, I.e., this draft needs to update RFC 7516, but those
> > > > changes must not preclude non-HPKE mechnisms later.
> > > >
> > >
> > > I am not sure what you mean, this draft invented the term integrated
> > > encryption, are you saying we should leave it open for others to use it
> > > differently?
> >
> > Not differently, but in the same way, but with new algorithms.
> >
> 
> I still don't follow, I think you are saying other drafts might use "Key
> Encryption" and "Integrated Encryption" like we did in JOSE-HPKE, I don't
> think our document prevents this.

This is just matter of document layout, and not what ultimately ends up
happening.


> > The draft does not register header parameter for that, but a key type.
> >
> 
> That's correct, because there exists a header parameter that carries keys
> called epk.

However, encapsulated keys are not themselves keys.

And what the heck should implementation do with JWK of such type? Key
types are primarily for JWK, it is just that those get reused for
ECDH-ES (which does indeed have ephemeral keys).


> > And then e.g., register OKP "crv" for X-wing. Or id-MLKEM768-ECDH-P256
> > (a ML-KEM/P256 hybrid).
> >
> > And none of this would be change to JWE anyway, because it is just
> > algorithms and keys.
> >
> 
> Agreed, although having multiple ways to do the same thing, seems less good
> than having one way to do it... I suppose this will need to be said every
> time someone wants to do what HPKE does, without using it.
> 
> As an aside, I am concerned about how this kind of behavior will interact
> with hybrids, but as you said, it is not something that can be stopped in
> the JOSE HPKE draft, and perhaps is is desirable to not use HPKE for some
> use cases.

Heck, what does JOSE HPKE initally even add? Scanning the algorithm
list, I only see stronger KDFs. I don't think JWE is currently
bottlenecked on KDF.

To get anything actually new, one would need something like ciphersuite
involving HPKE KEM 48 (X25519Kyber768Draft00). That one is PQC, where
no current JWE alg is.


And then I noticed HPKE-Base-P256-SHA256-AES128GCMKW... labeled as
Key Agreement with Key Wrap algorithm. Is the whole section just
mislabeled (along with previous section), or how the heck does that
even work?


And then I noticed that all ciphersuites have base mode, but there are
"psk_id" and "auth_kid" parameters, that only make sense for non-base
modes. Do those headers implicitly modify mode, or are there just no
ciphersuites available?

(There is an attack if auth/auth_psk modes are used for key encryption).


> > > > I don't think there are any. There is only one output field besides
> > > > headers for Key Encryption, and Integrated Encryption can not use
> > > > headers in compact without requiring multi-shot.
> > > >
> > >
> > > I think you are saying you prefer to have single shot and multi shot
> > > supported, over having JWE Protected headers be consistent.
> > >
> > > This is a good point.
> >
> > Single-shot can be supported with both modes consistent. But there is
> > only one way to do that (output concatenation).
> >
> 
> I think you are correct here.
> 
> The reason you are correct is that unprotected headers are not supported in
> compact, and protected headers are required input to AAD.

Well, there are also encrypted key and iv fields, but recipients either
do not have those, or are required for other purposes.




-Ilari