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

tirumal reddy <kondtir@gmail.com> Wed, 19 June 2024 11:30 UTC

Return-Path: <kondtir@gmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240F4C14F6E1 for <jose@ietfa.amsl.com>; Wed, 19 Jun 2024 04:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfZz9SvD6ULZ for <jose@ietfa.amsl.com>; Wed, 19 Jun 2024 04:30:48 -0700 (PDT)
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 92D5CC14F6A3 for <jose@ietf.org>; Wed, 19 Jun 2024 04:30:48 -0700 (PDT)
Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a6f408b8037so75872666b.0 for <jose@ietf.org>; Wed, 19 Jun 2024 04:30:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718796647; x=1719401447; 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=b/m91HDO4mkqsCgPeUwWubHTp4hXowkBMFOb+mZkADU=; b=M8jUIhrPuHT/4hzD2se8mMwiReGH4tAwo/9TIlU5aF4ZyxYwTOjo0jOTILK7hXSn/H iZFLJRDi2UfzO49yV76UTB4AEvhP567q8GsZAysACl/8DqS4WsPJD1z8jEcwR4BabImd BVBUZeA72wxp/6Y0G+7Vo6/ADKKlzmCU9Z+NQ7MB9icJCN/eIudpOzAwRB83O5FaqoAw tY9MnVZv5VWamtQ5vHZiLclxOPm2R6X0i4Og2jOfChDXV66gOtlRoeavmLhBGO9MOPOU FkYZ/57ooSKcn4BFRaULI6amD4Y+aYQHVFc2tcLJ2+XLLBJZWFRYnHxzXcnZ4Y8RmEWX SOPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718796647; x=1719401447; 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=b/m91HDO4mkqsCgPeUwWubHTp4hXowkBMFOb+mZkADU=; b=ZBCoz/Bk/+eIqQ6RSY9Hq5kbbxy8mpD4v13nfTMsLJWvc4T1BOWVwU7p5ehhxuxYAb iZhHir9dG8s0aLnMa/U+c54DpLvaCkQGQcuebJ6mDWS0JM/Y7x7/ny8EIiYflrmB/YAI VdIwolPwWUHB32uehxZ/L/13WYnNZXBjFE599DikCHQ3Q1nz3fjzN789DCqRftJbeiPL YSZe6Ku6CzMJXH898wKqf2CyLL2W/7hyTGwIA4ZuiMaAhifu64qpzKkCbUIMLum26v/B AB7x/E21+q4iasbvNFH4EfIIcMYNrI8B3MhUesmaGHnq1vTCaEoXVnWZojqxsB1TT8L8 Yn4g==
X-Gm-Message-State: AOJu0YyH9j93NGMzS9P+3g0mZEisRuQ2jmcNd8dC7O7CQydy+M8+VasL 3LpnCu9f407+vdCwnRuVlqUMyq3PFqBJyQB1wMXIMDkPcs1jBcrp2HPTM4U81RzIG8uxHTLGQR4 n1qCxWy49jSz4fjW+CYZEkFn+MBP6tMeX
X-Google-Smtp-Source: AGHT+IGOftxTmiEJXqk1epkze/0TDwG5PA+c3h9BypSdVABV77jgf9+RGzPi9EXfvjpzfG2ebAfphKrPBgVb9YCm1r4=
X-Received: by 2002:a17:907:9412:b0:a6f:186d:9e9f with SMTP id a640c23a62f3a-a6fab7c62d2mr121289566b.5.1718796646316; Wed, 19 Jun 2024 04:30:46 -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>
In-Reply-To: <ZnGn7eI6dKpfEUVA@LK-Perkele-VII2.locald>
From: tirumal reddy <kondtir@gmail.com>
Date: Wed, 19 Jun 2024 17:00:09 +0530
Message-ID: <CAFpG3gcT95i0DD11dUW37TN9ucfQVzYxMEkE8okiuFPzZAR=7w@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary="0000000000008b829b061b3c8763"
Message-ID-Hash: PEMH2BTCHMXJ6LM3DPLG4V77PEZDSQ6V
X-Message-ID-Hash: PEMH2BTCHMXJ6LM3DPLG4V77PEZDSQ6V
X-MailFrom: kondtir@gmail.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
CC: 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/4b6fdU1CfPWW3Wdef7jqPKXwW18>
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, 18 Jun 2024 at 21:02, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> 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:
>

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 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 JWE/COSE.
>
>
> > 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.
It is the same complexity in both cases.


>


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

Yes.


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


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


> which is ~500 byte penalty with PQC stuff. It is also incompatible with
> Auth/AuthPSK stuff (but PQC stuff is incompatible with that anyway).
>

Agreed.

-Tiru


>
>
>
>
> -Ilari
>
> _______________________________________________
> jose mailing list -- jose@ietf.org
> To unsubscribe send an email to jose-leave@ietf.org
>