Intent to Experiment: TLS Encrypted Client Hello (ECH)

[David Benjamin]

Contact emails

davi...@chromium.org, dad...@google.com

Explainer

None

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 component

Internals>Network>SSL

Search tags

ech, esni, tls, ssl

TAG review

Not applicable; this is a protocol under IETF

TAG review status

Not 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

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?

No (see https://github.com/web-platform-tests/wpt/issues/20159)

Flag name

encrypted-client-hello

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1091403

Launch bug

https://crbug.com/1349902

Estimated milestones

DevTrial on desktop

105

DevTrial on Android

105

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6196703843581952

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/YEo4LqB7nWI

This intent message was generated by Chrome Platform Status.

[Mike West]

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 emails

davi...@chromium.org, dad...@google.com

Explainer

None

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 component

Internals>Network>SSL

Search tags

ech, esni, tls, ssl

TAG review

Not applicable; this is a protocol under IETF

TAG review status

Not 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.

When do you plan to end the experiment? M109, perhaps?

[David Benjamin]

(Sorry for the late reply. Was out sick for a bit.)

Filed https://github.com/WebKit/standards-positions/issues/46

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.)

[Mike West]

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

[David Adrian]

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.

[David Adrian]

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.

[Achiel van der Mandele]

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

--
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+...@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.

[David Adrian]

We are ramping ECH up to 10% of Stable Channel.

We will send an Intent-to-Ship if the rollout continues successfully.