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

Ilari Liusvaara <ilariliusvaara@welho.com> Thu, 20 June 2024 16: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 0DD52C14F689 for <jose@ietfa.amsl.com>; Thu, 20 Jun 2024 09:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Status: No, score=-1.907 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, 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 95Dv4bM-c2kI for <jose@ietfa.amsl.com>; Thu, 20 Jun 2024 09:29:43 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1b.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 74F8AC14F60D for <jose@ietf.org>; Thu, 20 Jun 2024 09:29:42 -0700 (PDT)
Received: from localhost (localhost []) by welho-filter1.welho.com (Postfix) with ESMTP id 31E2A20DD2 for <jose@ietf.org>; Thu, 20 Jun 2024 19:29:40 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:]) by localhost (welho-filter1.welho.com [::ffff:]) (amavisd-new, port 10024) with ESMTP id LnuYuOKZhTbh for <jose@ietf.org>; Thu, 20 Jun 2024 19:29:39 +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 E067228B for <jose@ietf.org>; Thu, 20 Jun 2024 19:29:38 +0300 (EEST)
Date: Thu, 20 Jun 2024 19:29:38 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: JOSE WG <jose@ietf.org>
Message-ID: <ZnRY8mu_YFkbYH1m@LK-Perkele-VII2.locald>
References: <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> <ZnGn7eI6dKpfEUVA@LK-Perkele-VII2.locald> <CAFpG3gcT95i0DD11dUW37TN9ucfQVzYxMEkE8okiuFPzZAR=7w@mail.gmail.com> <ZnL5XmfTebPSltSE@LK-Perkele-VII2.locald> <CAFpG3gceD61PzG2VO3AD9E61ZUvjA+456CaihmQ3BgnBHzJEtQ@mail.gmail.com> <CAN8C-_LDFbA-UQV5RaER+_5Sqbhmp32QSQKdqu8s26iVQ7GHSw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAN8C-_LDFbA-UQV5RaER+_5Sqbhmp32QSQKdqu8s26iVQ7GHSw@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/11LhA58OKfphsXujSVlFGqZQsug>
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 Thu, Jun 20, 2024 at 10:25:28AM -0500, Orie Steele wrote:
> On Thu, Jun 20, 2024 at 9:03 AM tirumal reddy <kondtir@gmail.com> wrote:
> >
> > This complication can be avoided by defining {alg:
> > "HPKE-Base-P256-SHA256", enc: "A128"}.
> >
> Yes, and this is why we are coordinating with COSE, because we want to
> align on this sort of thing.

I would not want to align on this, because it would make COSE part much
more complicated (anything is more complicated than what COSE part is
currently doing!).

> > I think you mean a) Direct Key Agreement b) Key Agreement with Key
> > Wrapping.
> >
> Just to clarify the current source of this confusion.
> Both JOSE and COSE drafts use "HPKE-Base-P256-SHA256-A128GCM" for the case
> where you are logically doing this:
> alg: HPKE-Base-P256-SHA256-A128KW, enc: A128GCM ( 2 layer / indirect )
> alg: HPKE-Base-P256-SHA256, enc: A128GCM (1 layer / "integrated" )
> The hope is that by coordinating between JOSE and COSE, we pick algorithms
> that align, and we use them in headers and keys in a consistent way.

That is not what the COSE draft is doing. What the COSE draft is doing
would essentially be:

1) alg: HPKE-Base-P256-SHA256-A128GCM, enc: A128GCM
2) enc: HPKE-Base-P256-SHA256-A128GCM, no alg!

The second is very illegal in JWE (zero recipients and asymmetric enc),
but allowed in COSE.

(It is actually not trivial that the first one is allowed in COSE, but
ultimately it turns out all assumptions do line up).

> So far, both groups have been saying "HPKE-Base-P256-SHA256-A128GCM" works
> for both cases.... which seems to have confused people in both working
> groups.

HPKE-Base-P256-SHA256-A128GCM is fine for both 1 and 2 layer in COSE,
and 2 layer in JOSE. It is not fine for 1 layer in JOSE.

> The reason for this comes from HPKE:
> """
> All the algorithms also take an info parameter that can be used to
> influence the generation of keys (e.g., to fold in identity information)
> and an aad parameter that provides additional authenticated data to the
> AEAD algorithm in use.
> """
> https://datatracker.ietf.org/doc/html/rfc9180#section-5
> ^ This sentence is what implies "alg" values like
> "HPKE-Base-P256-SHA256-A128GCM" instead of "HPKE-Base-P256-SHA256" (since
> this one has no AEAD, and therefore no aad parameter).

HPKE has special AEAD id 0xFFFF for no AEAD.

The only thing it allows is using secret export, which has context
parameter (in addition to info).

HPKE Secret Export can be used to construct Direct Key Agreement.