> 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 On Wed, Mar 20, 2024 at 2:34 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > > > On Mon, Mar 18, 2024 at 3:37 PM 'David Adrian' via blink-dev < > blink-dev@chromium.org> wrote: > >> Contact emailsdadr...@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 componentInternals>Network>SSL >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ESSL> >> >> Search tagstls <https://chromestatus.com/features#tags:tls>, kem >> <https://chromestatus.com/features#tags:kem>, kyber >> <https://chromestatus.com/features#tags:kyber>, postquantum >> <https://chromestatus.com/features#tags:postquantum> >> >> TAG review >> >> TAG review statusNot 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? > > >> >> >> *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 >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ?N/A >> >> Flag name on chrome://flagsenable-tls13-kyber >> >> Finch feature namePostQuantumKyber >> >> Requires code in //chrome?False >> >> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1442377 >> >> Launch bughttps://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 discussionsIntent 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 >> <https://bughunters.google.com/blog/5108747984306176/google-s-threat-model-for-post-quantum-cryptography> >> 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 >> <https://chromestatus.com/>. >> >> -- >> 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+unsubscr...@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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42K4xE5n_Fbt8heqhNMC7-xf3RhNVopguK3YeTVoYM-VzQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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+unsubscr...@chromium.org. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BQfNtLkMRmf1o9-1GtVrDh6R2b_ugJeVNvjAQULPsTRA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaBGFvCfixK6xpL3gHTeqsSGays-E8Gqp5dXir%3D2EuEQkQ%40mail.gmail.com.
