LGTM1 On Wed, Mar 20, 2024 at 8:35 PM David Adrian <[email protected]> wrote:
> > 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 [email protected] > wrote: > >> On Tue, Mar 19, 2024 at 10:23 PM David Benjamin <[email protected]> >> 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) < >>> [email protected]> wrote: >>> >>>> >>>> >>>> On Mon, Mar 18, 2024 at 3:37 PM 'David Adrian' via blink-dev < >>>> [email protected]> wrote: >>>> >>>>> Contact [email protected] >>>>> >>>>> 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 [email protected]. >>>>> 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 [email protected]. >>>> 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 [email protected]. 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.
