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

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 18 June 2024 12:02 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 E0D24C15107C for <jose@ietfa.amsl.com>; Tue, 18 Jun 2024 05:02:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id KdMbXBu5x9i3 for <jose@ietfa.amsl.com>; Tue, 18 Jun 2024 05:02:20 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4b.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 9F8BBC14F5F2 for <jose@ietf.org>; Tue, 18 Jun 2024 05:02:20 -0700 (PDT)
Received: from localhost (localhost []) by welho-filter4.welho.com (Postfix) with ESMTP id 8679567ED5 for <jose@ietf.org>; Tue, 18 Jun 2024 15:02:17 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:]) by localhost (welho-filter4.welho.com [::ffff:]) (amavisd-new, port 10024) with ESMTP id fnQ-yTar6RCc for <jose@ietf.org>; Tue, 18 Jun 2024 15:02:17 +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 D27193BA for <jose@ietf.org>; Tue, 18 Jun 2024 14:53:53 +0300 (EEST)
Date: Tue, 18 Jun 2024 14:53:53 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: JOSE WG <jose@ietf.org>
Message-ID: <ZnF1UfCv9iGrcwWr@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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CH0PR11MB573955429ADF7F9516A95DF19FCD2@CH0PR11MB5739.namprd11.prod.outlook.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/xxT44cjXRwdc67AO5HVZZSQ0pzQ>
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 Mon, Jun 17, 2024 at 07:44:04PM +0000, Mike Ounsworth wrote:
> My TL;DR #1: If you already have an encryption framework that
> separates out the asymmetric key establishment from the symmetric
> content encryption, then integrating HPKE (RFC9180) is … awkward at
> best; it may be wise to borrow useful ideas from HPKE (like the
> domain separation properties that you get from LabeledExtract), but
> taking HPKE in its entirety is problematic.

And JOSE does exactly that, and as result, integrating (direct) HPKE
is quite thorny. The indirect case (act as PKE to encrypt CEK) is
much easier.

Whereas COSE has very different kind of design, which makes integrating
HPKE very easy. It even gives multi-recipient for free!

> My TL;DR #2: KEMs are a different interface from either Key Transport
> (ie pure PKE), or Key Agreement (DH) and probably should get their
> own message types.

Due to technical limiations in JOSE and COSE, KEMs must be Direct
Key Agreement algorithms.

Fortunately, the main Direct Key Agreement algorithm in JOSE and COSE
is ECDH-ES, which is extremely similar to KEMs. Where "extremely
similar" means operations map one-to-one.

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).

> Again, I’m just a tourist in JOSE / COSE, but this feels like CMS
> where you already have the asymmetric “alg” and symmetric “enc”
> separated out. Trying to merge these back together so that you can
> take advantage of the one-shot HPKE API seems like a whole lot of
> complex breaking changes in the name of simplicity. 

This is the case in JOSE, but not in COSE. Bulk encryption in COSE is
not required to be symmetric.

> I would cherry-pick the useful ideas out of 9180 and add the minimum
> amount of new message types to support KEMs.

In JOSE and COSE, it is not about new message types, but new algorithms
of already existing type.

At minimum:

- KEM (Direct Key Agreement)
- KEM+A256KW (Key Agreement with Key Wrap/Wrappping).