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

Thanks, replies inline below:

> On 17 May 2021, at 15:05, Richard Barnes <rlb@ipv.sx> 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 <neil.madden@forgerock.com <mailto:neil.madden@forgerock.com>> wrote:
> 
> > On 17 May 2021, at 10:53, Michael Richardson <mcr+ietf@sandelman.ca <mailto:mcr%2Bietf@sandelman.ca>> wrote:
> > 
> > 
> > Neil Madden <neil.madden@forgerock.com <mailto:neil.madden@forgerock.com>> 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?
> > 
> 
> 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
> -- 
> ForgeRock values your Privacy <https://www.forgerock.com/your-privacy <https://www.forgerock.com/your-privacy>>
> 
> _______________________________________________
> Secdispatch mailing list
> Secdispatch@ietf.org <mailto:Secdispatch@ietf.org>
> https://www.ietf.org/mailman/listinfo/secdispatch <https://www.ietf.org/mailman/listinfo/secdispatch>

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