Re: [jose] HPKE Compact JWE Demo

Likewise - I think Orie's described approach is sane

Mike Prorock
CTO - mesur.io

On Sat, Feb 10, 2024, 14:47 Michael Jones <michael_b_jones@hotmail.com>
wrote:

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