Original text:
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 <del> 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. </del>  The design in this document takes a different approach: it assumes <del> 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. </del>  2. directly to that provider, which has access to the plaintext of the connection. <del> In Split Mode, the provider is _not_ the origin server for hidden domains.  Rather the DNS records for hidden domains point to the </del>  provider, but the provider's server just relays the connection back <del> to the hidden server, which is the true origin server.  The provider </del>  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 <del> innocuous domains, but is also providing protection for some hidden domains.  Note that the hidden server can be an unmodified TLS 1.3 </del>  server. 3.2. 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 <del> particular, if some of the clients of a hidden server are </del>  applications rather than Web browsers, those applications might have the public key preconfigured. 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 <del> the hidden server (in Split Mode). </del>  4. (client-facing) SNI.  If present, clients SHOULD use its value in the SNI extension of the subsequent ClientHello. <del> Clients obtain these records by querying DNS for hidden server </del>  domains.  Thus, servers operating in Split Mode SHOULD have DNS <del> configured to return the same A (or AAAA) record for all hidden </del>  servers they service.  This yields an anonymity set of cardinality <del> 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. </del>  The "checksum" field provides protection against transmission errors, including those caused by intermediaries such as a DNS proxy running 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 <del> connection to the hidden server (if in Split Mode).  In the latter </del>  case, it does not make any changes to the TLS messages, but just blindly forwards them. 5.4. <del> The Hidden Server ignores both the "encrypted_server_name" and the </del>  "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 <del> SNI to the hidden server. </del>  <del> Similar to the Shared Mode behavior, the hidden server in Split Mode </del>  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. [[OPEN ISSUE: Do we want "encrypted_server_name" in EE?  It's clearer communication, but would make it so you could not operate a current <del> TLS 1.3 server as a hidden server.]] </del>  6. 7.2.6. This design permits servers operating in Split Mode to forward <del> connections directly to hidden origin servers, thereby avoiding </del>  unnecessary MiTM attacks. 7.2.7. 7.3. <del> Note that the hidden server has no way of knowing what the SNI was, </del>  but that does not lead to additional privacy exposure because the <del> 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 </del>  connection will still complete).  However, the client is still responsible for verifying the server's identity in its certificate.

Reviewer comments:
I decided "hidden" was bad. NAME
+1 to the change. I think that this is the right direction.

Revised text:
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  <ins> 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. </ins> The design in this document takes a different approach: it assumes  <ins> 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. </ins> 2. directly to that provider, which has access to the plaintext of the connection.  <ins> In Split Mode, the provider is _not_ the origin server for private domains.  Rather the DNS records for private domains point to the </ins> provider, but the provider's server just relays the connection back  <ins> to the backend server, which is the true origin server.  The provider </ins> 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  <ins> innocuous domains, but is also providing protection for some private domains.  Note that the backend server can be an unmodified TLS 1.3 </ins> server. 3.2. 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  <ins> particular, if some of the clients of a private server are </ins> applications rather than Web browsers, those applications might have the public key preconfigured. 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  <ins> the backend server (in Split Mode). </ins> 4. (client-facing) SNI.  If present, clients SHOULD use its value in the SNI extension of the subsequent ClientHello.  <ins> Clients obtain these records by querying DNS for ESNI-enabled server </ins> domains.  Thus, servers operating in Split Mode SHOULD have DNS  <ins> configured to return the same A (or AAAA) record for all ESNI-enabled </ins> servers they service.  This yields an anonymity set of cardinality  <ins> 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. </ins> The "checksum" field provides protection against transmission errors, including those caused by intermediaries such as a DNS proxy running 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  <ins> connection to the backend server (if in Split Mode).  In the latter </ins> case, it does not make any changes to the TLS messages, but just blindly forwards them. 5.4.  <ins> The backend Server ignores both the "encrypted_server_name" and the </ins> "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  <ins> SNI to the backend server. </ins>  <ins> Similar to the Shared Mode behavior, the backend server in Split Mode </ins> 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. [[OPEN ISSUE: Do we want "encrypted_server_name" in EE?  It's clearer communication, but would make it so you could not operate a current  <ins> TLS 1.3 server as a backend server.]] </ins> 6. 7.2.6. This design permits servers operating in Split Mode to forward  <ins> connections directly to backend origin servers, thereby avoiding </ins> unnecessary MiTM attacks. 7.2.7. 7.3.  <ins> Note that the backend server has no way of knowing what the SNI was, </ins> but that does not lead to additional privacy exposure because the  <ins> 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 </ins> connection will still complete).  However, the client is still responsible for verifying the server's identity in its certificate.