> 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. On Wednesday, March 20, 2024 at 1:58:33 AM UTC-4 yoav...@chromium.org wrote: > 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. > > >> >> On Wed, Mar 20, 2024 at 2:34 AM Yoav Weiss (@Shopify) < >> yoav...@chromium.org> wrote: >> >>> >>> >>> On Mon, Mar 18, 2024 at 3:37 PM 'David Adrian' via blink-dev < >>> blin...@chromium.org> wrote: >>> >>>> Contact emailsdad...@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 bug >>>> https://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+...@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+...@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/b84864e7-8888-4639-80eb-1c05a3854c0cn%40chromium.org.
