On Fri, Sep 8, 2023 at 4:16 PM 'David Adrian' via blink-dev < blink-dev@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 <miketa...@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 dadr...@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+unsubscr...@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+unsubscr...@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/CAF8qwaAcvGPYD1LmsjnJvbs4_cxOoTSTkUAL5hEQL1wzQVZC%3Dw%40mail.gmail.com.
