Draft: draft-ietf-tls-esni

Commentary: Use the term " plaintext " consistently . Be consistent about the number of spaces following a period . ( We 'll go with one . ) Editorial changes to Sec.1 - 3 .
Paragraph (version A):
Although TLS 1.3 RFC8446 encrypts most of the handshake, including
the server certificate, there are several ways in which an on-path
attacker can learn private information about the connection.  The
cleartext Server Name Indication (SNI) extension in ClientHello
messages, which leaks the target domain for a given connection, is
perhaps the most sensitive information unencrypted in TLS 1.3.
Paragraph (version A):
The target domain may also be visible through other channels, such as
cleartext 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 I-D.ietf-doh-dns-
over-https 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 B):
Although TLS 1.3 RFC8446 encrypts most of the handshake, including
the server certificate, there are several ways in which an on-path
attacker can learn private information about the connection.  The
plaintext Server Name Indication (SNI) extension in ClientHello
messages, which leaks the target domain for a given connection, is
perhaps the most sensitive information unencrypted in TLS 1.3.
Paragraph (version B):
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 I-D.ietf-doh-dns-
over-https 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 WG has extensively studied the problem of protecting the SNI,
Paragraph (version B):
The TLS Working Group has studied the problem of protecting the SNI,
Paragraph (version A):
The design in this document takes a different approach: it assumes
that private origins will co-locate with or hide behind a provider
(CDN, application server, etc.) which can protect SNIs for all of the
domains it hosts.  As a result, SNI protection does not indicate that
the client is attempting to reach a private origin, but only that it
is going to a particular service provider, which the observer could
already tell from the visible IP address.
Paragraph (version A):
The design in this document introduces a new extension, called
Encrypted Client Hello (ECH), which allows clients to encrypt the
entirety of their ClientHello to a supporting server.  This protects
the SNI and other potentially sensitive fields, such as the ALPN
list.  This extension is only supported with (D)TLS 1.3 RFC8446 and
newer versions of the protocol.
Paragraph (version B):
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 SNIs
for all of the domains it hosts.  As a result, SNI protection does
not indicate that the client is attempting to reach a private origin,
but only that it is going to a particular service provider, which the
observer could already tell from the visible IP address.
Paragraph (version B):
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 A):
In Shared Mode, the provider is the origin server for all the domains
whose DNS records point to it and clients form a TLS connection
directly to that provider, which has access to the plaintext of the
connection.
Paragraph (version A):
In Split Mode, the provider is _not_ the origin server for private
domains.  Rather the DNS records for private domains point to the
provider, and the provider's server relays the connection back to the
backend server, which is the true origin server.  The provider does
not have access to the plaintext of the connection.
Paragraph (version A):
ECH works by encrypting the entire ClientHello, including the SNI and
any additional extensions such as ALPN.  This requires that each
provider publish a public key and metadata which is used for
ClientHello encryption for all the domains for which it serves
directly or indirectly (via Split Mode).  This document defines the
format of the SNI encryption public key and metadata, referred to as
an ECH configuration, and delegates DNS publication details to HTTPS-
RR, though other delivery mechanisms are possible.  In particular, if
some of the clients of a private server are applications rather than
Web browsers, those applications might have the public key and
metadata preconfigured.
Paragraph (version A):
When a client wants to form a TLS connection to any of the domains
served by an ECH-supporting provider, it constructs a ClientHello in
the regular fashion containing the true SNI value (ClientHelloInner)
and then encrypts it using the public key for the provider.  It then
constructs a new ClientHello (ClientHelloOuter) with an innocuous SNI
(and potentially innocuous versions of other extensions such as ALPN
RFC7301) and containing the encrypted ClientHelloInner as an
extension.  It sends ClientHelloOuter to the server.
Paragraph (version A):
Upon receiving ClientHelloOuter, the server can then decrypt
ClientHelloInner and either terminate the connection (in Shared Mode)
or forward it to the backend server (in Split Mode).
Paragraph (version A):
Note that both ClientHelloInner and ClientHelloOuter are both valid,
complete ClientHello messages.  ClientHelloOuter carries an encrypted
representation of ClientHelloInner in a "encrypted_client_hello"
extension, defined in encrypted-client-hello.
Paragraph (version B):
This protocol is designed to operate in one of two topologies
illustrated below, which we call "Shared Mode" and "Split Mode".
Paragraph (version B):
In Shared Mode, the provider is the origin server for all the domains
whose DNS records point to it.  In this mode, the TLS connection is
terminated by the provider.
Paragraph (version B):
In Split Mode, the provider is not the origin server for private
domains.  Rather, the DNS records for private domains point to the
provider, and the provider's server relays the connection back to the
origin server, who terminates the TLS connection with the client.
Importantly, service provider does not have access to the plaintext
of the connection.
Paragraph (version B):
In the remainder of this document, we will refer to the ECH-service
provider as the "client-facing server" and to the TLS terminator as
the "backend server".  These are the same entity in Shared Mode, but
in Split Mode, the client-facing and backend servers are physically
separated.
Paragraph (version B):
ECH allows the client to encrypt sensitive ClientHello extensions,
e.g., SNI, ALPN, etc., under the public key of the client-facing
server.  This requires the client-facing server to publish the public
key and metadata it uses for ECH for all the domains for which it
serves directly or indirectly (via Split Mode).  This document
defines the format of the ECH encryption public key and metadata,
referred to as an ECH configuration, and delegates DNS publication
details to HTTPS-RR, though other delivery mechanisms are possible.
In particular, if some of the clients of a private server are
applications rather than Web browsers, those applications might have
the public key and metadata preconfigured.
Paragraph (version B):
When a client wants to establish a TLS session with the backend
server, it constructs its ClientHello as usual (we will refer to this
as the ClientHelloInner message) and then encrypts this message using
the ECH public key.  It then constructs a new ClientHello
(ClientHelloOuter) with innocuous values for sensitive extensions,
e.g., SNI, ALPN, etc., and with the encrypted ClientHelloInner in an
"encrypted_client_hello" extension, which this document defines
(encrypted-client-hello).  Finally, it sends ClientHelloOuter to the
server.
Paragraph (version B):
Upon receiving ClientHelloOuter, the client-facing server processes
the encrypted ClientHelloInner and either terminates the connection
(in Shared Mode) or forwards it to the backend server (in Split
Mode).
Paragraph (version A):
The server MUST ignore all PSK identities in the ClientHello which
correspond to ECH PSKs.  ECH PSKs offered by the client are
associated with the ECH name.  The server was unable to decrypt
then ECH name, so it should not resume them when using the
cleartext SNI name.  This restriction allows a client to reject
resumptions in auth-public-name.
Paragraph (version B):
The server MUST ignore all PSK identities in the ClientHello which
correspond to ECH PSKs.  ECH PSKs offered by the client are
associated with the ECH name.  The server was unable to decrypt
then ECH name, so it should not resume them when using the
plaintext SNI name.  This restriction allows a client to reject
resumptions in auth-public-name.
Paragraph (version A):
Assuming ECH records retrieved from DNS are authenticated, e.g., via
DNSSEC or fetched from a trusted Recursive Resolver, spoofing a
server operating in Split Mode is not possible.  See cleartext-dns
for more details regarding cleartext DNS.
Paragraph (version B):
Assuming ECH records retrieved from DNS are authenticated, e.g., via
DNSSEC or fetched from a trusted Recursive Resolver, spoofing a
server operating in Split Mode is not possible.  See plaintext-dns
for more details regarding plaintext DNS.