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