On Tue, Mar 19, 2024 at 10:23 PM David Benjamin <david...@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) < > 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 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+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/CAOmohSLz2RkStYYMHbXhfrFJ9zZFHGy%2BtnxwjyvAmYVb%3DyGZQg%40mail.gmail.com.
