Exciting news! Can you update Firefox / Gecko's status to 'Shipped / Shipping' with a link to our intent to ship <https://groups.google.com/a/mozilla.org/g/dev-platform/c/uv7PNrHUagA/m/BNA4G8fOAAAJ>? Thanks!
On Monday, September 11, 2023 at 5:41:38 PM UTC+1 dad...@google.com wrote: > ECH has been at 10% stable since 2023-08-31, and at 1% stable from Chrome > 115. General metric impact is negligible. The spurious regressions at 1% > appear to have gone away at 10%. The ECH "origin trial" was managed by > Finch, since the TLS stack completes before the web stack is available. ECH > use is dependent on servers opting in. > > We're requesting approval to ship to 100%, now that the origin trial has > completed (115 - 116, inclusive). > > On Mon, Sep 11, 2023 at 10:34 AM David Adrian <dad...@google.com> 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 >> >> *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 >> >> >> 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. >> >> >> 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://flagsencrypted-client-hello >> >> Finch feature nameNone >> >> Non-finch justificationNone >> >> Requires code in //chrome?False >> >> Tracking bughttps://crbug.com/1091403 >> >> Launch bughttps://crbug.com/1349902 >> >> Availability expectationFeature is also being launched in Firefox. >> >> Sample links >> https://tls-ech.dev >> >> Estimated milestones >> Shipping on desktop 117 >> OriginTrial desktop last 116 >> OriginTrial desktop first 115 >> DevTrial on desktop 105 >> Shipping on Android 117 >> OriginTrial Android last 116 >> OriginTrial Android first 115 >> DevTrial on Android 105 >> >> Anticipated spec changes >> >> Open questions about a feature may be a source of future web compat or >> interop issues. Please list open issues (e.g. links to known github issues >> in the project for the feature specification) whose resolution may >> introduce web compat/interop risk (e.g., changing to naming or structure of >> the API in a non-backward-compatible way). >> n/a >> >> 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 >> >> Intent to Experiment: >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaB488g2%3D1WdmFPnWaAYaXB2pXaVv0-Xe-XXqYFRi5y20A%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/b223a2fe-0cc8-4e1d-a413-cb5a2cb246a1n%40chromium.org.
