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.
