LGTM2. Good luck! On 3/20/24 4:30 PM, Yoav Weiss (@Shopify) wrote:
LGTM1On Wed, Mar 20, 2024 at 8:35 PM David Adrian <dadr...@google.com> 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 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 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 <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ESSL> Search tags tls <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 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? /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://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 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 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 <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 aresubscribed 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 subscribedto 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/CAOmohSKkvJmq-wT%3Dm6q20igyOr8qqgcLuCCjPYto%3D-F0FATbHg%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKkvJmq-wT%3Dm6q20igyOr8qqgcLuCCjPYto%3D-F0FATbHg%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/a437c512-73df-4473-8fd7-277c3be97b15%40chromium.org.
