Draft: draft-ietf-tls-esni

Commentary: Based on comments in Montreal , I believe that the authors no longer intend to document the partial - split configuration .
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, 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 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
backend server, which is the true origin server.  The provider does
not have access to the plaintext of the connection.
Paragraph (version A):
Content providers operating in Split Mode SHOULD ensure that the A
and AAAA records for ESNI-enabled server names do not allow
identifying the server name from the IP address.  This can for
example be achieved by always returning the same records for all
ESNI-enabled names, or by having the function that picks addresses
from a pool not depend on the server name.  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 B):
Content providers SHOULD ensure that the A and AAAA records for ESNI-
enabled server names do not allow identifying the server name from
the IP address.  This can for example be achieved by always returning
the same records for all ESNI-enabled names, or by having the
function that picks addresses from a pool not depend on the server
name.  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):
Assuming ESNI records 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.
Paragraph (version A):
Validating the ESNIKeys structure additionally validates the public
name.  This validates any retry signals from the server because the
client validates the server certificate against the public name
before retrying.
Paragraph (version B):
Assuming ESNI 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):
Authenticating the ESNIKeys structure naturally authenticates the
included public name.  This also authenticates any retry signals from
the server because the client validates the server certificate
against the public name before retrying.