Intent to Ship: X25519Kyber768 key encapsulation for TLS on Desktop

[David Adrian]

Contact emails

dad...@google.com

Explainer

https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html

Specification

https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html

Summary

Protect current Chrome TLS traffic against future quantum cryptanalysis by deploying the Kyber768 quantum-resistant key agreement algorithm. This is a hybrid X25519 + Kyber768 key agreement based on an IETF standard. This specification and launch is outside the scope of W3C. This key agreement will be launched as a TLS cipher, and should be transparent to users. https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html

Blink component

Internals>Network>SSL

Search tags

tls, kem, kyber, postquantum

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Post-quantum secure ciphers are larger than classical ciphers. This may cause compatibility issues with middleboxes.

Gecko: Shipped/Shipping (https://github.com/mozilla/standards-positions/issues/874) Firefox is also in the process of rolling this out.

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/244)

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Debuggability

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

N/A

Flag name on chrome://flags

enable-tls13-kyber

Finch feature name

PostQuantumKyber

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1442377

Launch bug

https://launch.corp.google.com/launch/4252981

Estimated milestones

Shipping on desktop	124
Origin trial desktop first	118
Origin trial desktop last	123
DevTrial on desktop	115

Shipping on Android	128
OriginTrial Android last	128
OriginTrial Android first	118
DevTrial on Android	115

Shipping on WebView	128
OriginTrial webView last	128
OriginTrial webView first	118

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5257822742249472

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42%2BgKeCTA6vWwzrE%3DDVR%3DTmQaCyDFQxqnXkOy9GcVyGtnA%40mail.gmail.com Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42%2B37SpGUy9t6bBkP13XQL4mrEaY%2Bu0wAzttjZyr_f2rGA%40mail.gmail.com

We plan to ship Kyber (ML-KEM) by default on desktop platforms only starting in M124. Kyber is a quantum-resistant key exchange mechanism for TLS that defends against harvest-now-decrypt-later attacks. This risk is relevant even if quantum computers do not yet exist.

Due to the structure of TLS 1.3, Kyber key shares are sent on the first ClientHello message regardless of server support. Servers that do not yet support Kyber will ignore it, and select a different algorithm. Servers that do support Kyber, such as GFEs and Cloudflare, will select Kyber and respond with their own Kyber key encapsulation. 

Unfortunately, Kyber key shares are around 35x larger than an X25519 key exchange, which increases the latency of the TLS handshake connections by 4-6%. On Desktop platforms, this effect is largely in the noise due to the higher likelihood of a high-bandwidth low-latency connection, and connection pooling reuse (one TLS handshake, many HTTP requests). On Android, this effect is far more noticeable and results in measurable regressions in LCP. 

Therefore, we intend to ship Kyber by default on Desktop platforms while we come up with a broader strategy for when and how to ship post-quantum cryptography on Android.

N.B. This Chrome Status entry is old and predates the new approval system from summer 2023.

This intent message was generated by Chrome Platform Status.

[Yoav Weiss (@Shopify)]

On Mon, Mar 18, 2024 at 3:37 PM 'David Adrian' via blink-dev <blin...@chromium.org> wrote:

Contact emails

dad...@google.com

Explainer

https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html

Specification

https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html

Summary

Protect current Chrome TLS traffic against future quantum cryptanalysis by deploying the Kyber768 quantum-resistant key agreement algorithm. This is a hybrid X25519 + Kyber768 key agreement based on an IETF standard. This specification and launch is outside the scope of W3C. This key agreement will be launched as a TLS cipher, and should be transparent to users. https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html

Blink component

Internals>Network>SSL

Search tags

tls, kem, kyber, postquantum

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Post-quantum secure ciphers are larger than classical ciphers. This may cause compatibility issues with middleboxes.

I'm guessing we're talking about MITM middleboxes, is that correct?

What's our plan to mitigate that risk? Slow rollout? Enterprise policy? Both? Something else entirely?

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42K4xE5n_Fbt8heqhNMC7-xf3RhNVopguK3YeTVoYM-VzQ%40mail.gmail.com.

[Mike Taylor]

Also, would you mind requesting reviews for the various shipping gates (privacy, security, enterprise, etc.) in your chromestatus entry?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BQfNtLkMRmf1o9-1GtVrDh6R2b_ugJeVNvjAQULPsTRA%40mail.gmail.com.

[David Benjamin]

> I'm guessing we're talking about MITM middleboxes, is that correct?

> What's our plan to mitigate that risk? Slow rollout? Enterprise policy? Both? Something else entirely?

Whether the middlebox MITMs the TLS connection is not terribly important. As long as they attempt to parse the ClientHello, they will need to handle the larger ClientHellos. They already do in that there's nothing stopping session tickets, etc., making the ClientHello large already, but Kyber makes it more likely.

We have already done a slow rollout. This has been running on 10% stable for several months now, and so far things seem to be fine. Some initial compat problems, but largely fixed now. We're far, far, far past the point that there's nothing more we can smoke out without proceeding to 100%.

And, yeah, the plan to mitigate the remaining risk is an enterprise policy, PostQuantumKeyAgreementEnabled, that admins can set while their middlebox vendors become post-quantum-ready. The admin policy has been in place for quite some time now, and has been communicated in enterprise release notes. Also the presence of any such incompatibility on an enterprise network blocks any deployment of post-quantum algorithms, so ultimately the middleboxes will just need to get fixed. The various ecosystem pressures towards getting to post-quantum are particularly strong in enterprise anyway, so hopefully admins will be more likely to understand why it's important for them to fix those.

https://chromeenterprise.google/policies/#PostQuantumKeyAgreementEnabled

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BQfNtLkMRmf1o9-1GtVrDh6R2b_ugJeVNvjAQULPsTRA%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

On Tue, Mar 19, 2024 at 10:23 PM David Benjamin <davi...@chromium.org> wrote:

> I'm guessing we're talking about MITM middleboxes, is that correct?

> What's our plan to mitigate that risk? Slow rollout? Enterprise policy? Both? Something else entirely?

Whether the middlebox MITMs the TLS connection is not terribly important. As long as they attempt to parse the ClientHello, they will need to handle the larger ClientHellos. They already do in that there's nothing stopping session tickets, etc., making the ClientHello large already, but Kyber makes it more likely.

We have already done a slow rollout. This has been running on 10% stable for several months now, and so far things seem to be fine. Some initial compat problems, but largely fixed now. We're far, far, far past the point that there's nothing more we can smoke out without proceeding to 100%.

And, yeah, the plan to mitigate the remaining risk is an enterprise policy, PostQuantumKeyAgreementEnabled, that admins can set while their middlebox vendors become post-quantum-ready. The admin policy has been in place for quite some time now, and has been communicated in enterprise release notes. Also the presence of any such incompatibility on an enterprise network blocks any deployment of post-quantum algorithms, so ultimately the middleboxes will just need to get fixed. The various ecosystem pressures towards getting to post-quantum are particularly strong in enterprise anyway, so hopefully admins will be more likely to understand why it's important for them to fix those.

https://chromeenterprise.google/policies/#PostQuantumKeyAgreementEnabled

Makes sense, thanks!!

I'll LGTM once the review gates are flipped.

[David Adrian]

> What's our plan to mitigate that risk? Slow rollout? Enterprise policy? Both? Something else entirely?

We also worked with a variety of vendors to fix incompatibilities that were brought to our attention, including Vercel, ZScaler, and PayPal CN (who have all since patched prior to any level of stable deployment).

> I'll LGTM once the review gates are flipped

Ack.

[Yoav Weiss (@Shopify)]

LGTM1

[Mike Taylor]

LGTM2. Good luck!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKkvJmq-wT%3Dm6q20igyOr8qqgcLuCCjPYto%3D-F0FATbHg%40mail.gmail.com.

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a437c512-73df-4473-8fd7-277c3be97b15%40chromium.org.