We've been running ECH at 50% Beta for TCP since I last posted (Nov 7, 2022). We recently landed support for ECH+QUIC, which is also running on Beta. We never made it to 1% Stable, so I'd like to continue to experiment / actually start a stable experiment, probably from 115-119.
The main server-side deployment we know of prefers QUIC, so the QUIC implementation was blocking real data collection. On Monday, November 7, 2022 at 12:29:07 PM UTC-7 David Adrian wrote: > An update: > > - We are deploying to 50% Beta as I write > - We have seen very little usage so far, however the usage we do see > is basically entirely successful. > > The main issue at this point is Chrome does not yet support ECH with QUIC > connections, and the main deployment we know of prefers QUIC to TCP. We > plan to add QUIC support before experimenting further, and will update this > thread accordingly. > > Similarly, we will need to extend the length of this experiment at least > through M111 in January, 2023. > > On Wed, Aug 24, 2022 at 8:32 AM Mike West <mk...@chromium.org> wrote: > >> LGTM to experiment from M105 to M109 (inclusive). It'd be excellent to >> come back to the group with initial results in the (likely?) case you need >> to extend and revise. >> >> Good luck! >> >> -mike >> >> >> >> On Tue, Aug 23, 2022 at 8:03 PM David Benjamin <davi...@chromium.org> >> wrote: >> >>> (Sorry for the late reply. Was out sick for a bit.) >>> >>> On Thu, Aug 11, 2022 at 4:06 PM Mike West <mk...@google.com> wrote: >>> >>>> I'm excited to see this! One question inline about timelines: >>>> >>>> On Thursday, August 11, 2022 at 9:55:48 PM UTC+2 David Benjamin wrote: >>>> >>>>> Contact emailsdavi...@chromium.org, dad...@google.com >>>>> >>>>> ExplainerNone >>>>> >>>>> Specificationhttps://datatracker.ietf.org/doc/html/draft-ietf-tls-esni >>>>> >>>>> Summary >>>>> >>>>> The TLS Encrypted ClientHello (ECH) extension enables clients to >>>>> encrypt ClientHello messages, which are normally sent in cleartext, under >>>>> a >>>>> server’s public key. This allows websites to opt-in to avoid leaking >>>>> sensitive fields, like the server name, to the network by hosting a >>>>> special >>>>> HTTPS RR DNS record. (Earlier iterations of this extension were called >>>>> Encrypted Server Name Indication, or ESNI.) >>>>> >>>>> >>>>> Blink componentInternals>Network>SSL >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ESSL> >>>>> >>>>> Search tagsech <https://chromestatus.com/features#tags:ech>, esni >>>>> <https://chromestatus.com/features#tags:esni>, tls >>>>> <https://chromestatus.com/features#tags:tls>, ssl >>>>> <https://chromestatus.com/features#tags:ssl> >>>>> >>>>> TAG reviewNot applicable; this is a protocol under IETF >>>>> >>>>> TAG review statusNot applicable >>>>> >>>>> Risks >>>>> >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> As a networking protocol, interoperability risks look different from a >>>>> web platform API: This is a draft of a developing protocol, so the final >>>>> standard will differ from what we ship now. We manage this as in other >>>>> protocol work: the draft uses different codepoints in the DNS record and >>>>> ClientHello, set up to not conflict with the final standard. There is >>>>> also >>>>> a risk of breaking buggy servers or network middleware. ECH is DNS-gated, >>>>> so non-ECH servers won't be exposed to ECH itself. We do implement ECH's >>>>> GREASE mechanism (section 6.2 of the draft), but this should appear as >>>>> any >>>>> normal unrecognized extension to non-ECH servers. Servers and network >>>>> elements that are compliant with RFC 8446, section 9.3, should not be >>>>> impacted. We will be monitoring for these issues as part of the >>>>> experiment, >>>>> comparing error rates and handshake times both for HTTPS servers as a >>>>> whole, and the subset of those that advertise ECH in DNS. >>>>> >>>>> >>>>> *Gecko*: In development ( >>>>> https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox >>>>> ) >>>>> >>>>> *WebKit*: No signal >>>>> >>>> >>>> It would be reasonable to ask via >>>> https://github.com/WebKit/standards-positions/issues. >>>> >>> >>> Filed https://github.com/WebKit/standards-positions/issues/46 >>> >>> >>>> >>>>> *Web developers*: Positive ( >>>>> https://blog.cloudflare.com/encrypted-client-hello) >>>>> >>>>> *Other signals*: >>>>> >>>>> Ergonomics >>>>> >>>>> ECH is part of TLS, so it is largely abstracted away from web platform >>>>> APIs themselves. >>>>> >>>>> >>>>> Activation >>>>> >>>>> This is a network protocol and thus inherently requires server >>>>> software changes. It also requires keys deployed in the HTTPS DNS record. >>>>> At this stage in the process, we do not expect ECH to be deployed beyond >>>>> a >>>>> few early adopters. Rather, this experiment is part of real-world testing >>>>> for the developing protocol. The connection with the DNS record is of >>>>> particular note. It is possible that, due to DNS caching, etc., that the >>>>> DNS record we fetch is out of sync with the server instance we talk to. >>>>> ECH >>>>> has a built-in recovery mechanism to repair these mismatches. One of the >>>>> aims of the experiment will be to validate this mechanism. >>>>> >>>>> >>>>> Security >>>>> >>>>> See >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-14#section-10 >>>>> for security considerations in the specification >>>>> >>>>> >>>>> 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? >>>>> >>>>> No WebView-specific risks >>>>> >>>>> >>>>> >>>>> Goals for experimentation >>>>> >>>>> This is a new extension to TLS. As part of the standardization >>>>> process, we wish to validate the design, and ensure it works, performs >>>>> well, etc. This is also the first time a TLS extension has been gated on >>>>> DNS. This introduces a new set of deployment risks. ECH includes >>>>> mechanisms >>>>> to mitigate these risks, which we also aim to validate with this >>>>> experiment. We'll do this by A/B testing clients with and without ECH >>>>> enabled, and comparing error rates and latency across all TLS >>>>> connections, >>>>> and across just connections to hostnames with ECH keys in DNS. We'll also >>>>> be looking at how often the recovery flow is used. >>>>> >>>>> >>>>> Reason this experiment is being extended >>>>> >>>>> n/a >>>>> >>>>> >>>>> Ongoing technical constraints >>>>> >>>>> None >>>>> >>>>> >>>>> Debuggability >>>>> >>>>> Servers that use ECH are visible in the DevTools security panel. >>>>> >>>>> >>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>> Mac, Linux, Chrome OS, Android, and Android WebView)?Yes >>>>> >>>>> While supported on all platforms, ECH requires keys fetched via DNS in >>>>> the new HTTPS record. Chrome can currently fetch the HTTPS record over >>>>> DoH >>>>> and over our built-in DNS resolver. As of writing, the built-in DNS >>>>> resolver is not yet enabled on Windows (https://crbug.com/1317948) >>>>> and Linux (https://crbug.com/1350321). >>>>> >>>>> >>>>> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ?No (see https://github.com/web-platform-tests/wpt/issues/20159) >>>>> >>>>> Flag nameencrypted-client-hello >>>>> >>>>> Requires code in //chrome?False >>>>> >>>>> Tracking bughttps://crbug.com/1091403 >>>>> >>>>> Launch bughttps://crbug.com/1349902 >>>>> >>>>> Estimated milestones >>>>> DevTrial on desktop 105 >>>>> DevTrial on Android 105 >>>>> >>>> >>>> When do you plan to end the experiment? M109, perhaps? >>>> >>> >>> Didn't have a particular set end time... depends on how long it takes to >>> answer our questions and how things shake out I suppose. We can tentatively >>> say M109 if we need an end date. (Although at this point I suspect a lot of >>> the milestones will get shifted over anyway.) >>> >>> >>>> >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> https://chromestatus.com/feature/6196703843581952 >>>>> >>>>> Links to previous Intent discussionsIntent to prototype: >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/YEo4LqB7nWI >>>>> >>>>> >>>>> 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/df76ac9a-856e-4639-8eb0-c5658e65bc44n%40chromium.org.
