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
On Wed, Sep 20, 2023 at 1:48 PM David Adrian <dadr...@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 <david...@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 <bratel...@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 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. >>> >>> >>> >>> >>> >>> On Mon, Sep 18, 2023 at 9:53 AM David Benjamin <david...@chromium.org> >>> wrote: >>> >>>> On Mon, Sep 18, 2023 at 10:06 AM Yoav Weiss <yoavwe...@chromium.org> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Sat, Sep 16, 2023 at 5:35 PM David Benjamin <david...@chromium.org> >>>>> wrote: >>>>> >>>>>> On Sat, Sep 16, 2023 at 1:12 AM Yoav Weiss <yoavwe...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Sep 15, 2023 at 10:05 PM Mike Taylor <miketa...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> On 9/11/23 6:34 PM, 'David Adrian' via blink-dev wrote: >>>>>>>> >>>>>>>> Contact emails david...@chromium.org, dadr...@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. >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> 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 >>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ESSL> >>>>>>>> >>>>>>>> Search tags ech <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 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 >>>>>>>> >>>>>>>> >>>>>>>> *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. >>>>>>>> >>>>>>>> Can you expand on these recovery mechanisms? (maybe as part of the >>>>>>> explainer requested above) >>>>>>> >>>>>> >>>>>> 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. >>>>>> >>>>> >>>>> 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 >>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>> ? 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. >>>>> >>>> >>>> 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. >>>> >>>> >>>>> 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 >>>>>>>> <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/CAGkh42KgSdG0D1YT3H8EjXkm4zys4i5A1jskyZcXGbaedGvxHQ%40mail.gmail.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42KgSdG0D1YT3H8EjXkm4zys4i5A1jskyZcXGbaedGvxHQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>>> -- >>>>>>>> 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/d066fa66-d356-4be7-99ec-56db593280b0%40chromium.org >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d066fa66-d356-4be7-99ec-56db593280b0%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- >>> 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/CAGkh42JXymYrVqkLD2_-da-FhUVQAS6js1sP9B7ZmrjOC4pnYQ%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42JXymYrVqkLD2_-da-FhUVQAS6js1sP9B7ZmrjOC4pnYQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- 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/CAGkh42%2BeG%2BNk3E_xL2uKO5H5%3DwiFP-4265uJquCqXqvpVEfjhA%40mail.gmail.com.
