[TLS] Re: [EXTERNAL] Re: Planned changes to Cloudflare's post-quantum deployment

[David Benjamin <[e-mail]>]

Yup, we plan to offer it in the initial ClientHello. (We currently offer
X25519Kyber768Draft00 in the initial ClientHello, so X25519MLKEM768 would
just take its place.)

Of course, it is still the server's responsibility to correctly evaluate
ClientHellos where X25519MLKEM768 appears in supported_groups and not
key_shares, if the servers aim to reliably pick a PQ option. This matches
the WG discussion around draft-ietf-tls-key-share-prediction and
downgrades. But given we've already deployed Kyber to Chrome on desktop, I
happily don't currently anticipate needing to send such a ClientHello in
Chrome for compatibility purposes. Then there's
draft-ietf-tls-key-share-prediction itself, which interacts with this.

On Tue, Sep 10, 2024 at 4:51 PM Andrei Popov <[e-mail]>
wrote:

> Hi David,
>
>
>
>    - After a little time to give early Kyber adopters time to migrate,
>    we'll roll the change out more fully.
>
> Are you planning to offer X25519MLKEM768 key share on the initial
> ClientHello (in addition to X25519), or just advertise for those servers
> willing to burn a round-trip?
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* David Benjamin <[e-mail]>
> *Sent:* Tuesday, September 10, 2024 1:35 PM
> *To:* Bas Westerbaan <bas=[e-mail]>
> *Cc:* <[e-mail]> <[e-mail]>; [e-mail]
> *Subject:* [EXTERNAL] [TLS] Re: Planned changes to Cloudflare's
> post-quantum deployment
>
>
>
> Thanks Bas! We plan to do the same for Chrome,
> replacing X25519Kyber768Draft00 with X25519MLKEM768. X25519MLKEM768 should
> be live now to a small fraction of Chrome Canary, so that servers have some
> clients in the wild to test against.
>
>
>
> After a little time to give early Kyber adopters time to migrate, we'll
> roll the change out more fully. (Due to how TLS 1.3 works, transitions for
> large KEMs are not the smoothest. Hopefully
> draft-ietf-tls-key-share-prediction will be ready for the next such
> transition.)
>
>
>
> David
>
>
>
> On Fri, Sep 6, 2024 at 7:03 AM Bas Westerbaan <bas=
> [e-mail]> wrote:
>
> Hi all,
>
>
>
> We are planning to replace X25519Kyber768Draft00 (0x6399)
> with X25519MLKEM768 (0x11ec) [1], a hybrid of ML-KEM-768 and X25519.
>
>
>
> We will support X25519Kyber768Draft00 and X25519MLKEM768 at the same time
> for a while to allow clients the opportunity to migrate without losing
> post-quantum security.
>
>
>
> Apart from these two, we also supported X25519Kyber768Draft00 under
> codepoint 0xfe31 and X25519Kyber512Draft00 (0xfe30). We logged zero uses of
> these two in the last week with a 1/100 sample rate. We will disable
> 0xfe31, 0xfe30 over the common weeks.
>
>
>
> Best,
>
>
>
>  Bas
>
>
>
>
>
> PS. Not sure I shared it here already, but we have public graph tracking
> client PQ key agreement deployment:
> https://radar.cloudflare.com/adoption-and-usage#post-quantum-encryption-adoption
> At the time of writing about 17% of all human traffic (by request count)
> with us is using X25519Kyber768Draft00.
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>