Subject: [Secdispatch] draft-madden-jose-ecdh-1pu

From: Neil Madden <[email-masked]>
Date: Mon, 17 May 2021 09:51:46 +0100

I am looking for a home for this draft that defines a new public key authenticated encryption algorithm for JOSE (JWE):

https://datatracker.ietf.org/doc/draft-madden-jose-ecdh-1pu/ <https://datatracker.ietf.org/doc/draft-madden-jose-ecdh-1pu/>

Existing JWE algorithms provide authenticated encryption only in the case of symmetric algorithms (i.e., AES) and all the existing public key encryption algorithms provide only confidentiality with some level of ciphertext integrity - no sender/origin authentication. When sender authentication is required in a public key context, currently users must resort to a nested combination of a digital signature JWS wrapped in a JWE. This can be inefficient, somewhat error-prone, and the stronger security properties provided by signatures (non-repudiation, 3rd-party verifiability) can be undesirable in some applications where deniability or privacy are important.

The draft was originally created to support work within the OAuth WG around JWT-format access tokens. However, the WG declined to adopt the draft, so it’s looking for a new home. I believe the draft is ideally suited to many applications within OAuth and OpenID Connect, and it has already been adopted by other standards work outside the IETF (https://identity.foundation/didcomm-messaging/spec/#key-wrapping-algorithms <https://identity.foundation/didcomm-messaging/spec/#key-wrapping-algorithms>). It may also be a worthwhile addition to the COSE WG as it has some advantages in code size compared to combined signature+encryption schemes, but I am primarily interested in the JOSE applications.

Kind regards,

Neil Madden
-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 May 2021 05:53:43 -0400

Neil Madden <[email-masked]> wrote:
    > The draft was originally created to support work within the OAuth WG
    > around JWT-format access tokens. However, the WG declined to adopt the
    > draft, so it’s looking for a new home. I believe the draft is ideally

Did the WG give a reason?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Neil Madden <[email-masked]>
Date: Mon, 17 May 2021 11:04:02 +0100

> On 17 May 2021, at 10:53, Michael Richardson <[email-masked]> wrote:
> 
> 

The meeting was some time ago now, but as I remember it essentially they felt that it was outside of their charter and area of expertise. Although the OAuth WG have done work around JWTs specifically in the past, they have not ever approved new cryptographic algorithms.

— Neil

---

From: Richard Barnes <[email-masked]>
Date: Mon, 17 May 2021 10:05:44 -0400

Hi Neil,

Thanks for bringing up this idea.  I wasn't in the WG for the discussion,
but if I were there, I would have been worried about the new crypto
construction that is laid out in this draft.

An interesting alternative approach here might be to use HPKE [1] as the
public-key encryption primitive here.  HPKE has been through CFRG review
already, and has security proofs.  It is already being used in protocols
like TLS ECH [2] and MLS [3], so there's starting to be some support for it
in libraries like boringssl [4].  And in addition to getting a
sender-authenticated mode as you do with 1PE, you would also get to upgrade
the base JWE ECDH mode to something with better proofs, and you would get a
PSK option, all basically for free.

Cheers,
--Richard

[1] https://tools.ietf.org/html/draft-irtf-cfrg-hpke
[2] https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-07#section-4
[3]
https://datatracker.ietf.org/doc/html/draft-ietf-mls-protocol#section-7.7
[4]
https://boringssl.googlesource.com/boringssl/+/chromium-stable/crypto/hpke/

On Mon, May 17, 2021 at 6:04 AM Neil Madden <[email-masked]>
wrote:

> The meeting was some time ago now, but as I remember it essentially they
> felt that it was outside of their charter and area of expertise. Although
> the OAuth WG have done work around JWTs specifically in the past, they have
> not ever approved new cryptographic algorithms.
>
> — Neil
> --
> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: Neil Madden <[email-masked]>
Date: Mon, 17 May 2021 15:57:17 +0100

Thanks, replies inline below:

> On 17 May 2021, at 15:05, Richard Barnes <[email-masked]> wrote:
> 
> Hi Neil,
> 
> Thanks for bringing up this idea.  I wasn't in the WG for the discussion, but if I were there, I would have been worried about the new crypto construction that is laid out in this draft.
> An interesting alternative approach here might be to use HPKE [1] as the public-key encryption primitive here.  HPKE has been through CFRG review already, and has security proofs.  It is already being used in protocols like TLS ECH [2] and MLS [3], so there's starting to be some support for it in libraries like boringssl [4]. 

ECDH-1PU is broadly similar to the DHKEM HPKE construction: it differs mainly in the key derivation process. The DH AuthEncap/AuthDecap process in section 4.1 is very similar. (It’s also similar to e.g. the Noise K one-way handshake pattern [1]). 

However, HPKE has one serious disadvantage for the use-cases I (and others) want it for, in that it explicitly rules out of scope what the HPKE draft (and related papers) refer to as “Insider-Auth” security [2]. That is, a recipient of a message sent using HPKE can construct a forgery that, to the other recipients of the original message, appears to come from the original sender. This is a critical weakness in, for example, an OAuth system built upon this, as shown in this example:

1. Alice talks to an OAuth authorization server and obtains an access token to access API1, API2, and API3.
2. The authorization server authenticates and encrypts a JWT-based access token using the public keys of API1, API2, and API3.
3. Alice uses the encrypted access token to access API1.

The problem here is that API1 can now construct their own access tokens to access API2 and API3 with whatever scope they wish. As the security analysis in [3] section 5.4 says:

We can show that for any AKEM, KS, and AEAD, the construction APKE[AKEM,KS, AEAD] given in Listing 8 is not (n,qe,qd)-Insider-Auth secure. The inherent reason for this construction to be vulnerable against this attack is that the KEM ciphertext does not depend on the message. Thus, the KEM ciphertext can be reused and the DEM ciphertext can be exchanged by the encryption of any other message. 

ECDH-1PU is not vulnerable to this issue precisely because, in the multi-recipient case, it ensures that the AKEM ciphertext *does* depend on the message, through the use of a compactly-committing AEAD [4] - the tag of which is effectively included as associated data in the KEM.

> And in addition to getting a sender-authenticated mode as you do with 1PE, you would also get to upgrade the base JWE ECDH mode to something with better proofs, and you would get a PSK option, all basically for free.

I don’t think at this point implementers would thank us for changing how the existing ECDH-ES encryption mode of operation works. ECDH-1PU is deliberately kept quite similar to that existing mode, and in fact can be implemented with just a few additional lines of code in a typical existing implementation.

[1]: http://noiseprotocol.org/noise.html#one-way-handshake-patterns <http://noiseprotocol.org/noise.html#one-way-handshake-patterns> 
[2]: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke#section-8.2.2 <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke#section-8.2.2> 
[3]: https://eprint.iacr.org/2020/1499.pdf <https://eprint.iacr.org/2020/1499.pdf> 
[4]: https://eprint.iacr.org/2017/664.pdf <https://eprint.iacr.org/2017/664.pdf> 

— Neil

> 
> Cheers,
> --Richard
> 
> [1] https://tools.ietf.org/html/draft-irtf-cfrg-hpke <https://tools.ietf.org/html/draft-irtf-cfrg-hpke>
> [2] https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-07#section-4 <https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-07#section-4>
> [3] https://datatracker.ietf.org/doc/html/draft-ietf-mls-protocol#section-7.7 <https://datatracker.ietf.org/doc/html/draft-ietf-mls-protocol#section-7.7>
> [4] https://boringssl.googlesource.com/boringssl/+/chromium-stable/crypto/hpke/ <https://boringssl.googlesource.com/boringssl/+/chromium-stable/crypto/hpke/>
> On Mon, May 17, 2021 at 6:04 AM Neil Madden <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On 17 May 2021, at 10:53, Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > 
> > Neil Madden <[email-masked] <mailto:[email-masked]>> wrote:
> ForgeRock values your Privacy <https://www.forgerock.com/your-privacy <https://www.forgerock.com/your-privacy>>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/secdispatch <https://www.ietf.org/mailman/listinfo/secdispatch>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 May 2021 10:59:05 -0400

>>> around JWT-format access tokens. However, the WG declined to adopt
    >>> the draft, so it’s looking for a new home. I believe the draft is
    >>> ideally
    >>

    > The meeting was some time ago now, but as I remember it essentially
    > they felt that it was outside of their charter and area of
    > expertise. Although the OAuth WG have done work around JWTs
    > specifically in the past, they have not ever approved new cryptographic
    > algorithms.

So, "good idea", sounds like OAUTH would use it, but they feel it is the
wrong place.

---

From: Neil Madden <[email-masked]>
Date: Thu, 27 May 2021 18:40:50 +0100

> On 17 May 2021, at 15:59, Michael Richardson <[email-masked]> wrote:
> 
> 

Yes, pretty much.

I’m actually wondering if re-chartering the JOSE working group may be a good way to proceed here? I have another (now expired) draft for a new algorithm [1] that I know at least one other vendor was keen to implement, and I believe there have been other potential ideas for JOSE improvements/changes. For example, I believe there is some interest in deprecating the “none” algorithm, which was the cause of some attacks. At some point in the not-too-distant future I would think that JOSE should really standardise at least one post-quantum encryption and signature algorithm too.

[1]: https://datatracker.ietf.org/doc/draft-madden-jose-siv-mode/ <https://datatracker.ietf.org/doc/draft-madden-jose-siv-mode/> 

— Neil