Intent to Ship: TLS Encrypted Client Hello (ECH)

[David Adrian]

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

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?

No

Flag name on chrome://flags

encrypted-client-hello

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1091403

Launch bug

https://crbug.com/1349902

Availability expectation

Feature 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 discussions

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

[David Adrian]

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

[Dennis Jackson]

Exciting news!

Can you update Firefox / Gecko's status to 'Shipped / Shipping' with a link to our intent to ship? Thanks!

[David Adrian]

Updated in Chrome Status.

[Mike Taylor]

On 9/11/23 6:34 PM, 'David Adrian' via blink-dev 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

Could we please request a signal?

https://github.com/WebKit/standards-positions/issues/new/choose

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42KgSdG0D1YT3H8EjXkm4zys4i5A1jskyZcXGbaedGvxHQ%40mail.gmail.com.

[Yoav Weiss]

On Fri, Sep 15, 2023 at 10:05 PM Mike Taylor <mike...@chromium.org> wrote:

On 9/11/23 6:34 PM, 'David Adrian' via blink-dev wrote:

Contact emails

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

Explainer

None

I think a short explainer that outlines what this is and what's the typical flow would be helpful. While that content could've been part of the draft, that doesn't seem to be the case, at least at a glance.

Can you expand on these recovery mechanisms? (maybe as part of the explainer requested above) 

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.

Do we already support the HTTPS record for other purposes? Or would this intent also add HTTPS record support? 

Is this feature fully tested by web-platform-tests?

No

Can you expand on why? Is it due to implementation complexity of network tests in python? 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d066fa66-d356-4be7-99ec-56db593280b0%40chromium.org.

[David Benjamin]

On Sat, Sep 16, 2023 at 1:12 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Fri, Sep 15, 2023 at 10:05 PM Mike Taylor <mike...@chromium.org> wrote:

On 9/11/23 6:34 PM, 'David Adrian' via blink-dev wrote:

Contact emails

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

Explainer

None

I think a short explainer that outlines what this is and what's the typical flow would be helpful. While that content could've been part of the draft, that doesn't seem to be the case, at least at a glance.

This is a process mismatch that comes up for every networking protocol. The expected audiences and also style of spec are very different. Explainers make sense for W3C-style specs where the other consumer of the feature is a web developer who wants to understand how to use the API and not how to implement it step-by-step. The audience for a network protocol is completely different. The other consumer of the feature is a TLS server software implementer, who also needs to understand the full protocol.

When it gets filtered up to web developers and server operators, all they see is how to configure their server software, which is specific to that software. I.e. they would need to refer to their server software documentation.

As for an overview for a non-participant to understand the protocol, section 1 gives an introduction, and section 3 of the draft covers the typical flow. Keep in mind this is not a web platform API, but a TLS extension that lives far, far below the HTTP abstraction, so one should not expect discussion of anything particularly webby. And, as noted above, anything at the level of configuring server software will be server-software-specific, so that also would not make sense here.

See section 3.2 and 6.1.6 of the draft.

Broadly, if the server fails to decrypt the inner ClientHello, it handshakes with the outer one instead and provides replacement keys. That handshake is authenticated against the config's public name, which authenticates the replacement keys and the client retries the connection.

 

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.

Do we already support the HTTPS record for other purposes? Or would this intent also add HTTPS record support? 

We already support the HTTPS record. (That support could be improved, but that's separate from this launch and something for the loading/networking team to work on. This launch is about using ECH keys when we manage to fetch them.)

Is this feature fully tested by web-platform-tests?

No

Can you expand on why? Is it due to implementation complexity of network tests in python? 

web-platform-tests has never been suitable for testing network protocols, especially not TLS extensions. In addition to the limitations caused by Python (not just implementation complexity, it's simply the wrong tool for that job), the infrastructure needed for testing network protocols is completely different, since it's not based on code running under a web page. Like most networking features, ECH is broadly invisible to the web platform itself. It's all behind the HTTP abstraction.

https://github.com/web-platform-tests/wpt/issues/20159

This comes up for every networking protocol launch. Perhaps we need to refine the processes here, so that networking protocol features go through a slightly different template?

[Yoav Weiss]

On Sat, Sep 16, 2023 at 5:35 PM David Benjamin <davi...@chromium.org> wrote:

On Sat, Sep 16, 2023 at 1:12 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Fri, Sep 15, 2023 at 10:05 PM Mike Taylor <mike...@chromium.org> wrote:

On 9/11/23 6:34 PM, 'David Adrian' via blink-dev wrote:

Contact emails

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

Explainer

None

I think a short explainer that outlines what this is and what's the typical flow would be helpful. While that content could've been part of the draft, that doesn't seem to be the case, at least at a glance.

This is a process mismatch that comes up for every networking protocol. The expected audiences and also style of spec are very different. Explainers make sense for W3C-style specs where the other consumer of the feature is a web developer who wants to understand how to use the API and not how to implement it step-by-step. The audience for a network protocol is completely different. The other consumer of the feature is a TLS server software implementer, who also needs to understand the full protocol.

Explainers are not destined only for web developers.

In this particular case, I'd think the audience for this is the API owners (who may or may not have time to read the full I-D), as well as the broader Blink community that keeps tabs on what we're shipping, and may want to understand more about this feature and what it gives them as users. Note that I'm not necessarily asking for a long and complex document - a short explainer that outlines the status quo, what this is changing and how the new flow works would do the trick. 

  

When it gets filtered up to web developers and server operators, all they see is how to configure their server software, which is specific to that software. I.e. they would need to refer to their server software documentation.

As for an overview for a non-participant to understand the protocol, section 1 gives an introduction, and section 3 of the draft covers the typical flow. Keep in mind this is not a web platform API, but a TLS extension that lives far, far below the HTTP abstraction, so one should not expect discussion of anything particularly webby. And, as noted above, anything at the level of configuring server software will be server-software-specific, so that also would not make sense here.

The intro in section 1 is great, but the flow could use a simpler explanation.

Here again, an explainer would've been useful, assuming you don't expect reviewers and interested folks to read through the entire I-D.

 

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.

Do we already support the HTTPS record for other purposes? Or would this intent also add HTTPS record support? 

We already support the HTTPS record. (That support could be improved, but that's separate from this launch and something for the loading/networking team to work on. This launch is about using ECH keys when we manage to fetch them.)

Is this feature fully tested by web-platform-tests?

No

Can you expand on why? Is it due to implementation complexity of network tests in python? 

web-platform-tests has never been suitable for testing network protocols, especially not TLS extensions. In addition to the limitations caused by Python (not just implementation complexity, it's simply the wrong tool for that job), the infrastructure needed for testing network protocols is completely different, since it's not based on code running under a web page. Like most networking features, ECH is broadly invisible to the web platform itself. It's all behind the HTTP abstraction.

https://github.com/web-platform-tests/wpt/issues/20159

This comes up for every networking protocol launch. Perhaps we need to refine the processes here, so that networking protocol features go through a slightly different template?

Alternatively, you could have a generic doc or issue that outlines those issues with WPT and networking tests. Then you could point to it in this section.

[David Benjamin]

The issue is the bug I linked above. In fact, that bug was already listed in chromestatus.com entry. It looks like this is actually a Blink process bug, where chromestatus.com does not fill this field into this section of the email. I've filed https://github.com/GoogleChrome/chromium-dashboard/issues/3335

In the meantime, I guess folks need to remember that the process is buggy and you need to go to the chromestatus entry if you see a "No" here when reviewing.

[David Adrian]

> Could we please request a signal?

Done (and positive!). I had forgotten to add it to Chrome Status. https://github.com/WebKit/standards-positions/issues/46

As for the explainer, between sending the I2S and now, I updated the Chrome Status description to cover most of what David Benjamin discussed, and match what was previously communicated in Chrome release notes. I should have done this before sending the I2S, although I was under the impression that an RFC would be a sufficient explainer. I do understand why it is useful to provide information at a slightly higher and holistic level---I hope the updated description and David Benjamin's comments can stand as that for this Intent.

More broadly, David Benjamin is right that we are effectively jamming a TLS change from the IETF through a process designed for the Web Platform and W3C. We mostly do this so that launches show up in Chrome Status, and organizations who are interested in following TLS changes can see them there.

Now that launches show up in Chrome Status regardless of whether or not they are a Blink launch, we may want to consider no longer sending TLS launches through the Intent process, since they exist outside of the Web Platform, and primarily cause discussion about process confusion (we're trying our best to fit them in!), and not actual impact.

[Daniel Bratell]

We are fine with being flexible with the details when the defaults don't work out, but every field/question has an underlying purpose that we try to satisfy through some means. Sometimes some fields might seem superfluous, but the explainer field is one that is always valuable.

The "explainer" has a couple of different consumers (not quite overlapping but why make it too easy). It serves as a way to introduce non-experts to a feature, it serves as an executive summary of a complicated feature and it serves to fill in some non-technical gaps for web developers, possibly with usage examples. When there is a public announcement of a feature in a certain Chromium version, that is most often based on the explainer, not any specification.

Just as an example of something an explainer might have mentioned is why this involves keys in DNS and if HTTPS depends on DNS, what about DNS over HTTPS? It often say things that are obvious to area experts, but might not be obvious to everyone exposed to this change.

Quite often an explainer can be lifted/extracted from another source, like a previous blog post, or the human friendly part of specification, but it still has to be packaged in non-scary way. You mentioned a release note, maybe that one was all that was needed?

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42JXymYrVqkLD2_-da-FhUVQAS6js1sP9B7ZmrjOC4pnYQ%40mail.gmail.com.

[David Benjamin]

I think this discussion is conflating two different things:

1. Whether some content (sections 1 and 3 of the spec) was extracted into an explainer.

2. Particular questions about the spec that Blink API owners wanted answers for.

With the expectation that, had there been something under an explainer, the questions in (2) would have been automatically answered. But if we wrote an explainer, it would simply have contained sections 1 and 3. As this is a TLS and networking feature, everything is naturally all written from that context, including explainers. The norms and audiences are very different from, say, a JavaScript API. In the same way that a web platform explainer doesn't explain what origins, frames, documents, windows, and the DOM are, yet folks in the TLS community won't necessarily know how webpages are organized. (I can't tell you how many times I've had to explain the implications of subresources in a browser to TLSWG folks!)

That's not to say non-TLS folks can't look at this... we're certainly interested in feedback from you all! But I'd suggest that, if something is unclear to you all, keep in mind the different context and not assume it's just due to the specification formats. Instead, just ask us! To sort out the formalities, I've updated chromestatus.com to just link to sections 1 and 3 of the spec under explainer, but that doesn't do anything to change this fundamental difference in context.

To your example question, ECH is orthogonal[*] to DNS over HTTPS. Since it's orthogonal, I don't think we'd have covered that in the explainer anyway. Rather your question is about how DoH works, independently of ECH. (Even without ECH, HTTPS still depends on DNS!) But I can still answer:

When you visit example.com, you query A, AAAA, and HTTPS-RR records for example.com from your DNS resolver. (Confusingly, the DNS records are also called "HTTPS". I've taken to writing "HTTPS-RR" to disambiguate.) The ECH keys are in HTTPS-RR. Note HTTPS-RR is not specific to ECH and already launched. ECH is just using one more piece of service information from there. If we get any keys, we pass them to TLS, just as the A/AAAA information is passed to TCP setup.

If your DNS resolver happens to be DNS over HTTPS, those queries may themselves require setting up a different HTTPS connection, to different origin. If the DoH origin is specified by IP address, there's no DNS lookup, including no HTTPS-RR lookup and we just don't do ECH for that connection. (DoH or non-DoH, ECH, deployed with keys from DNS, only works for DNS-based origins and not IP-based origins. But there is also less to protect for an IP-based origin.) If the DoH origin is specified by a DNS name, we indeed need a DNS lookup. That is not new with ECH... before ECH, we needed to look up A and AAAA anyway. If that DNS lookup went through DNS over HTTPS, that would indeed be a circular dependency, but nothing to do with ECH. Just DoH. As that's unrelated to this launch, I don't know the exact details, but I believe we just use the system, non-DoH resolver to look up information for the DoH server. If we get ECH keys as part of that, we'll use them, otherwise we won't.

Are there other questions we can help answer?

[*] Or rather, it is mechanically orthogonal. Of course, if you're using cleartext DNS, the server name may be leaked from your DNS queries rather than the ClientHello. Whether or not that's useful will depend a bit on network vantage points, etc. E.g. it could be that our "cleartext" DNS resolver is actually pointing to a localhost caching resolver that, itself, forwards onto DoH outside the browser. Then ECH would be useful. We, from the browser side, can't tell whether that's happening, so it's simplest to just treat it as orthogonal.

[David Adrian]

I'll note that Chrome does not require that the HTTPS RR be resolved over DoH to use ECH, under the argument that some ECH is still better than no ECH. Firefox only uses ECH when they are able to query HTTPS RR records over encrypted DNS.

[David Adrian]

To make it easier for people who are not following the IETF to understand the impact on browsers and Chrome, I have provided a brief explainer: https://github.com/dadrian/ech-chrome

[Yoav Weiss]

LGTM1

On Tue, Sep 26, 2023 at 9:42 PM David Adrian <dad...@google.com> wrote:

To make it easier for people who are not following the IETF to understand the impact on browsers and Chrome, I have provided a brief explainer: https://github.com/dadrian/ech-chrome

Thanks for the explainer. A brief paragraph RE the flow could also be useful. I'll try to PR something shortly.

On Wed, Sep 20, 2023 at 1:48 PM David Adrian <dad...@google.com> wrote:

I'll note that Chrome does not require that the HTTPS RR be resolved over DoH to use ECH, under the argument that some ECH is still better than no ECH. Firefox only uses ECH when they are able to query HTTPS RR records over encrypted DNS.

On Wed, Sep 20, 2023 at 12:54 PM David Benjamin <davi...@chromium.org> wrote:

I think this discussion is conflating two different things:

1. Whether some content (sections 1 and 3 of the spec) was extracted into an explainer.

2. Particular questions about the spec that Blink API owners wanted answers for.

With the expectation that, had there been something under an explainer, the questions in (2) would have been automatically answered. But if we wrote an explainer, it would simply have contained sections 1 and 3. As this is a TLS and networking feature, everything is naturally all written from that context, including explainers. The norms and audiences are very different from, say, a JavaScript API. In the same way that a web platform explainer doesn't explain what origins, frames, documents, windows, and the DOM are, yet folks in the TLS community won't necessarily know how webpages are organized. (I can't tell you how many times I've had to explain the implications of subresources in a browser to TLSWG folks!)

That's not to say non-TLS folks can't look at this... we're certainly interested in feedback from you all! But I'd suggest that, if something is unclear to you all, keep in mind the different context and not assume it's just due to the specification formats. Instead, just ask us! To sort out the formalities, I've updated chromestatus.com to just link to sections 1 and 3 of the spec under explainer, but that doesn't do anything to change this fundamental difference in context.

To your example question, ECH is orthogonal[*] to DNS over HTTPS. Since it's orthogonal, I don't think we'd have covered that in the explainer anyway. Rather your question is about how DoH works, independently of ECH. (Even without ECH, HTTPS still depends on DNS!) But I can still answer:

When you visit example.com, you query A, AAAA, and HTTPS-RR records for example.com from your DNS resolver. (Confusingly, the DNS records are also called "HTTPS". I've taken to writing "HTTPS-RR" to disambiguate.) The ECH keys are in HTTPS-RR. Note HTTPS-RR is not specific to ECH and already launched. ECH is just using one more piece of service information from there. If we get any keys, we pass them to TLS, just as the A/AAAA information is passed to TCP setup.

If your DNS resolver happens to be DNS over HTTPS, those queries may themselves require setting up a different HTTPS connection, to different origin. If the DoH origin is specified by IP address, there's no DNS lookup, including no HTTPS-RR lookup and we just don't do ECH for that connection. (DoH or non-DoH, ECH, deployed with keys from DNS, only works for DNS-based origins and not IP-based origins. But there is also less to protect for an IP-based origin.) If the DoH origin is specified by a DNS name, we indeed need a DNS lookup. That is not new with ECH... before ECH, we needed to look up A and AAAA anyway. If that DNS lookup went through DNS over HTTPS, that would indeed be a circular dependency, but nothing to do with ECH. Just DoH. As that's unrelated to this launch, I don't know the exact details, but I believe we just use the system, non-DoH resolver to look up information for the DoH server. If we get ECH keys as part of that, we'll use them, otherwise we won't.

Are there other questions we can help answer?

[*] Or rather, it is mechanically orthogonal. Of course, if you're using cleartext DNS, the server name may be leaked from your DNS queries rather than the ClientHello. Whether or not that's useful will depend a bit on network vantage points, etc. E.g. it could be that our "cleartext" DNS resolver is actually pointing to a localhost caching resolver that, itself, forwards onto DoH outside the browser. Then ECH would be useful. We, from the browser side, can't tell whether that's happening, so it's simplest to just treat it as orthogonal.

On Wed, Sep 20, 2023 at 12:25 PM Daniel Bratell <brat...@gmail.com> wrote:

We are fine with being flexible with the details when the defaults don't work out, but every field/question has an underlying purpose that we try to satisfy through some means. Sometimes some fields might seem superfluous, but the explainer field is one that is always valuable.

The "explainer" has a couple of different consumers (not quite overlapping but why make it too easy). It serves as a way to introduce non-experts to a feature, it serves as an executive summary of a complicated feature and it serves to fill in some non-technical gaps for web developers, possibly with usage examples. When there is a public announcement of a feature in a certain Chromium version, that is most often based on the explainer, not any specification.

Just as an example of something an explainer might have mentioned is why this involves keys in DNS and if HTTPS depends on DNS, what about DNS over HTTPS? It often say things that are obvious to area experts, but might not be obvious to everyone exposed to this change.

Quite often an explainer can be lifted/extracted from another source, like a previous blog post, or the human friendly part of specification, but it still has to be packaged in non-scary way. You mentioned a release note, maybe that one was all that was needed?

/Daniel

On 2023-09-19 01:04, 'David Adrian' via blink-dev wrote:

> Could we please request a signal?

Done (and positive!). I had forgotten to add it to Chrome Status. https://github.com/WebKit/standards-positions/issues/46

As for the explainer, between sending the I2S and now, I updated the Chrome Status description to cover most of what David Benjamin discussed, and match what was previously communicated in Chrome release notes. I should have done this before sending the I2S, although I was under the impression that an RFC would be a sufficient explainer.

I think specific sections in the RFC could be, when they provide a high-level overview before diving into the details.

 

I do understand why it is useful to provide information at a slightly higher and holistic level---I hope the updated description and David Benjamin's comments can stand as that for this Intent.

More broadly, David Benjamin is right that we are effectively jamming a TLS change from the IETF through a process designed for the Web Platform and W3C. We mostly do this so that launches show up in Chrome Status, and organizations who are interested in following TLS changes can see them there.

Now that launches show up in Chrome Status regardless of whether or not they are a Blink launch, we may want to consider no longer sending TLS launches through the Intent process, since they exist outside of the Web Platform

I think that would be a suboptimal outcome. The Blink process provides transparency and visibility to the changes shipped in Chromium, and I think that network/TLS launches are not different in that respect. I'm more than happy to discuss how we can improve the process to make it less painful to ship TLS-y things through it.

[Daniel Bratell]

LGTM2

Now we just have to keep the IP numbers secret! (joke; though I now start to wonder if there is work going on to make that happen)

/Daniel

[Yoav Weiss]

On Wed, Sep 27, 2023 at 4:50 PM Daniel Bratell <brat...@gmail.com> wrote:

LGTM2

Now we just have to keep the IP numbers secret! (joke; though I now start to wonder if there is work going on to make that happen)

Well, there's https://github.com/GoogleChrome/ip-protection and https://support.apple.com/en-us/102602

[Mike Taylor]

LGTM3