Re: [jose] HPKE Compact JWE Demo

[Michael Jones <[e-mail]>]

I support the design philosophy described by Orie below.

                                                                -- Mike

From: jose <[e-mail]> On Behalf Of Orie Steele
Sent: Saturday, February 10, 2024 1:15 PM
To: Ilari Liusvaara <[e-mail]>
Cc: JOSE WG <[e-mail]>
Subject: Re: [jose] HPKE Compact JWE Demo

This list feels like mostly complaints about JWE, and not about JOSE HPKE.

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

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

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

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.

The guiding principle is this:

Adding HPKE based single recipient and multiple recipient support, with as few changes to JWE as possible.

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.

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.

OS





On Sat, Feb 10, 2024, 11:46 AM Ilari Liusvaara <[e-mail]<mailto:[e-mail]>> wrote:
On Sat, Feb 10, 2024 at 08:39:07AM -0600, Orie Steele wrote:
> Hello Hybrid Public Key Encryption Enthusiasts,
>
> I feel JOSE HPKE is getting very close to stable, we have demonstrated
> compact and json serialization, including key encryption with both HPKE and
> normal ECDH-ES.

I feel that JOSE HPKE is far from stable.

I did start writing review of draft-rha-jose-hpke-encrypt-03, but never
finished that because I hit just too many issues to properly write up.


Very abbrevated list (some involve aspects of JWE I only learned about
recently):

1) Key Management Modes are defined by JWE, not JWA.
2) Key Agreement has nothing to do with the way HPKE is used.
3) The mode descriptions are misleading.
4) Encapsulated key is neither a structure nor a public key.
5) Using header parameters for encapsulated key is problematic.
6) Using JWK for encapsulated key is too complicated.
7) "enc" existing does not mean it is Key Encryption, just not
   Integrated Encryption.
8) JWE requires serialization invariance, which precludes any
   requirement on serialization used.
9) JWE unions the recipient headers, which precludes requirements on
   bucket used for any existing parameter.
10) JWE allows "enc" to be in recipient header(!) if all recipients have
    the same value. *vomit*. This precludes requiring enc to be in any
    given bucket.
11) Using JWE aad for recipients will cause severe implementation
    issues. There is clear precedent of not doing that even with
    something AEAD-capable.
12) Mode_auth and mode_auth_psk with Key Encryption are insecure.


Deviating from important JWE requirements with single-recipient mode
needs to be done carefully, because doing so can cause nasty issues with
implementations. Doing so in multi-recipient mode is categorically not
acceptable.


The simplest way to handle HPKE seal outputs is to just concatenate the
two, no length markers. This would seem to work well for both modes.

That is:

JWE_ciphertext = hpke_enc || hpke_ct
JWE_encrypted_key = hpke_enc || hpke_ct




-Ilari

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