I support the design philosophy described by Orie below.
-- Mike
From: jose <[email protected]> On Behalf Of Orie Steele
Sent: Saturday, February 10, 2024 1:15 PM
To: Ilari Liusvaara <[email protected]>
Cc: JOSE WG <[email protected]>
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
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
