Draft: draft-ietf-tls-esni

Commentary: Because this document now delegates the way the keys are advertised from the RRType ESNI to HTTPSSVC should n't the RRType Considerations be removed from this document .
Paragraph (version B):
When operating in Split Mode, backend servers will not have access to
PaddedServerNameList.sni or ClientESNIInner.nonce without access to
the ESNI keys or a way to decrypt ClientEncryptedSNI.encrypted_sni.
Paragraph (version B):
One way to address this for a single connection, at the cost of
having communication not be unmodified TLS 1.3, is as follows.
Assume there is a shared (symmetric) key between the client-facing
server and the backend server and use it to AEAD-encrypt Z and send
the encrypted blob at the beginning of the connection before the
ClientHello.  The backend server can then decrypt ESNI to recover the
true SNI and nonce.
Paragraph (version B):
Alternative approaches to encrypted SNI may be implemented at the TLS
or application layer.  In this section we describe several
alternatives and discuss drawbacks in comparison to the design in
this document.
Paragraph (version B):
In this variant, TLS Client Hellos are tunneled within early data
payloads belonging to outer TLS connections established with the
client-facing server.  This requires clients to have established a
previous session --- and obtained PSKs --- with the server.  The
client-facing server decrypts early data payloads to uncover Client
Hellos destined for the backend server, and forwards them onwards as
necessary.  Afterwards, all records to and from backend servers are
forwarded by the client-facing server - unmodified.  This avoids
double encryption of TLS records.
Paragraph (version B):
Problems with this approach are: (1) servers may not always be able
to distinguish inner Client Hellos from legitimate application data,
(2) nested 0-RTT data may not function correctly, (3) 0-RTT data may
not be supported - especially under DoS - leading to availability
concerns, and (4) clients must bootstrap tunnels (sessions), costing
an additional round trip and potentially revealing the SNI during the
initial connection.  In contrast, encrypted SNI protects the SNI in a
distinct Client Hello extension and neither abuses early data nor
requires a bootstrapping connection.
Paragraph (version B):
In this variant, client-facing and backend servers coordinate to
produce "combined tickets" that are consumable by both.  Clients
offer combined tickets to client-facing servers.  The latter parse
them to determine the correct backend server to which the Client
Hello should be forwarded.  This approach is problematic due to non-
trivial coordination between client-facing and backend servers for
ticket construction and consumption.  Moreover, it requires a
bootstrapping step similar to that of the previous variant.  In
contrast, encrypted SNI requires no such coordination.
Paragraph (version B):
In this variant, clients request secondary certificates with
CERTIFICATE_REQUEST HTTP/2 frames after TLS connection completion.
In response, servers supply certificates via TLS exported
authenticators I-D.ietf-tls-exported-authenticator in CERTIFICATE
frames.  Clients use a generic SNI for the underlying client-facing
server TLS connection.  Problems with this approach include: (1) one
additional round trip before peer authentication, (2) non-trivial
application-layer dependencies and interaction, and (3) obtaining the
generic SNI to bootstrap the connection.  In contrast, encrypted SNI
induces no additional round trip and operates below the application
layer.
Paragraph (version B):
If the encrypted block has its own KeyShare, it does not
necessarily require the client to use a single KeyShare, because
the client's share is bound to the SNI by the AEAD (analysis
needed).
Paragraph (version B):
The client-facing server can still see the other extensions.  By
contrast we could introduce another EncryptedExtensions block that
was encrypted to the backend server and not the client-facing
server.
Paragraph (version B):
It requires a mechanism for the client-facing server to provide
the extension-encryption key to the backend server (as in
communicating-sni and thus cannot be used with an unmodified
backend server.