Intent to Ship: X25519Kyber768 key encapsulation for TLS on Desktop

477 views
Skip to first unread message

David Adrian

unread,
Mar 18, 2024, 10:37:15 AMMar 18
to blink-dev

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

tlskemkyberpostquantum

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 desktop124
Origin trial desktop first118
Origin trial desktop last123
DevTrial on desktop115
Shipping on Android128
OriginTrial Android last128
OriginTrial Android first118
DevTrial on Android115
Shipping on WebView128
OriginTrial webView last128
OriginTrial webView first118


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)

unread,
Mar 19, 2024, 12:34:41 PMMar 19
to David Adrian, blink-dev
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

tlskemkyberpostquantum

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

unread,
Mar 19, 2024, 4:44:26 PMMar 19
to Yoav Weiss (@Shopify), David Adrian, blink-dev

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

David Benjamin

unread,
Mar 19, 2024, 5:23:33 PMMar 19
to Yoav Weiss (@Shopify), David Adrian, blink-dev
> 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.

Yoav Weiss (@Shopify)

unread,
Mar 20, 2024, 1:58:33 AMMar 20
to David Benjamin, David Adrian, blink-dev
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.

Makes sense, thanks!!

I'll LGTM once the review gates are flipped.

David Adrian

unread,
Mar 20, 2024, 3:35:51 PMMar 20
to blink-dev, yoav...@chromium.org, David Adrian, blink-dev, David Benjamin
> 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)

unread,
Mar 20, 2024, 4:30:43 PMMar 20
to David Adrian, blink-dev, David Benjamin
LGTM1

Mike Taylor

unread,
Mar 20, 2024, 6:54:45 PMMar 20
to Yoav Weiss (@Shopify), David Adrian, blink-dev, David Benjamin

Daniel Bratell

unread,
Mar 21, 2024, 4:20:11 AMMar 21
to Mike Taylor, Yoav Weiss (@Shopify), David Adrian, blink-dev, David Benjamin
Reply all
Reply to author
Forward
0 new messages