Draft: draft-ietf-tls-esni

Commentary: This builds on , but removes the probabilistic pieces . I created a fresh PR to make review easier . cc 
 LGTM
Paragraph (version B):
The largest name the server expects to support, if known.  If this
value is not known it can be set to zero, in which case clients
SHOULD use the inner ClientHello padding scheme described below.
That could happen if wildcard names are in use, or if names can be
added or removed from the anonymity set during the lifetime of a
particular resource record value.
Paragraph (version A):
An ESNIConfigs structure containing one or more ECHOConfig
structures in decreasing order of preference that the client
should use on subsequent connections to encrypt the
ClientHelloInner structure.
Paragraph (version A):
This protocol also defines the "echo_required" alert, which is sent
by the client when it offered an "encrypted_server_name" extension
which was not accepted by the server.
Paragraph (version B):
An ECHOConfigs structure containing one or more ECHOConfig
structures in decreasing order of preference that the client
should use on subsequent connections to encrypt the
ClientHelloInner structure.
Paragraph (version B):
This protocol also defines the "echo_required" alert, which is sent
by the client when it offered an "encrypted_client_hello" extension
which was not accepted by the server.
Paragraph (version A):
The client MUST place the value of ECHOConfig.public_name in the
ClientHelloOuter "server_name" extension.  The remaining contents of
the ClientHelloOuter MAY be identical to those in ClientHelloInner
but MAY also differ.  The ClientHelloOuter MUST NOT contain a
"cached_info" extension RFC7924 with a CachedObject entry whose
CachedInformationType is "cert", since this indication would divulge
the true server name.
Paragraph (version B):
The client MUST place the value of ECHOConfig.public_name in the
ClientHelloOuter "server_name" extension.  The ClientHelloOuter MUST
NOT contain a "cached_info" extension RFC7924 with a CachedObject
entry whose CachedInformationType is "cert", since this indication
would divulge the true server name.  The remaining contents of the
ClientHelloOuter MAY be identical to those in ClientHelloInner but
MAY also differ.
Paragraph (version B):
This section describes a deterministic padding mechanism based on the
following observation: individual extensions can reveal sensitive
information through their length.  Thus, each extension in the inner
ClientHello may require different amounts of padding.  This padding
may be fully determined by the client's configuration or may require
server input.
Paragraph (version B):
By way of example, clients typically support a small number of
application profiles.  For instance, a browser might support HTTP
with ALPN values ["http/1.1, "h2"] and WebRTC media with ALPNs
["webrtc", "c-webrtc"].  Clients SHOULD pad this extension by
rounding up to the total size of the longest ALPN extension across
all application profiles.  The target padding length of most
ClientHello extensions can be computed in this way.
Paragraph (version B):
If L > D, add L - D bytes of padding.  This rounds to the server's
advertised hint, i.e., ECHOConfig.maximum_name_length.
Paragraph (version B):
Otherwise, add 32 - (D % 32) bytes of padding.  This rounds D up
to the nearest multiple of 32 bytes.
Paragraph (version B):
In addition to padding ClientHelloInner, clients and servers will
also need to pad all other handshake messages that have sensitive-
length fields.  For example, if a client proposes ALPN values in
ClientHelloInner, the server-selected value will be returned in an
EncryptedExtension, so that handshake message also needs to be padded
using TLS record layer padding.
Paragraph (version A):
Otherwise, when the handshake completes successfully with the public
name authenticated, the client MUST abort the connection with an
"echo_required" alert.  It then processes the "retry_keys" field from
the server's "encrypted_server_name" extension.
Paragraph (version B):
Otherwise, when the handshake completes successfully with the public
name authenticated, the client MUST abort the connection with an
"echo_required" alert.  It then processes the "retry_keys" field from
the server's "encrypted_client_hello" extension.
Paragraph (version A):
If the server negotiates an earlier version of TLS, or if it does not
provide an "encrypted_server_name" extension in EncryptedExtensions,
the client proceeds with the handshake, authenticating for
ECHOConfigContents.public_name as described in auth-public-name.  If
an earlier version was negotiated, the client MUST NOT enable the
False Start optimization RFC7918 for this handshake.  If
authentication or the handshake fails, the client MUST return a
failure to the calling application.  It MUST NOT treat this as a
secure signal to disable ECHO.
Paragraph (version B):
If the server negotiates an earlier version of TLS, or if it does not
provide an "encrypted_client_hello" extension in EncryptedExtensions,
the client proceeds with the handshake, authenticating for
ECHOConfigContents.public_name as described in auth-public-name.  If
an earlier version was negotiated, the client MUST NOT enable the
False Start optimization RFC7918 for this handshake.  If
authentication or the handshake fails, the client MUST return a
failure to the calling application.  It MUST NOT treat this as a
secure signal to disable ECHO.
Paragraph (version A):
Clients SHOULD implement a limit on retries caused by
"echo_retry_request" or servers which do not acknowledge the
"encrypted_server_name" extension.  If the client does not retry in
either scenario, it MUST report an error to the calling application.
Paragraph (version B):
Clients SHOULD implement a limit on retries caused by
"echo_retry_request" or servers which do not acknowledge the
"encrypted_client_hello" extension.  If the client does not retry in
either scenario, it MUST report an error to the calling application.
Paragraph (version B):
Set the "suite" field to a supported cipher suite.  The selection
SHOULD vary to exercise all supported configurations, but MAY be
held constant for successive connections to the same server in the
same session.
Paragraph (version A):
The retry mechanism repairs inconsistencies, provided the server is
authoritative for the public name.  If server and advertised keys
mismatch, the server will respond with echo_retry_requested.  If the
server does not understand the "encrypted_server_name" extension at
all, it will ignore it as required by RFC8446; Section 4.1.2.
Provided the server can present a certificate valid for the public
name, the client can safely retry with updated settings, as described
in handle-server-response.
Paragraph (version B):
The retry mechanism repairs inconsistencies, provided the server is
authoritative for the public name.  If server and advertised keys
mismatch, the server will respond with echo_retry_requested.  If the
server does not understand the "encrypted_client_hello" extension at
all, it will ignore it as required by RFC8446; Section 4.1.2.
Provided the server can present a certificate valid for the public
name, the client can safely retry with updated settings, as described
in handle-server-response.
Paragraph (version A):
A more serious problem is MITM proxies which do not support this
extension.  RFC8446; Section 9.3 requires that such proxies remove
any extensions they do not understand.  The handshake will then
present a certificate based on the public name, without echoing the
"encrypted_server_name" extension to the client.
Paragraph (version B):
A more serious problem is MITM proxies which do not support this
extension.  RFC8446; Section 9.3 requires that such proxies remove
any extensions they do not understand.  The handshake will then
present a certificate based on the public name, without echoing the
"encrypted_client_hello" extension to the client.
Paragraph (version A):
IANA is requested to create an entry, encrypted_server_name(0xffce),
in the existing registry for ExtensionType (defined in RFC8446), with
"TLS 1.3" column values being set to "CH, EE", and "Recommended"
column being set to "Yes".
Paragraph (version B):
Variations in the length of the ClientHelloInner ciphertext could
leak information about the corresponding plaintext. padding describes
a RECOMMENDED padding mechanism for clients aimed at reducing
potential information leakage.
Paragraph (version B):
IANA is requested to create an entry, encrypted_client_hello(0xffce),
in the existing registry for ExtensionType (defined in RFC8446), with
"TLS 1.3" column values being set to "CH, EE", and "Recommended"
column being set to "Yes".