Draft: draft-ietf-tls-esni

Commentary: It is rather long . I 've taken a pass at making it read a little clearer , hopefully . I 've tried to preserve the bits of the old text that seemed important . Hopefully other folks agree . This still could use another editing pass ( e.g. the first and second paragraphs both conclude with the same thing ) , but I think it 's an improvement . I 've dropped the paragraph about about how the TLSWG has studied the problem but had difficulties . That seemed more relevant when we were comparing this approach against others . The following paragraph then describes the setup ( colocated servers ) and what the extension achieves ( stuff about anonymity sets ) . That s redundant with the text above talking about how sometimes the server IP is n't identifying , and the text below talking about what the extension does . I 've worked that text into those two paragraphs . I tweaked the bit about consistent TLS configuration , since it 's not actually true : it 's fine if the servers do n't support the same ALPN protocols . It 's just a few externally - visible bits of TLS configuration . That 's probably worth defining more accurately , if we have n't already ( I forget ) , but not in the introduction . I 've also dropped the claim that we leak no more than the server IP . We have n't addressed padding of application data , and cases where the colocated servers have sufficiently different TLS configuration are out of scope . I tried to general tightened up language . For instance there was a paragraph that says " ( assuming the server does not use domain - based virtual hosting ) " and then goes straight to talk about servers that do use virtual hosting .
Paragraph (version A):
The target domain may also be visible through other channels, such as
plaintext client DNS queries, visible server IP addresses (assuming
the server does not use domain-based virtual hosting), or other
indirect mechanisms such as traffic analysis.  DoH RFC8484 and DPRIVE
RFC7858 RFC8094 provide mechanisms for clients to conceal DNS lookups
from network inspection, and many TLS servers host multiple domains
on the same IP address.  In such environments, the SNI remains the
primary explicit signal used to determine the server's identity.
Paragraph (version A):
The TLS Working Group has studied the problem of protecting the SNI,
but has been unable to develop a completely generic solution.
RFC8744 provides a description of the problem space and some of the
proposed techniques.  One of the more difficult problems is "Do not
stick out" (RFC8744, Section 3.4): if only sensitive or private
services use SNI encryption, then SNI encryption is a signal that a
client is going to such a service.  For this reason, much recent work
has focused on concealing the fact that the SNI is being protected.
Unfortunately, the result often has undesirable performance
consequences, incomplete coverage, or both.
Paragraph (version A):
The protocol specified by this document takes a different approach.
It assumes that private origins will co-locate with or hide behind a
provider (reverse proxy, application server, etc.) that protects
sensitive ClientHello parameters, including the SNI, for all of the
domains it hosts.  These co-located servers form an anonymity set
wherein all elements have a consistent configuration, e.g., the set
of supported application protocols, ciphersuites, TLS versions, and
so on.  Usage of this mechanism reveals that a client is connecting
to a particular service provider, but does not reveal which server
from the anonymity set terminates the connection.  Thus, it leaks no
more than what is already visible from the server IP address.
Paragraph (version A):
This document specifies a new TLS extension, called Encrypted Client
Hello (ECH), that allows clients to encrypt their ClientHello to a
supporting server.  This protects the SNI and other potentially
sensitive fields, such as the ALPN list RFC7301.  This extension is
only supported with (D)TLS 1.3 RFC8446 and newer versions of the
protocol.
Paragraph (version B):
The target domain may also be visible through other channels, such as
plaintext client DNS queries or visible server IP addresses.
However, DoH RFC8484 and DPRIVE RFC7858 RFC8094 provide mechanisms
for clients to conceal DNS lookups from network inspection, and many
TLS servers host multiple domains on the same IP address.  Private
origins may also be deployed behind a common provider, such as a
reverse proxy.  In such environments, the SNI remains the primary
explicit signal used to determine the server's identity.
Paragraph (version B):
This document specifies a new TLS extension, called Encrypted Client
Hello (ECH), that allows clients to encrypt their ClientHello to such
a deployment.  This protects the SNI and other potentially sensitive
fields, such as the ALPN list RFC7301.  Co-located servers with
consistent externally visible TLS configurations, including supported
versions and cipher suites, form an anonymity set.  Usage of this
mechanism reveals that a client is connecting to a particular service
provider, but does not reveal which server from the anonymity set
terminates the connection.
Paragraph (version B):
ECH is only supported with (D)TLS 1.3 RFC8446 and newer versions of
the protocol.