Updating this thread to say that Kyber has been at 10% stable on all platforms since 2023-11-06.
On Friday, September 8, 2023 at 3:32:09 PM UTC-6 David Benjamin wrote: > On Fri, Sep 8, 2023 at 4:16 PM 'David Adrian' via blink-dev < > blin...@chromium.org> wrote: > >> > LGTM to experiment from M117 - M118 inclusive. I think that's what >> you're asking for - please let me know if I'm reading this incorrectly. >> Good luck! >> >> Thank you! >> >> > Any pointers to learn more about this possible compat problem? >> >> The basic issue is that the Kyber key exchange pushes the ClientHello >> size to be larger than one packet. This makes it more likely that the call >> to read() on the TCP socket will not return the entire ClientHello in a >> single call. Not all implementations are prepared for this (despite the >> fact that the ClientHello TLS record includes the length at the start, and >> TCP is stream-based). >> > > It is also conceivable that we run into some system that just caps the > ClientHello size too tightly. Though so far all the issues we've seen have > been just folks not understanding how to use sockets. An actual size limit > would be a very, very tight constraint. > > The main difference is that packetization issues will be a little flaky. > You may just get (un)lucky and the whole ClientHello is available in one > read() anyway. Also they can be made to trigger on smaller ClientHellos > too, if we artificially send the ClientHello in two halves with a delay > between them. But this difference is mostly only relevant to help diagnose > the issue. (I.e. do you need to fix your socket reading logic, or fix some > unreasonable size limit in your code?) The actual impact to page loads is > about the same. > > >> On Fri, Sep 1, 2023 at 4:00 PM Mike Taylor <mike...@chromium.org> wrote: >> >>> Hi David, >>> >>> LGTM to experiment from M117 - M118 inclusive. I think that's what >>> you're asking for - please let me know if I'm reading this incorrectly. >>> Good luck! >>> >>> thanks, >>> Mike >>> On 8/28/23 9:18 AM, 'David Adrian' via blink-dev 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 Pending >>> >>> Risks >>> >>> >>> Interoperability and Compatibility >>> >>> Post-quantum secure ciphers are larger than classical ciphers. This may >>> cause compatibility issues with middleboxes. >>> >>> Any pointers to learn more about this possible compat problem? >>> >>> >>> >>> *Gecko*: No signal ( >>> 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? >>> >>> >>> Goals for experimentation This is a Finch experiment, not site opt-in. >>> >>> We are aiming to shake out bugs and incompatibilities with buggy TLS >>> stacks that do not correctly handle large TLS ClientHellos. Announcing a >>> public timeline for experimenting on stable provides the necessary >>> justification for teams at companies who have buggy TLS stacks to >>> prioritize fixing the bugs. >>> >>> Ongoing technical constraints >>> >>> Debuggability >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, Chrome OS, 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> >>> ? No >>> >>> 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 119 >>> OriginTrial desktop last 118 >>> OriginTrial desktop first 117 >>> DevTrial on desktop 115 >>> Shipping on Android 119 >>> OriginTrial Android last 118 >>> OriginTrial Android first 117 >>> DevTrial on Android 115 >>> Shipping on WebView 119 >>> >>> 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 >>> >>> 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/CAGkh42%2B37SpGUy9t6bBkP13XQL4mrEaY%2Bu0wAzttjZyr_f2rGA%40mail.gmail.com >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42%2B37SpGUy9t6bBkP13XQL4mrEaY%2Bu0wAzttjZyr_f2rGA%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/CAGkh42%2BoZZVLYf3hVfxe9RezK%2B_i26tL6M2r6aFLqd-cvoQvRg%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42%2BoZZVLYf3hVfxe9RezK%2B_i26tL6M2r6aFLqd-cvoQvRg%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/9eebd568-28c7-4e17-a20e-dd9a69b1090fn%40chromium.org.
