[jose] Re: [EXTERNAL] Re: HPKE and diminishing returns

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 18 June 2024 15:29 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 0D124C1CAE90 for <jose@ietfa.amsl.com>; Tue, 18 Jun 2024 08:29:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id NZV44nhgB9Jt for <jose@ietfa.amsl.com>; Tue, 18 Jun 2024 08:29:54 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2b.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 8D8CCC14F70D for <jose@ietf.org>; Tue, 18 Jun 2024 08:29:53 -0700 (PDT)
Received: from localhost (localhost []) by welho-filter2.welho.com (Postfix) with ESMTP id 9365C44555 for <jose@ietf.org>; Tue, 18 Jun 2024 18:29:50 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:]) by localhost (welho-filter2.welho.com [::ffff:]) (amavisd-new, port 10024) with ESMTP id zpJ7W8Kza-7M for <jose@ietf.org>; Tue, 18 Jun 2024 18:29:50 +0300 (EEST)
Received: from LK-Perkele-VII2 (78-27-96-203.bb.dnainternet.fi []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 5D8E4230A for <jose@ietf.org>; Tue, 18 Jun 2024 18:29:49 +0300 (EEST)
Date: Tue, 18 Jun 2024 18:29:49 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: JOSE WG <jose@ietf.org>
Message-ID: <ZnGn7eI6dKpfEUVA@LK-Perkele-VII2.locald>
References: <762F63AC-D5B7-4C07-AE44-29BDA6F1077C@gmail.com> <CA+k3eCRez+M4NAH=OqPfciHV4geAXiSn7AnrmUqdFwNVrXt6XA@mail.gmail.com> <Zm2NfyM_XcQZBswu@LK-Perkele-VII2.locald> <CAN8C-_+i4aEFvAFENmyJTzK-b2u_14hpBDeOGi1Nx6cCMyKxDA@mail.gmail.com> <CA+k3eCQo_NhKbZvKqc=rSCL8a8Jaj2PziQaxUriBV35cqE4a+g@mail.gmail.com> <CH0PR11MB573955429ADF7F9516A95DF19FCD2@CH0PR11MB5739.namprd11.prod.outlook.com> <ZnF1UfCv9iGrcwWr@LK-Perkele-VII2.locald> <CAFpG3geuPFMPMJdeD9yz=CxMgviZN7Nk=r8LfECDmBRhQk1+TA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAFpG3geuPFMPMJdeD9yz=CxMgviZN7Nk=r8LfECDmBRhQk1+TA@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: [EXTERNAL] Re: HPKE and diminishing returns
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/aFmxyd_J8NDbYHKuuIClwDaz4F0>
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 Tue, Jun 18, 2024 at 07:08:46PM +0530, tirumal reddy wrote:
> On Tue, 18 Jun 2024 at 17:32, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
> > On Mon, Jun 17, 2024 at 07:44:04PM +0000, Mike Ounsworth wrote:
> >
> > I estimate that defining the needed algorithms for native KEM support
> > to both JOSE and COSE would take about a page of spec text (not
> > counting IANA considerations).
> >
> Integrating the PQ/T hybrid scheme (ECDH-ES+ML-KEM) into JWE introduces the
> same complexities as HPKE that require modifications to the existing JOSE
> framework. 

Hybrid KEMs do not introduce the same complexities as HPKE:

The source of complexity in HPKE in JOSE is not fitting any existing Key
Managment Mode, and JOSE not being designed for new KMMs.

Whereas native KEMs (including hybrid) are DKA or KAwKW, and thus can
reuse all the JWE/COSE machinery for those modes. And then it is further
possible to reuse KDF, which is substantial part of ECDH-ES machinery

> In both cases, a new parameter would have to be defined to carry
> the KEM ciphertext. 

New parameter is trivial to add.

> As discussed previously, it is not essential to use the one-shot API
> in HPKE. It is easy to split the HPKE suite information differently
> for key encryption and direct algorithm to align with JWE. For
> example:
> 1. Direct: {alg: HPKE-Base-P256-SHA256, enc: A128GCM} (this could lead to
> mismatches in strength, and hash function, and poor interop)
> 2. Indirect: { alg: HPKE-Base-P256-SHA256-A128KW, enc: A128GCM }

I had designs like this a while back. I think HPKE-Base-P256-SHA256 can
be regarded as Direct Key Agreement. Which would make 
HPKE-Base-P256-SHA256-A128KW Key Agreement with Key Wrapping.

This design is compatible with oneshot API (all designs using existing
modes are).

One small issue with this is that enc gets base64-url encoded twice,
which is ~500 byte penalty with PQC stuff. It is also incompatible with
Auth/AuthPSK stuff (but PQC stuff is incompatible with that anyway).