Updated in Chrome Status <https://chromestatus.com/feature/6196703843581952> .
On Monday, September 11, 2023 at 10:53:13 AM UTC-6 djac...@mozilla.com wrote: > 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/54d2ebc6-37b8-4610-b50a-b0279364f9f4n%40chromium.org.
