[jose] Re: draft-ietf-jose-hpke-encrypt adoption call feedback and prototype

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 22 June 2024 20:42 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A50F7C14F5FB for <jose@ietfa.amsl.com>; Sat, 22 Jun 2024 13:42:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id vprXr4yi08tO for <jose@ietfa.amsl.com>; Sat, 22 Jun 2024 13:42:37 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3b.welho.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4F5C14F5F7 for <jose@ietf.org>; Sat, 22 Jun 2024 13:42:35 -0700 (PDT)
Received: from localhost (localhost []) by welho-filter3.welho.com (Postfix) with ESMTP id F389715C5B for <jose@ietf.org>; Sat, 22 Jun 2024 23:42:32 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:]) by localhost (welho-filter3.welho.com [::ffff:]) (amavisd-new, port 10024) with ESMTP id vGGm32Yy9W4H for <jose@ietf.org>; Sat, 22 Jun 2024 23:42:32 +0300 (EEST)
Received: from LK-Perkele-VII2 (78-27-96-203.bb.dnainternet.fi []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id A49283BA for <jose@ietf.org>; Sat, 22 Jun 2024 23:42:31 +0300 (EEST)
Date: Sat, 22 Jun 2024 23:42:31 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: JOSE WG <jose@ietf.org>
Message-ID: <Znc3N4jZ9UpcCdcJ@LK-Perkele-VII2.locald>
References: <CAN8C-_KLwCjfj2_gOUM6jF_4jv8-w7UZC1hzDWpNSHP6OpQe6Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAN8C-_KLwCjfj2_gOUM6jF_4jv8-w7UZC1hzDWpNSHP6OpQe6Q@mail.gmail.com>
Sender: ilariliusvaara@welho.com
X-MailFrom: ilariliusvaara@welho.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-jose.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [jose] Re: draft-ietf-jose-hpke-encrypt adoption call feedback and prototype
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/VN9NRGr3nk78PhlNM1XkWKHfLNE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Owner: <mailto:jose-owner@ietf.org>
List-Post: <mailto:jose@ietf.org>
List-Subscribe: <mailto:jose-join@ietf.org>
List-Unsubscribe: <mailto:jose-leave@ietf.org>

On Sat, Jun 22, 2024 at 12:32:42PM -0500, Orie Steele wrote:
> Hello,
> I've created yet another prototype HPKE implementation to consider feedback
> we got from the adoption call.
> I know folks are struggling to follow along with HPKE details, but I'm
> going to address several points of feedback in this email to avoid creating
> separate threads for each topic.
> To make this bearable (bearer token joke), I have focused only on compact
> JWEs for use as JWTs.
> As you can see from:
> https://github.com/transmute-industries/hpke/blob/main/tests/jwt.test.ts#L26
> In the prototype, JWTs are built from { alg:
> 'HPKE-Base-P256-SHA256-A128GCM', enc: 'A128GCM' }
> The encapsulated key goes into the JWE Encrypted Key.
> This is a change from the draft-ietf-jose-hpke-encrypt-00 where the "ek"
> was placed in the protected header.
> It eliminates double base64url encoding.
> The enc value is set to `A128GCM`, this is a change from
> draft-ietf-jose-hpke-encrypt-00.

Redefining what enc: 'A128GCM' means in JWE is not acceptable.

Any extensions to JWE itself must encode to currently invalid things
(but compact and JSON serialization may still be used).

And then alg: 'HPKE-Base-P256-SHA256-A128GCM' sounds like Key
Encryption... And JWE is pretty explicit on how that works.

> Another exciting topic has been AuthMode and PSK support.
> draft-ietf-jose-hpke-encrypt-00 requests psk_id and auth_kid headers to
> support this use case, but does not request algorithms.

For PSK, easiest would be to have presence of psk_id header to select
PSK mode.

- Senders have to be explicitly configured about PSK to use anyway.
- Receiver not supporting PSK will get decryption failure anyway.

Auth is rather nasty can of worms. It is trivially insecure in
presence of multiple recipients, and still has security issues
even with one recipient (because HPKE fails Insider-Auth).

> I've now done a first attempt here:
> https://github.com/transmute-industries/hpke/blob/main/tests/jwt-auth-psk.test.ts
> The headers  "psk_id" and "auth_kid" should be optional, but I believe it
> is important to distinguish "auth mode psk" from "base" mode:
> - HPKE-Base-P256-SHA256-A128GCM
> - HPKE-Auth-P256-SHA256-A128GCM
> - HPKE-AuthPSK-P256-SHA256-A128GCM
> - HPKE-PSK-P256-SHA256-A128GCM
> This is sad, because it will result in registry bloat per mode.
> We could consider making the "mode" a dependent parameter of the algorithm,
> but then we lose the ability to distinguish keys which support auth mode
> from those that do not.

This sounds bit similar to ECDH-SS. While JOSE does not have that, COSE
does. What does COSE do with ECDH-SS sender keys?

And then one might want to restrict keys to HPKE, but no further.

> Now seems like a great time to talk about use cases for HPKE based JWTs, so
> we know which algorithms are actually needed.

For base mode, the only algorithms that JWE has no substitute for is
the post-quantum stuff.

Yes, HPKE might be a bit more compact, but I doubt people seriously
golfing bytes are using JWTs.

> As you can see, the latest editors copy includes some guidance on use of
> https://paulbastian.github.io/draft-bastian-dvs-jose/draft-bastian-dvs-jose.html#name-designated-verifier-signatur
> If this document were to register algorithms there would be substantial
> overlap with HPKE Encrypted JWT use cases.
> I believe that draft-ietf-jose-hpke-encrypt based JWTs can support the use
> case that draft-bastian-jose-alg-ecdh-mac is targeting.

HPKE auth mode has property that compromising receiver key allows
unlimited forgery.

And looks like to enable unlimited forgeries from a single sender, it
requires leaking just a single DH result (receiver private key times
sender public key).