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

Orie Steele <orie@transmute.industries> Thu, 20 June 2024 15:25 UTC

Return-Path: <orie@transmute.industries>
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 01593C14F6FA for <jose@ietfa.amsl.com>; Thu, 20 Jun 2024 08:25:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=transmute.industries
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Ho60FiuDSb7S for <jose@ietfa.amsl.com>; Thu, 20 Jun 2024 08:25:40 -0700 (PDT)
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D431AC14F721 for <jose@ietf.org>; Thu, 20 Jun 2024 08:25:40 -0700 (PDT)
Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-1f4a0050b9aso8589095ad.2 for <jose@ietf.org>; Thu, 20 Jun 2024 08:25:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transmute.industries; s=google; t=1718897140; x=1719501940; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tjWmi4SG1oFikx+QBtPR+q5TNi9iu+fc/r8IwVw6wkg=; b=MDBRShQx2ouClLoIvi/ngFiEPnAsYnFf0iMFvNTweOLvXyhTY5c1AKpPcUAU+VssrE sxuzAg0TFduo9a/Dl1vA0OlfD6qkBpD9ab0O9daitgYC8DmOOryggLYfxqojNQdE9VnA WuqYnty+2OSpYmpv1ukc68jtsBwq5LIx2zirYCs9HFuCQ9/jFFBMxN1lX9Iv2eZGU1oI pKVsYjbla4/ef+2Pl7jvPCdRtWcdIsfdTLueWAHGxRtLMd0kGmPz0WLaqipX9uwtZf8Q O7vhXuJHllqv1EFB5LM/xbw19UHMwIbSH/yrEUWQxVfOlpH0u9cfJx15FE2dAvRnMRa+ L6SA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718897140; x=1719501940; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tjWmi4SG1oFikx+QBtPR+q5TNi9iu+fc/r8IwVw6wkg=; b=fBNxeRB/AoDEOlooMEwfzL79mOB4AStN1GklOt2HZ7Wto+vfLe62wUf7GqxfzYVLMz wefRgnHvIv0gGMZ45BX0DVa96n1KA9AN4ZLAlUFMsezkfo0hMFxv4pukeMXca4uSFWh3 qRGng0MA/4APrje+NkKR/wqkkrntnQQzTcOfbcsvaomqfQjATP2bYq7Z7vzigfw1Jfxl dVtO1mIG2CICqQNIBtNms78SKtT/RtVTbj38TIKqFns9HdHkXPKzAQeVobRiaiwOwqmy DzGDPuqNHuZFV9G1MXlmPYcpiiHE0BKGTB1igVbpeNPgVqs1WyQdRSEdOGtfQSIVXwvg XtrA==
X-Forwarded-Encrypted: i=1; AJvYcCXBZgDuzgNcjs4hI2QewXqlro9w9J2UbEK7kZdNvrPiiXoF1TOl+3UtWbaSMaHewHC3Cu03Z3EofBX+qWpm
X-Gm-Message-State: AOJu0YwH3x+icm7zmh62kHCRi602hzP1zXNY3Qnsb9+NxaYjRPEwKzVe AUxTmR0HbiCX1T0rYcINlgU62rJItBFDCdiD79ETkVljRhPBs1VBkA5crsmtxgMH59Sn+PBxZsD 0rJrWDEKz35aWizS26JAxNQk7eY5z6c1mpvqyXdqAyyBRMIIHMX8=
X-Google-Smtp-Source: AGHT+IHKXnNU3sKG8IDjhOCWdY27aFwqDRF+RB3TxogjM5vg+5LMMBsmOeqr9sXusGBuMFNZt8IlFY+WY1obBRjkoeE=
X-Received: by 2002:a17:902:ea0c:b0:1f7:1931:7a8f with SMTP id d9443c01a7336-1f9aa46c28emr58449115ad.64.1718897139927; Thu, 20 Jun 2024 08:25:39 -0700 (PDT)
MIME-Version: 1.0
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> <ZnGn7eI6dKpfEUVA@LK-Perkele-VII2.locald> <CAFpG3gcT95i0DD11dUW37TN9ucfQVzYxMEkE8okiuFPzZAR=7w@mail.gmail.com> <ZnL5XmfTebPSltSE@LK-Perkele-VII2.locald> <CAFpG3gceD61PzG2VO3AD9E61ZUvjA+456CaihmQ3BgnBHzJEtQ@mail.gmail.com>
In-Reply-To: <CAFpG3gceD61PzG2VO3AD9E61ZUvjA+456CaihmQ3BgnBHzJEtQ@mail.gmail.com>
From: Orie Steele <orie@transmute.industries>
Date: Thu, 20 Jun 2024 10:25:28 -0500
Message-ID: <CAN8C-_LDFbA-UQV5RaER+_5Sqbhmp32QSQKdqu8s26iVQ7GHSw@mail.gmail.com>
To: tirumal reddy <kondtir@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000006e6da1061b53ed77"
X-MailFrom: orie@transmute.industries
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
CC: Ilari Liusvaara <ilariliusvaara@welho.com>, JOSE WG <jose@ietf.org>
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/Gew5fxmUy70cNCfHHSFYJSMg-XU>
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 9:03 AM tirumal reddy <kondtir@gmail.com> wrote:

> On Wed, 19 Jun 2024 at 20:59, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>> On Wed, Jun 19, 2024 at 05:00:09PM +0530, tirumal reddy wrote:
>> > On Tue, 18 Jun 2024 at 21:02, Ilari Liusvaara <ilariliusvaara@welho.com
>> >
>> > wrote:
>> >
>> > > Hybrid KEMs do not introduce the same complexities as HPKE:
>> > >
>> >
>> > HPKE has the advantage of integrated key management to handle the
>> > combination of the shared secrets to derive the final secret, utilizing
>> a
>> > KDF at the required strength, and ensuring the appropriate security
>> levels
>> > to combine traditional and post-quantum cryptography (PQC).
>> > What makes leveraging HPKE complex compared to native Hybrid KEM
>> support in
>> > JWE?
>> The thing that makes HPKE complicated to integrate is that it also
>> performs symmetric encryption.
> 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.

>> JOSE (and COSE) already has KDF in order to handle ECDH-ES. And proper
>> hybrid KEM (e.g., X-Wing) already handles combining traditional and
>> post-quantum cryptography.
> Yes, and X-Wing also defines Hybrid PQ/T HPKE interfaces.
>> > > > In both cases, a new parameter would have to be defined to carry
>> > > > the KEM ciphertext.
>> > >
>> > > New parameter is trivial to add.
>> >
>> >
>> > The new parameter will not be integrity protected but in the case of JWE
>> > compact serialization it must be integrity protected.
>> There is no need to integerity protect the encapsulated key unless using
>> some bad KEMs with PSK.
> No, compact serialization requires JWE protected headers and the new
> parameter has to be within the protected header.

encapsulated keys do not need to be secured as aead aad, afaik.

But then we need to explain that we are changing JWE to allow an
encapsulated key to be transported as an "encrypted key", and how that
works in JSON and compact serialization.

There is more than one way to solve the "where to put encapsulated keys"
problem safely I think, but they come with different trade offs.

New header parameters, or changing the definition of encrypted key, or both.

It seems ok to know that you need process parameters differently based on
the algorithm that is chosen.

>> And also, if there was some requirement for integerity protecting it,
>> then the whole thing would be broken, because it can not be protected
>> with multiple recipients.
> I meant integrity protected only in case of compact serialization and no
> integrity protection with multiple recipients.

Yes, and that's consistent with what I said above... Because of how JWE was
built, we are required to keep relating compact and JSON serializations.

>> > > 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.
>> > >
>> >
>> > Yes.
>> Idea that is bit odd but should technically work would be to use
>> Direct Key Agremeent and Key Encryption.
> 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.

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

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.

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

>> As constructing Key Encryption from HPKE is easier than constructing
>> Key Agreement with Key Wrap out of HPKE.
>> Yes, it is not symmetric, but there are going to be all sorts of
>> differences anyway.
>> > > This design is compatible with oneshot API (all designs using existing
>> > > modes are).
>> > >
>> >
>> > The design is not compatible with oneshot API in case of compact
>> > serialization, it creates a cyclic dependency (encapsulated key will
>> have
>> > to be integrity protected).
>> ECDH-ES also uses headers in key agreement step, and works just fine
>> with compact serialization.
>> Key agreement operation occurs before committing protected headers,
>> which occurs before bulk encryption.
> Yes, that means the oneshot API won't work (but that is anyway not a
> requirement to mandate the use of it).

Agreed that the oneshot API is not required, but it's possible that moving
encapsulated keys out of protected headers can have an impact here.

IIRC, epk is not required to be integrity protected, and it follows that
encapsulated keys are also not required to be integrity protected.

> -Tiru
>> > > One small issue with this is that enc gets base64-url encoded twice,
>> > >
>> >
>> > The overhead of base64url encoded twice is only applicable to compact
>> > serialization, it is the same problem with Hybrid KEM or Pure PQ KEM
>> (e.g.,
>> > ML-KEM) where the KEM ciphertext will have to be base64url encoded
>> twice.
>> Yes, native KEMs also double-encode, unless doing weird stuff with
>> encoding.
>> -Ilari
>> _______________________________________________
>> jose mailing list -- jose@ietf.org
>> To unsubscribe send an email to jose-leave@ietf.org
> _______________________________________________
> jose mailing list -- jose@ietf.org
> To unsubscribe send an email to jose-leave@ietf.org


Chief Technology Officer