[jose] Re: HPKE and diminishing returns

Simo Sorce <simo@redhat.com> Tue, 18 June 2024 17:09 UTC

Return-Path: <simo@redhat.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 66A49C169413 for <jose@ietfa.amsl.com>; Tue, 18 Jun 2024 10:09:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.103
X-Spam-Level:
X-Spam-Status: No, score=-7.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 (1024-bit key) header.d=redhat.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 7TWwtrQGe98E for <jose@ietfa.amsl.com>; Tue, 18 Jun 2024 10:09:33 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 940A4C14F5F3 for <jose@ietf.org>; Tue, 18 Jun 2024 10:09:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1718730572; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TFQGvXT5bHvpQW9h0LWViXvUJMgGAhQHTnuXy5Xrrzg=; b=MZ+93Exg9gUa50RHYKCvYNHyRNGKdHcb4+y7ZMnz6Wub1jnZ8Jaq+SELZE9WjrVq8eJWBB LFi3ZJSzLKGpD8b94KfMaeBqrsKtahAOCAF6RGOjkBVyiBNWpEiVEr0k5NEbdnSpOM94j3 vNFC1XTy3M6REt0/JQEYTR3itTbuH2o=
Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-433-J8VzrWehM5OT6yYa2dZnUw-1; Tue, 18 Jun 2024 13:09:30 -0400
X-MC-Unique: J8VzrWehM5OT6yYa2dZnUw-1
Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-43fb05ef704so76117611cf.2 for <jose@ietf.org>; Tue, 18 Jun 2024 10:09:30 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718730570; x=1719335370; h=mime-version:user-agent:content-transfer-encoding:organization :references:in-reply-to:date:cc:to:from:subject:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=TFQGvXT5bHvpQW9h0LWViXvUJMgGAhQHTnuXy5Xrrzg=; b=eISiH8pXs5qUFd/Q74WAjkI57XX0YHr/dNUmhjQuWmB/yF1Asspj230Y0Z+AYt+2gY gTYRkJxGz4xD3hUWAxXjtHwM6qCbBXdpqTWP7s0rwgzid2scq/mEAbtCPUh6Q9D+7BAv fNlmWXhwr0PF+PiiB+tD2tjvP+CqVqv1hndKl57H+ELgbR/NpvElKF2SBJgQ0YiRToIX Owd4ThfFf+qzyWdtwNsP7talv8wqCD64xwcHGN5CQDiI7nGd68Awq4T3OAhyAVoFf7HR WOiFEwITI0eaOYcioi0VY/T/BZs/lXe8Z+lZ6LOPySfAUbJ6wrvefrAdy8MuBPbEH1r0 zUjg==
X-Gm-Message-State: AOJu0Ywv+UG8xgLhHiLEif95qnUhp+h/UOKo6MbuWPx9R+3ffEmZXpOG x2M8J8pNMGfCFtfu+UHjYXKyld8Jh931uAkZTFu4Rq45uvBticjM5jDsYIS47lT26tbttw7fSto Y6WUrBZshKIH9rHFkwkAck0E69K7hJjiwuIFVkRIF01y9SHwvNA==
X-Received: by 2002:a0c:da92:0:b0:6b2:b11b:c329 with SMTP id 6a1803df08f44-6b501e33004mr4466706d6.31.1718730570345; Tue, 18 Jun 2024 10:09:30 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IHR7KW3b4zgXcN3Y1cEgWR17Zlh2etpMdiMnQpwKBpMVucntSoIuxleYnh3nKaHajOjfVFLTA==
X-Received: by 2002:a0c:da92:0:b0:6b2:b11b:c329 with SMTP id 6a1803df08f44-6b501e33004mr4466366d6.31.1718730569885; Tue, 18 Jun 2024 10:09:29 -0700 (PDT)
Received: from m8.users.ipa.redhat.com ([2603:7000:9400:fe80::a75]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6b2a5eb4a49sm68454046d6.96.2024.06.18.10.09.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Jun 2024 10:09:29 -0700 (PDT)
Message-ID: <85065444d9d70370b5628e5fdafdaa586a008271.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Orie Steele <orie@transmute.industries>, Ilari Liusvaara <ilariliusvaara@welho.com>
Date: Tue, 18 Jun 2024 13:09:28 -0400
In-Reply-To: <CAN8C-_+iiX7XkzNeL+zR5ZLkq=6zmiC0qU5PdotOe6uFFVBZVg@mail.gmail.com>
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> <Zm3LJWxGdL6GcB5m@LK-Perkele-VII2.locald> <CAN8C-_+iiX7XkzNeL+zR5ZLkq=6zmiC0qU5PdotOe6uFFVBZVg@mail.gmail.com>
Organization: Red Hat
User-Agent: Evolution 3.52.2 (3.52.2-1.fc40)
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: SRM5GANS5JEZF6AKLHFRRY4WUWKNZELZ
X-Message-ID-Hash: SRM5GANS5JEZF6AKLHFRRY4WUWKNZELZ
X-MailFrom: simo@redhat.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: HPKE and diminishing returns
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/e9eCEK4gADCYQj5OCwTltUI3Y2c>
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 Sat, 2024-06-15 at 13:12 -0500, Orie Steele wrote:
> On Sat, Jun 15, 2024, 12:11 PM Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
> 
> > On Sat, Jun 15, 2024 at 09:02:24AM -0500, Orie Steele wrote:
> > > Brian wrote:
> > > 
> > > >  Perhaps it'd be less awkward to do something like JWHPKE that defines
> > > independent JOSE style JSON and compact serializations specifically for
> > > HPKE and is unencumbered by constructs and constraints of RFC7516?
> > > 
> > > This is an interesting idea.
> > > 
> > > MIMI also seems to be considering something like this, where MLS (see
> > > https://www.iana.org/assignments/mls/mls.xhtml#mls-ciphersuites ) and
> > CBOR
> > > are used together, instead of COSE or mixed in with COSE algorithms, here
> > > is the draft:
> > > 
> > > 
> > https://datatracker.ietf.org/doc/html/draft-ietf-mimi-content-04#section-4.4
> > > 
> > > I assumed we had already moved beyond "normal JWE" some time ago, given
> > the
> > > structure of a compact HPKE JWT (from the unadopted draft) looks like
> > this:
> > > 
> > > 
> > eyJhbGciOiJIUEtFLUJhc2UtUDI1Ni1TSEEyNTYtQUVTMTI4R0NNIiwiZXBrIjp7Imt0eSI6IkVLIiwiZWsiOiJCTFE0cHBMMFdlendzWjAyYTRtTFlkLVY1NUh2a0trT1hZVFN6NXJ3aWh6Z1BKbFY5M2Z3c2NfRzhLdTNfeHJKdUtST1FaT05HMzUxcmtKNnZ5Z0xDVk0ifX0...cwLUcH4GFHBZqq0Q-u3yHl-3Nb6eUpLg2w-WZyv1PfYi4pdgLyp_Mmw9atlp7NqujqIFgRhZpAvIRgOBlWPSfjGgi5qsUyU0lcY0DdICCPRMdPnA0JGtFI9iP11JbQLldSg-1Fo.
> > > 
> > > ( notice the gaps for things we don't need from
> > > https://datatracker.ietf.org/doc/html/rfc7516#section-3.1 )
> > > 
> > > Decoded protected header (after updates to align with COSE):
> > > 
> > > {
> > >   "alg": "HPKE-Base-P256-SHA256-A128GCM",
> > >   "ek":
> > > 
> > "BLQ4ppL0WezwsZ02a4mLYd-V55HvkKkOXYTSz5rwihzgPJlV93fwsc_G8Ku3_xrJuKROQZONG351rkJ6vygLCVM"
> > > }
> > 
> > Easier to do something like:
> > 
> > 
> > eyJhbGciOiJIUEtFLUJhc2UtUDI1Ni1TSEEyNTYtQUVTMTI4R0NNIiwiZW5jIjoiZGlyIn0.BLQ4ppL0WezwsZ02a4mLYd-V55HvkKkOXYTSz5rwihzgPJlV93fwsc_G8Ku3_xrJuKROQZONG351rkJ6vygLCVM..cwLUcH4GFHBZqq0Q-u3yHl-3Nb6eUpLg2w-WZyv1PfYi4pdgLyp_Mmw9atlp7NqujqIFgRhZpAvIRgOBlWPSfjGgi5qsUyU0lcY0DdICCPRMdPnA0JGtFI9iP11JbQLldSg-1Fo.
> > 
> > Which has decoded header:
> > 
> > {
> >   "alg": "HPKE-Base-P256-SHA256-A128GCM",
> >   "enc":"dir"
> > }
> > 
> > 
> > There is no reason to align the two modes, because implementations are
> > separate anyway.
> > 
> > (Also noticed that this avoids double base64-url).
> > 
> 
> This is an improvement.
> 
> 
> > 
> > > As Tiru points out, the purpose of the draft is to enable protocols (that
> > > rely on JWT or JSON serialization) to upgrade to PQ or hybrid encryption.
> > 
> > This can also be done with indirect HPKE (it is even compatible with
> > compact serialization), which avoids all problems with JWE
> > compatibility.
> > 
> > Or it could be done with native KEM support (I estimate adding that to
> > JOSE would take about half page of spec).
> > 
> > 
> > > A JWT is a JWS or a *compact* JWE today, so we have focused on making
> > "HPKE
> > > JWEs".
> > > 
> > > The fact that an "HPKE JWE" looks similar to a compact JWE using
> > > alg:ECDH-ES, enc: A128GCM, but is different, seems to be causing a lot of
> > > confusion.
> > 
> > What I think is confusing is that it looks like JWE, but it is not JWE.
> > 
> > And also that bulk encryption should be one operation, and ECDH-ES is
> > inherently different operation.
> > 
> > 
> > > I had similar confusion with SD-JWT, until I did an implementation, and
> > > then I realized that SD-JWT is like a JWT, but with a ~ on the end, and
> > > some new rules for processing parameters in the payload.
> > 
> > Based on brief look at SD-JWT spec, to me it looks like the "JWT" part
> > is an actual signed JWT, and not just something that looks like JWT.
> > 
> > 
> > > HPKE JWTs are like normal JWEs, but with some missing parameters (because
> > > HPKE internalizes them) and with some rules for processing new parameters
> > > (ek will be the only new parameter, assuming we can use alg and enc).
> > 
> > JWE explictly allows any combination of Encrypted Key, Initialization
> > Vector and Authentication Tag to be missing.
> > 
> > - If using Direct Encryption or Direct Key Agreement, Encrypted key is
> >   missing.
> > - If "enc" does not have IV nor nonce, Initialization Vector is missing.
> > - If "enc" combines ciphertext and tag, Authentication Tag is missing.
> > 
> > 
> > > I think this makes HPKE JWTs easier to understand than many other
> > formats I
> > > have reviewed.
> > > 
> > > Consider the compact example above, we could make a new kind of compact
> > > JWE, like compact JWE2.
> > > 
> > > That allows for this:
> > > 
> > > <encoded protected header>.<cipher text>
> > > 
> > > Or we could add support for unprotected headers in compact JWE2s:
> > > 
> > > <encoded protected header>.<encoded unprotected header>.<cipher text>
> > > 
> > > Then we could define a JWT as being a JWS, compact JWE, (compact SD-JWT?)
> > > or a compact JWE2.
> > 
> > JWS uses three components, so it might not be good idea, as it could be
> > confused with JWS.
> > 
> > And if using Encrypted Key, the full format has only a few bytes of
> > overhead.
> > 
> 
> Could use a different separator, to avoid confusion with JWS.
> Although I think counting "." Or "~" and guessing is worse than decoding a
> header and checking typ.
> 
> I think it's ok to have 3 components, separated by a "." Where the first is
> a protected header with optional alg and typ.
> 
> If we're not stuck with JWE rules, we can make alg optional just like it is
> in COSE.
> 

If you want to leave one optional you just leave it out and have 2
consecutive .. it is fine, there is no need to invent new stuff.

Parsing headers w/o knowing whether it is a JWE or a JWS is inefficient
and error prone, as you will then have to re-parse the input again with
the proper code later.

Using the number of dots has nothing sketchy for it, it is no different
the looking at the first few bytes of a file to guess the type via a
magic number.

Full validation later will throw an error if it was a malformed token,
but this is exactly why you should not confuse software by sending
obviously "incorrect" tokens by changing the number of dots.
> 


> > > AFAIK, a JWT can never be JSON serialized, which is why SD-JWT has
> > sections
> > > like this that clarify how to verify a JSON serialized SD-JWT:
> > > 
> > > 
> > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-09#name-verification-of-the-jws-jso
> > > 
> > > I bring up SD-JWT, because that draft seems to have taken the approach
> > > Brian has suggested.
> > 
> > To me, it looks like SD-JWT took compact JWS, and added more components
> > with a different separator.
> > 
> 
> That's what it is, it's also a different media type.
> 
> Even if it had the same number of components and separators as JWS and JWE,
> it would still be a different media type.
> 
> 
> > 
> > > If we are successful and produce an HPKE alg that can be used in JSON
> > > Serialized JWE Encryptions, we can start adding a recipient that supports
> > > ML-KEM, next to other recipients that support RSA or ECDH.
> > 
> > I think there are only a few details that need to be figured out, most
> > of those minor.
> > 
> > 
> > > If COSE WG is also successful, keys restricted for
> > > HPKE-Base-P256-SHA256-A128GCM in JOSE will also be useful in COSE.
> > 
> > And COSE stuff is just about complete.
> > 
> > 
> > > Of course it will take rough consensus in both groups to ensure we don't
> > > end up with confusing algorithms that are partially specified in
> > different
> > > ways.
> > 
> > Or trying to "align" things, but only managing to make things more
> > complex rather than simpler.
> > 
> 
> Sometimes it's simpler to make a new structure, sounds like we are heading
> for a new compact serialization that can be used for encrypted JWTs, but
> that is not a JWE.

Why? It is unclear why you would need that.
> 

> > > Luckily we appear to have a good amount of overlap, and both groups have
> > > now discussed the essentials for adding HPKE to JOSE and COSE.
> > > 
> > > I will summarize those essentials here once more, with the hope that
> > > providing clarity addresses the topic of "diminishing returns":
> > > 
> > > KEM Info -
> > > 
> > https://datatracker.ietf.org/doc/html/rfc9180#name-auxiliary-authenticated-app
> > 
> > HPKE spec has some rather annyoing limitations around KEM info. Actual
> > HPKE implementations may or may not actually have those limitations.
> > 
> > 
> > > Additional Authenticated Data -
> > > https://datatracker.ietf.org/doc/html/rfc9180#section-9.4
> > > Protected Headers - alg, enc, ek, psk_id
> > > 
> > > 2 Layer (Indirect / JSON Serialization, etc...)
> > > HPKE-Base-P256-SHA256-A128GCM upgrades { alg: ECDH-ES+A128KW } ... { enc:
> > > A128GCM }
> > > 1 Layer (A new kind of "direct encryption"... "does not exist in JWE")
> > > HPKE-Base-P256-SHA256-A128GCM upgrades { alg: ECDH-ES, enc: A128GCM }
> > 
> > Careful here: "Direct Encryption" is existing term in JWE, and it means
> > something different. Hence me using "Integrated Encryption" as the mode
> > name in the past ("direct encryption operation" was used as algorithm
> > operation name).
> > 
> 
> Right and if we are saying it's not a JWE, we should not reuse any JWE
> terminology... And we are not limited by normative statements about the
> construction of JWE.

Are you planning to build a completely new competing standard ... for
an algorithm ?

> But we are saying that JSON serialization with HPKE used to encrypt a
> content encryption key is JWE... Which seems to also be confusing people.

You can encrypt what you want with a JWE, including keys, I fail to see
why this would be confusing.

Simo.

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc