> 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 <[email protected]>
wrote:
On Mon, Sep 18, 2023 at 10:06 AM Yoav Weiss
<[email protected]> wrote:
On Sat, Sep 16, 2023 at 5:35 PM David Benjamin
<[email protected]> wrote:
On Sat, Sep 16, 2023 at 1:12 AM Yoav Weiss
<[email protected]> wrote:
On Fri, Sep 15, 2023 at 10:05 PM Mike Taylor
<[email protected]> wrote:
On 9/11/23 6:34 PM, 'David Adrian' via blink-dev
wrote:
Contact emails
[email protected], [email protected]
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 <http://chromestatus.com> entry. It
looks like this is actually a Blink process bug, where
chromestatus.com <http://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
[email protected].
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
[email protected].
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 [email protected].
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>.
