Draft: draft-rescorla-tls-esni

Commentary: PTAL ! I tried Transparent mode , though this seemed subjectively better at the time . I 'm happy to be convinced otherwise . 
 Domain fronting already has a bad rap . Perhaps we should give this a new name to avoid pushback ? 
 Agree , Maybe " Transparent " mode ? " Proxy " mode ? 
 I 'm going to go a step farther and suggest only defining shared mode in this document . it brings esni to the masses and eliminates the need for special tech to acheive classic fronting . That 's a significant net - win without being weighed down by bias about fronting - I think we 'll get more participation that way because the set of goals is easier to achieve consensus on ( privacy is good ! ) If folks need a separate document later to figure out they can tunnel based on the decrypted SNI then istm it can be separable .. true ? 
 My reservation there is that , with only   , a better design is probably to encrypt all of the extensions , and not just the SNI . With that change , it then later becomes infeasible to accomplish the front / hidden split . 
 Closing via . if we want to keep only   , let 's use a new issue to track that .
Paragraph (version A):
In Fronting 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 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 A):
First, the provider publishes a public key which is used for SNI
encryption for all the domains which it serves or fronts for.  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 hidden 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 Fronting 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 hidden server (in Split Mode).
Paragraph (version A):
The length to pad the ServerNameList value to prior to encryption.
This value SHOULD be set to the largest ServerNameList the
fronting server expects to support rounded up the nearest multiple
of 16.
Paragraph (version B):
The length to pad the ServerNameList value to prior to encryption.
This value SHOULD be set to the largest ServerNameList the server
expects to support rounded up the nearest multiple of 16.
Paragraph (version A):
Alt-Svc records may be used to inform the client of the plaintext
(fronting) SNI.  If present, clients SHOULD use its value in the SNI
extension of the subsequent ClientHello.
Paragraph (version A):
Clients obtain these records by querying DNS for hidden server
domains.  Thus, servers operating in Fronting 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
fronting server.  Thus, even with SNI encryption, an attacker which
can enumerate the set of hidden server domains supported by a
fronting 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):
Alt-Svc records may be used to inform the client of the plaintext
(client-facing) SNI.  If present, clients SHOULD use its value in the
SNI extension of the subsequent ClientHello.
Paragraph (version B):
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 A):
Upon determining the true SNI, the fronting 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 Fronting Mode).
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 hidden server (if in Split Mode).
Paragraph (version A):
The handshake will fail if the fronting server requires SNI.
Paragraph (version A):
The handshake will succeed with the fronting server's default
certificate.
Paragraph (version B):
The handshake will fail if the client-facing server requires SNI.
Paragraph (version B):
The handshake will succeed with the client-facing server's default
certificate.
Paragraph (version A):
In order to enable this mechanism, fronting servers SHOULD NOT
require SNI, but rather respond with some default certificate.
Paragraph (version B):
In order to enable this mechanism, client-facing servers SHOULD NOT
require SNI, but rather respond with some default certificate.
Paragraph (version A):
This design permits servers operating in Fronting 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 hidden origin servers, thereby avoiding
unnecessary MiTM attacks.
Paragraph (version A):
Assuming ESNIKeys retrieved from DNS are validated, e.g., via DNSSEC
or fetched from a trusted Recursive Resolver, spoofing a server
operating in Fronting Mode is not possible.  See cleartext-dns for
more details regarding cleartext DNS.
Paragraph (version B):
Assuming ESNIKeys retrieved from DNS are validated, 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.