Re: [jose] HPKE Compact JWE Demo

[Ilari Liusvaara <[e-mail]>]

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.

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.


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

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


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


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


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


> - 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.
Key Encryption is already defined by JWE (RFC 7516).


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

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

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

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.

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.


> > > 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. HPKE RFC even mentions single-shot-only
implementatations.


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




-Ilari