Re: [jose] HPKE Compact JWE Demo

[Ilari Liusvaara <[e-mail]>]

On Sat, Feb 10, 2024 at 03:15:11PM -0600, Orie Steele wrote:
> This list feels like mostly complaints about JWE, and not about JOSE HPKE.

Sure, JWE has its problems, but that ship has sailed. Debating those
problems when working with JWE is not productive. One just has to live
with those.

There is only one complaint about JWE, and that is then immediately
taken as something one needs to live with. Plenty of other complaints
just are not relevant here.


> With compatibility with ECDH-ES JWE shown, I feel pretty confident that the
> design is on a good track.

That was only a smoke test. Failing it would have been really bad, but
passing does not mean things are actually working.


> If there are problems in the design we have now... those problems are
> fundamental to JWE.

I disagree. I think things can be vastly improved while modifying JWE
no more than what is currently done.


> We are adding HPKE support to JWE not making an incompatible alternative to
> JWE, that only works with HPKE.

The draft does currently have requirements incompatible with JWE. E.g.,

- Requirement to use JSON serialization for Key Encryption.
- Requirement to put "enc" in protected parameters for Key Encryption.
- Requirement to put "alg" in per-recipient unprotected header for Key
  Encryption.

And then arguably also requirement to use compact serialization for
Integrated Encryption.


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.


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


> The guiding principle is this:
> 
> Adding HPKE based single recipient and multiple recipient support, with as
> few changes to JWE as possible.

The guiding principles I have:

- Keep things as simple as possible.
- Minimize disruption caused by JWE changes for single recipient.
- Zero HPKE-specific modifications to JWE.
- Zero modifications to JWE for multiple recipient support.

Note that first two are relative, while the last two are absolute.
And new header parameters, algorithms, etc. are not "modifications to
JWE".

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.

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.

And as example of disruption JWE changes could cause, consider
implementation that immediately parses JWE doing the first three steps
of JWE section 5.2. Maybe together with doing step 15. By time that is
done, original serialization is lost. That is very much code one does
not want to touch lightly.


> This constraint makes our job simple... What parameters go in headers? How
> can we accomplish what is needed with as few HPKE specific changes as
> possible.

For stuff relevant to HPKE, nothing except alg needs to go in headers.
This is in contrast to things like Key Agreement ephemeral key, that
does need to go into headers.

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.

 
> 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.
- Both modes encode the output in the same 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.




-Ilari