Re: [COSE] [jose] HPKE Compact JWE Demo

[Orie Steele <[e-mail]>]

Inline:

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:
> > Inline
> >
> > On Sun, Feb 11, 2024, 4:26 AM Ilari Liusvaara <[e-mail]>
> > wrote:
> >
> > > On Sat, Feb 10, 2024 at 03:15:11PM -0600, Orie Steele wrote:
> > >
> > > The draft does currently have requirements incompatible with JWE. E.g.,
> > >
> > > - Requirement to use JSON serialization for Key Encryption.
> > >
> >
> > There is an open issue, before we had JSON Serialization working with
> > backwords compatibility this was not possible, now that we have it, it's
> > just matter of moving objects into the spaces between periods right?
>
> Yes, if there is exactly one recipient and no JWE aad, because compact
> serialization requires exactly one recipient or JWE aad.
>
> Any unprotected headers must be made protected instead.
>

I agree with you up to the comment about changing headers, we can't do
that, because compact JWE has no unprotected headers.


> JWE messages always have at least one recipient. Even Direct Encryption
> ("alg":"dir") is logically a recipient.
>
>
> > - Requirement to put "enc" in protected parameters for Key Encryption.
> > >
> >
> > As is don't with Key Agreement with Key Wrapping? Not sure which enc you
> > are talking about.
>
> The Encryption Algorithm, defined in JWE section 4.1.2.
>
> Note that 4.1.2. does not say where "enc" can occur. Contrast to JWE
> section 4.1.3. ("zip" (Compression Algorithm) Header Parameter), which
> says:
>
> ------------------------------------------------------------------------
> When used, this Header Parameter MUST be integrity protected; therefore,
> it MUST occur only within the JWE Protected Header.
> ------------------------------------------------------------------------
>
> Then Section 7.2.1. (General JWE JSON Serialization Syntax) says:
>
> ------------------------------------------------------------------------
> Therefore, all Header Parameters that specify the treatment of the
> plaintext value MUST be the same for all recipients. This primarily
> means that the "enc" (encryption algorithm) Header Parameter value in
> the JOSE Header for each recipient and any parameters of that algorithm
> MUST be the same.
> ------------------------------------------------------------------------
>
> 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.



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

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.



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

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.

These are the primary differences we have now.




>
> > > As example of just what requirements like this can cause, I once wrote
> > > support for extensible priorities in HTTP/2 in a reverse proxy. IIRC, I
> > > explicitly ignored every single requirement that went against base
> > > HTTP/2. Mostly, because code I was modifying was designed for as
> > > specified by base HTTP/2.
> > >
> >
> > Yep, that's why we added support for epk to transport encapsulated
> keys...
> > To keep things as close as possible between key agreement with key
> wrapping
> > and key encryption.
>
> This was not about having two different modes work the same (there
> actually is, and those don't). It was about what can happen if base spec
> requirements are broken.
>
>
> > > > Adding the ability to upgrade to HPKE without major breaking
> interface
> > > > changes is the objective, and greenfielding alternatives to JWE just
> > > delays
> > > > adoption of KEMs and resilience to harvest now decrypt later.
> > >
> > > Greenfielding alternatives to JWE is not an option.
> > >
> > > And even stuff that just goes against precedent can cause severe
> issues.
> > >
> > > E.g., Multi-recipient interface with similar design as I used in
> > > COSE-HPKE test code would seem to work just fine now. But it would be
> > > a major breaking change to add HPKE as currently specified to it.
> > >
> >
> > But both are drafts... Expecting breaking changes in drafts is as it
> should
> > be.
>
> Not breaking changes to drafts, breaking changes to implementations.
>
> The problem is follows:
>
> My COSE-HPKE test code has the following:
>
> impl MultiRecipientEncrypt
> {
>         pub fn get_key(&self) -> &[u8] { &self.key }
>         pub fn add_recipient(&mut self, recipient: &[CBOR]) { /* ... */ }
>         /* ... */
> }
>
> I.e. method to export the CEK and method to add arbitrary recipient.
>
> 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.

When I implemented JSON Serialization for JWE I had to do essentially the
same thing.

Granted I only used HPKE without the oneshot APIs.


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

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

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.

I don't see why COSE as WG should attempt to make them different, but that
is for the COSE List, which we should probably include at this point.


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


>
> > - Zero HPKE-specific modifications to JWE.
> > >
> >
> > So no new modes for integrated encryption and key encryption, and just
> use
> > the same terms direct key agreement and key agreement with key wrapping?
> >
> > That seems more confusing to me.
>
> That only means that Integrated Encryption is not specific to HPKE.
>

We defined Integrated Encryption in the HPKE draft, to refer specifically
to using HPKE to encrypt plaintext that is not a content encryption key.

If you are saying that other drafts can use the same term to do the same
thing, I suppose that's true, but I don't see how it's relevant to the Jose
HPKE draft.

Key Encryption is already defined by JWE (RFC 7516).
>

And is our use of the term consistent?


>
> > - Zero modifications to JWE for multiple recipient support.
> > >
> >
> > I think we are close to solving for this, we only need to address compact
> > mode for single recipient.
>
> There is also the location requirements for "enc" and "alg".
>
> And the requirements in JWE section 4.1.2. already prevent the attack:
>

I agree, I removed this note in a recent PR.


> ------------------------------------------------------------------------
> This algorithm MUST be an AEAD algorithm with a specified key length.
> ------------------------------------------------------------------------
>
> Because carrying out the attack in I-D.draft-ietf-lamps-cms-cek-hkdf-sha256
> would require using forbidden algorithm (not AEAD).
>
>
> > > The reason for requiring zero modifications for multiple recipients
> > > is that the interaction between recipients is specified by JWE, and
> > > trying to change those rules is asking for critical issues.
> > >
> >
> > We have achieved zero modifications for multiple recipients, in tests.
> >
> > But we do use different language to support interop between key agreement
> > with key wraps and key encryption.
>
> I think the language should specify how it works as Key Encryption, and
> then have JWE specify how it interacts with the others.
>

I agree, that's what we are trying to do.


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



>
> > > I don't see any need for HPKE-specific changes. Even a new header for
> > > KEM ciphertext (problematic for other reasons) could be usefully
> > > repurposed for KEM Key Agreement.
> > >
> >
> > I don't understand this.
> >
> > Are you saying that the header parameters we have registered for "key
> > encryption" (we haven't registered any new ones) can be used for key
> > agreement?
>
> 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.


> And yes, it is reusable. One could for example register new "alg"
> values "KEM" (Direct Key Agreement) and "KEM+A256KW" (Key Agreement with
> Key Wrapping) and then proceed to use the new parameter or new key type
> for the KEM ciphertext.
>

Agreed.


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


>
> > > > The current draft does the best at this so far, but it's possible in
> can
> > > be
> > > > further improved.
> > > >
> > > > I don't think your suggestion to concatenate strings values for enc
> and
> > > ct
> > > > is an improvement.
> > >
> > > What other way is there to satisfy:
> > >
> > > - Avoid requiring multi-shot HPKE for compact.
> > >
> >
> > Why should single shot be used?
>
> Simpler to use, and some HPKE implementations might not implement
> anything else.


Some implementations might not support one shot : )

... I don't think it's simpler to use.

I do think it's a simplification of the mandatory to implement HPKE APIs...

Another way of saying this, is that the oneshot APIs are overly fit to
specific protocol use cases.


HPKE RFC even mentions single-shot-only
> implementatations.
>

Sure, an API that exposes builders, can always be simplified to use them
internally, and in the process, make some choices for callers, and prevent
the callers from using those choices as extension points.

In our case, using one shot prevents enc from being mixed into aad.

If the oneshot APIs were the only mandatory ot implement interface the
argument to only support them, would be compelling.

But as I read the HPKE spec, they seem like an implementation detail that
only makes sense for certain protocols.



>
> > - Both modes encode the output in the same way.
> > >
> > > ?
> > >
> >
> > I'm not sure what you are talking about here.
> > We don't need to take all of what HPKE defined, especially if it defined
> > multiple ways to do things that are equivalent, we can pick the one way
> > that makes sense for the JSON ecosystem.
>
> Even if multiple ways are equivalent, those all might not be
> implemented.
>
> E.g., My HPKE implementation lacks one-shot, it only has multi-shot
> (if application needs single-shot, it needs to construct that from
> multi-shot mode). Another might be the other way.
>

I should have read further, we clearly agree.


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

The result is that oneshot APIs cannot be used to produce JWE
Serializations, unless you smuggle enc and ct inside the JWE Ciphertext.

So the question for the JOSE WG, is: do we smuggle an epk-like value in the
JWE CT, or do we require HPKE implementations to expose an API that is not
one shot, in order to support JOSE HPKE.


>
>
>
> -Ilari
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>