x25519kyber768 support

[vparla]

Title: Support for x25519kyber768 TLS extension to allow PQ cryptography in Envoy TLS sessions.

Description:
We would like to request adding support for x25519kyber768 cryptography so the Envoy can support PQ TLS capabilities from x25519kyber768 capable clients and servers.

A recent fix was added to address the tldr.fail handshake issue. However this request is for full support of x25519kyber768

Relevant Links:
https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html

[adisuissa]

cc @ggreenway

[ggreenway]

I think (but haven't tested) that if you add X25519Kyber768Draft00 to ecdh_curves it will work.

Note that, because this is only a draft, that this configuration may stop working in a future version of Envoy. This string is passed directly to BoringSSL, and if they drop this draft version at some time in the future, it will no longer work.

[bardiharborow]

I think (but haven't tested) that if you add X25519Kyber768Draft00 to ecdh_curves it will work.

I can confirm that this does work. I was able to establish a connection with Chrome 133 with #enable-tls13-kyber=true and #use-ml-kem=false set.

In principle, X25519MLKEM768 may also work as of google/boringssl@7fb4d3d, but my version of BoringSSL does not appear to have it yet.

[dethi]

I can also confirm that it works with X25519MLKEM768 (tested with Envoy 1.33.2). I think it would be nice to officially support PQC and document it. At minimum, I think adding X25519MLKEM768 to the extensions.transport_sockets.tls.v3.TlsParameters.ecdh_curves documentation.

[wiktor-k]

Just FYI, Let's Encrypt recommends enabling X25519MLKEM768:

If you operate servers, please ensure they support hybrid post-quantum key exchange (X25519MLKEM768). Major browsers and operating systems already do, and turning it on at the server is one of the highest-leverage things you can do this year.

[netanmangal]

France's ANSSI will stop certifying security products without post-quantum cryptography starting in 2027 — the first hard regulatory deadline of its kind globally. Additional mandates: US NSA CNSA 2.0 (2027), NIST IR 8547 (deprecation by 2030, disallowed by 2035), EU critical infrastructure (2030).

Update: the BoringSSL dependency blocker for PQC is now resolved.

Envoy's main branch uses BoringSSL 0.20260413.0 (April 13, 2026), which includes ML-KEM and ML-DSA support. The BoringSSL upgrade requested in #42893 was completed via PR #43260 (merged February 2, 2026).

The remaining gap is Envoy-level enablement:

1. Document that X25519MLKEM768 can be set in ecdh_curves config
2. Verify hybrid PQC key exchange works end-to-end
3. Consider adding X25519MLKEM768 to the default curve list (gRPC already did this in PR #42560, merged June 2026)

[netanmangal]

Happy to help with documentation and testing.

[ggreenway]

One issue with adding to the default curve list is that there is an expected 1 RTT performance regression in QUIC handshakes, because the ServerHello is much larger, but there are limits to how much data the server can send relative to what the client has sent, in order to prevent bandwidth amplification attacks.

[netanmangal]

That's a fair point @ggreenway . Thanks for that!

Should we keep the current defaults unchanged and just add documentation showing how operators can opt-in to X25519MLKEM768 via ecdh_curves config - for now atleast?