Re: [jose] HPKE Compact JWE Demo

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 10 February 2024 17:46 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFADCC14F5E7 for <jose@ietfa.amsl.com>; Sat, 10 Feb 2024 09:46:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOkl9qBfc6Ir for <jose@ietfa.amsl.com>; Sat, 10 Feb 2024 09:46:06 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4b.welho.com [83.102.41.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80712C14E515 for <jose@ietf.org>; Sat, 10 Feb 2024 09:46:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 8CE4D6311A for <jose@ietf.org>; Sat, 10 Feb 2024 19:46:02 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id SoLacxjGw0EV for <jose@ietf.org>; Sat, 10 Feb 2024 19:46:02 +0200 (EET)
Received: from LK-Perkele-VII2 (78-27-96-203.bb.dnainternet.fi [78.27.96.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 2BFC0292 for <jose@ietf.org>; Sat, 10 Feb 2024 19:36:47 +0200 (EET)
Date: Sat, 10 Feb 2024 19:36:47 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: JOSE WG <jose@ietf.org>
Message-ID: <Zce0L9JgcfA2CAE7@LK-Perkele-VII2.locald>
References: <CAN8C-_KgcsaY9A4icRhjHAPnEVb8fYu3vzf0=mk_ODkGEVDDtw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAN8C-_KgcsaY9A4icRhjHAPnEVb8fYu3vzf0=mk_ODkGEVDDtw@mail.gmail.com>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/0ODZ_2TTjrOOwv1JwvYuv0OuZ0s>
Subject: Re: [jose] HPKE Compact JWE Demo
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Feb 2024 17:46:08 -0000

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