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. > > *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? > > > 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/31097519-0b4e-4468-8caa-640e818208fan%40chromium.org.
