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/CAF8qwaBXoBLSj-iB-QAuyy41L39byuwP2FCMfBoaNo3eFdB4Ug%40mail.gmail.com.
