We are ramping ECH up to 10% of Stable Channel. We will send an Intent-to-Ship if the rollout continues successfully.
On Fri, Jun 9, 2023 at 10:38 AM Achiel van der Mandele < ach...@cloudflare.com> wrote: > That's great to hear! Looking forward to ECH traffic ramping up (from the > looks of it 115 is slated to go out in July?) > > Thanks, > -- > Achiel van der Mandele > Product Manager > > > On Fri, Jun 9, 2023 at 11:13 AM 'David Adrian' via blink-dev < > blink-dev@chromium.org> wrote: > >> 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 >>>>>>> >>>>>>> Specification >>>>>>> https://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 a topic in the >> Google Groups "blink-dev" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/a/chromium.org/d/topic/blink-dev/KrPqrd-pO2M/unsubscribe >> . >> To unsubscribe from this group and all its topics, 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/df76ac9a-856e-4639-8eb0-c5658e65bc44n%40chromium.org?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/CAGkh42KY05Qv_7t_ob0TXmyh0aCgkSqqb9CKCW3CA9gTL%3DM0Kg%40mail.gmail.com.
