Draft: draft-rescorla-tls-esni

Commentary: I decided " hidden " was bad . 
 +1 to the change . I think that this is the right direction .
Paragraph (version A):
The TLS WG has extensively studied the problem of protecting SNI, but
has been unable to develop a completely generic solution.  I-D.ietf-
tls-sni-encryption provides a description of the problem space and
some of the proposed techniques.  One of the more difficult problems
is "Do not stick out" (I-D.ietf-tls-sni-encryption; Section 2.4): if
only hidden services use SNI encryption, then SNI encryption is a
signal that a client is going to a hidden server.  For this reason,
much recent work has focused on concealing the fact that SNI is being
protected.  Unfortunately, the result often has undesirable
performance consequences, incomplete coverage, or both.
Paragraph (version A):
The design in this document takes a different approach: it assumes
that hidden servers will hide behind a provider (CDN, app server,
etc.) which is able to activate encrypted SNI (ESNI) for all of the
domains it hosts.  Thus, the use of encrypted SNI does not indicate
that the client is attempting to reach a hidden server, but only that
it is going to a particular service provider, which the observer
could already tell from the IP address.
Paragraph (version B):
The TLS WG has extensively studied the problem of protecting SNI, but
has been unable to develop a completely generic solution.  I-D.ietf-
tls-sni-encryption provides a description of the problem space and
some of the proposed techniques.  One of the more difficult problems
is "Do not stick out" (I-D.ietf-tls-sni-encryption; Section 2.4): if
only sensitive/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
SNI is being protected.  Unfortunately, the result often has
undesirable performance consequences, incomplete coverage, or both.
Paragraph (version B):
The design in this document takes a different approach: it assumes
that private origins will co-locate with or hide behind a provider
(CDN, app server, etc.) which is able to activate encrypted SNI
(ESNI) for all of the domains it hosts.  Thus, the use of encrypted
SNI 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 IP address.
Paragraph (version A):
In Split Mode, the provider is _not_ the origin server for hidden
domains.  Rather the DNS records for hidden domains point to the
provider, but the provider's server just relays the connection back
to the hidden server, which is the true origin server.  The provider
does not have access to the plaintext of the connection.  In
principle, the provider might not be the origin for any domains, but
as a practical matter, it is probably the origin for a large set of
innocuous domains, but is also providing protection for some hidden
domains.  Note that the hidden server can be an unmodified TLS 1.3
server.
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, but the provider's server just 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.  In
principle, the provider might not be the origin for any domains, but
as a practical matter, it is probably the origin for a large set of
innocuous domains, but is also providing protection for some private
domains.  Note that the backend server can be an unmodified TLS 1.3
server.
Paragraph (version A):
First, the provider publishes a public key which is used for SNI
encryption for all the domains for which it serves directly or
indirectly (via Split mode).  This document defines a publication
mechanism using DNS, but other mechanisms are also possible.  In
particular, if some of the clients of a hidden server are
applications rather than Web browsers, those applications might have
the public key preconfigured.
Paragraph (version B):
First, the provider publishes a public key which is used for SNI
encryption for all the domains for which it serves directly or
indirectly (via Split mode).  This document defines a publication
mechanism using DNS, but other mechanisms are also 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 preconfigured.
Paragraph (version A):
When a client wants to form a TLS connection to any of the domains
served by an ESNI-supporting provider, it replaces the "server_name"
extension in the ClientHello with an "encrypted_server_name"
extension, which contains the true extension encrypted under the
provider's public key.  The provider can then decrypt the extension
and either terminate the connection (in Shared Mode) or forward it to
the hidden server (in Split Mode).
Paragraph (version B):
When a client wants to form a TLS connection to any of the domains
served by an ESNI-supporting provider, it replaces the "server_name"
extension in the ClientHello with an "encrypted_server_name"
extension, which contains the true extension encrypted under the
provider's public key.  The provider can then decrypt the extension
and either terminate the connection (in Shared Mode) or forward it to
the backend server (in Split Mode).
Paragraph (version A):
Clients obtain these records by querying DNS for hidden server
domains.  Thus, servers operating in Split Mode SHOULD have DNS
configured to return the same A (or AAAA) record for all hidden
servers they service.  This yields an anonymity set of cardinality
equal to the number of hidden server domains supported by a given
client-facing server.  Thus, even with SNI encryption, an attacker
which can enumerate the set of hidden server domains supported by a
client-facing server can guess the correct SNI with probability at
least 1/K, where K is the size of this hidden server anonymity set.
This probability may be increased via traffic analysis or other
mechanisms.
Paragraph (version B):
Clients obtain these records by querying DNS for ESNI-enabled server
domains.  Thus, servers operating in Split Mode SHOULD have DNS
configured to return the same A (or AAAA) record for all ESNI-enabled
servers they service.  This yields an anonymity set of cardinality
equal to the number of ESNI-enabled server domains supported by a
given client-facing server.  Thus, even with SNI encryption, an
attacker which can enumerate the set of ESNI-enabled domains
supported by a client-facing server can guess the correct SNI with
probability at least 1/K, where K is the size of this ESNI-enabled
server anonymity set.  This probability may be increased via traffic
analysis or other mechanisms.
Paragraph (version A):
Upon determining the true SNI, the client-facing server then either
serves the connection directly (if in Shared Mode), in which case it
executes the steps in the following section, or forwards the TLS
connection to the hidden server (if in Split Mode).  In the latter
case, it does not make any changes to the TLS messages, but just
blindly forwards them.
Paragraph (version B):
Upon determining the true SNI, the client-facing server then either
serves the connection directly (if in Shared Mode), in which case it
executes the steps in the following section, or forwards the TLS
connection to the backend server (if in Split Mode).  In the latter
case, it does not make any changes to the TLS messages, but just
blindly forwards them.
Paragraph (version A):
The Hidden Server ignores both the "encrypted_server_name" and the
"server_name" (if any) and completes the handshake as usual.  If in
Shared Mode, the server will still know the true SNI, and can use it
for certificate selection.  In Split Mode, it may not know the true
SNI and so will generally be configured to use a single certificate.
communicating-sni describes a mechanism for communicating the true
SNI to the hidden server.
Paragraph (version A):
Similar to the Shared Mode behavior, the hidden server in Split Mode
SHOULD pad the Certificate message, via padding at the record layer
such that its length equals the size of the largest possible
Certificate (message) covered by the same ESNI key.
Paragraph (version B):
The backend Server ignores both the "encrypted_server_name" and the
"server_name" (if any) and completes the handshake as usual.  If in
Shared Mode, the server will still know the true SNI, and can use it
for certificate selection.  In Split Mode, it may not know the true
SNI and so will generally be configured to use a single certificate.
communicating-sni describes a mechanism for communicating the true
SNI to the backend server.
Paragraph (version B):
Similar to the Shared Mode behavior, the backend server in Split Mode
SHOULD pad the Certificate message, via padding at the record layer
such that its length equals the size of the largest possible
Certificate (message) covered by the same ESNI key.
Paragraph (version A):
This design permits servers operating in Split Mode to forward
connections directly to hidden origin servers, thereby avoiding
unnecessary MiTM attacks.
Paragraph (version B):
This design permits servers operating in Split Mode to forward
connections directly to backend origin servers, thereby avoiding
unnecessary MiTM attacks.
Paragraph (version A):
Note that the hidden server has no way of knowing what the SNI was,
but that does not lead to additional privacy exposure because the
hidden server also only has one identity.  This does, however, change
the situation slightly in that the hidden server might previously
have checked SNI and now cannot (and an attacker can route a
connection with an encrypted SNI to any hidden server and the TLS
connection will still complete).  However, the client is still
responsible for verifying the server's identity in its certificate.
Paragraph (version B):
Note that the backend server has no way of knowing what the SNI was,
but that does not lead to additional privacy exposure because the
backend server also only has one identity.  This does, however,
change the situation slightly in that the backend server might
previously have checked SNI and now cannot (and an attacker can route
a connection with an encrypted SNI to any backend server and the TLS
connection will still complete).  However, the client is still
responsible for verifying the server's identity in its certificate.