Original text:
Progressive deployment of solutions like DNS in TLS RFC7858 and DNS over HTTPS RFC8484 mitigates the disclosure of DNS information.  More and more services are colocated on multiplexed servers, loosening the <del> relation between IP address and web service.  However, multiplexed servers rely on the Service Name Information (SNI) TLS extension to direct connections to the appropriate service implementation.  This protocol element is transmitted in clear text.  As the other methods of monitoring get blocked, monitoring focuses on the clear text SNI. The purpose of SNI encryption and privacy is to prevent that. </del>  Replacing clear text SNI transmission by an encrypted variant will improve the privacy and reliability of TLS connections, but the The SNI was defined to facilitate management of servers, but the developers of middleboxes found out that they could take advantage of the information.  Many examples of such usage are reviewed in <del> RFC8404.  They include: </del>  The SNI is probably also included in the general collection of metadata by pervasive surveillance actors, for example to identify The clear-text transmission of the SNI was not flagged as a problem in the security consideration sections of RFC3546, RFC4366, or RFC6066.  These specifications did not anticipate the alternative <del> uses and abuses described in snileak.  One reason may be that, when these RFCs were written, the SNI information was available through a variety of other means. </del>  Many deployments still allocate different IP addresses to different services, so that different services can be identified by their IP <del> addresses.  However, content distribution networks (CDN) commonly serve a large number of services through a comparatively small number of addresses. </del>  The SNI carries the domain name of the server, which is also sent as part of the DNS queries.  Most of the SNI usage described in snileak The decoupling of IP addresses and server names, deployment of DNS privacy, and protection of server certificate transmissions all contribute to user privacy in the face of an RFC3552-style adversary. <del> Encrypting the SNI now will complete this push for privacy and make it harder to censor or otherwise provide differential treatment to specific internet services. </del>  2.3. <del> Deploying SNI encryption will help thwart most of the "unanticipated" SNI usages described in snileak, including censorship and pervasive surveillance.  It will also thwart functions that are sometimes described as legitimate.  Most of these functions can, however, be realized by other means.  For example, some DNS service providers offer customers the provision to "opt in" filtering services for parental control and phishing protection.  Per-stream QoS could be provided by a combination of packet marking and end-to-end agreements.  As SNI encryption becomes common, we can expect more deployment of such "end-to-end" solutions. At the moment, enterprises have the option of installing a firewall performing SNI filtering to prevent connections to certain websites. With SNI encryption this becomes ineffective.  Obviously, managers could block usage of SNI encryption in enterprise computers, but this wide-scale blocking would diminish the privacy protection of traffic leaving the enterprise, which may not be desirable.  Enterprise managers could rely instead on filtering software and management software deployed on the enterprise's computers. </del>  3. Over the past years, there have been multiple proposals to add an SNI <del> encryption option in TLS.  Many of these proposals appeared promising, though were rejected after security reviews identified plausible attacks.  In this section, we collect a list of these known attacks. </del>  3.1. encrypted SNI values and forcing the multiplexed server to spend resources in useless decryption attempts. <del> It may be argued that this is not an important DOS avenue, as regular TLS connection attempts also require the server to perform a number of cryptographic operations.  However, in many cases, the SNI decryption will have to be performed by a front-end component with limited resources, while the TLS operations are performed by the component dedicated to their respective services.  SNI-based DOS attacks could target the front-end component. </del>  3.4. The SNI encryption requirement does not stop with HTTP over TLS. Multiple other applications currently use TLS, including, for <del> example, SMTP RFC5246, DNS RFC7858, IMAP RFC2595, and XMPP RFC7590. </del>  These applications, too, will benefit from SNI encryption.  HTTP-only methods like those described in httpfrontingtunnels would not apply there.  In fact, even for the HTTPS case, the HTTPS tunneling service 4. In the absence of TLS-level SNI encryption, many sites rely on an <del> "HTTP Co-Tenancy" solution.  The TLS connection is established with the fronting server, and HTTP requests are then sent over that connection to the hidden service.  For example, the TLS SNI could be set to "fronting.example.com", the fronting server, and HTTP requests sent over that connection could be directed to "hidden.example.com", </del>  accessing the hidden service.  This solution works well in practice when the fronting server and the hidden server are "co-tenants" of the same multiplexed server. implementations, trust, and applicability: The discovery issue is common to most SNI encryption solutions.  The <del> browser issue may be solved by developing a browser extension that support HTTP Fronting, and manages the list of fronting services associated with the hidden services that the client uses.  The multi- protocol issue can be mitigated by using implementation of other applications over HTTP, such as for example DNS over HTTPS RFC8484. The trust issue, however, requires specific developments. </del>  4.1. In practice, this attack is well mitigated when the hidden service is accessed through a specialized application.  The name of the fronting server can then be programmed in the code of the application.  But <del> the attack is much harder to mitigate when the hidden service has to be accessed through general purpose web browsers.  The browsers will need a mechanism to obtain the fronting server indication in a secure way. </del>  There are several proposed solutions to this problem, such as creating a special form of certificate to codify the relation between fronting and hidden server, or obtaining the relation between hidden and fronting service through the DNS, possibly using DNSSEC to avoid <del> spoofing. We can observe that content distribution networks (CDNs) have a similar requirement.  They need to convince the client that "www.example.com" can be accessed through the seemingly unrelated "cdn-node-xyz.example.net".  Most CDNs have deployed DNS-based solutions to this problem.  However, the CDN often holds the authoritative certificate of the origin.  There is simultaneously verification of a relationship between the origin and the CDN, through the certificate, and a risk that the CDN can spoof the content from the origin. </del>  4.3.

Reviewer comments:
This addresses comments from Roman , Éric , Adam , Alissa and Alexey . Also make sure that fixes addressing Mirja's comment will be in the final text.
NAME I think this properly addresses the comments, but you may want to check with Adam for section 3.6 and Alexey for section 4.
LGTM -- thanks, Christian!
Please use RFC 8314 instead of RFC 2595 as a reference for IMAP over TLS.
Done in PR
COMMENT: Section 1: s/servers rely on the Service Name Information (SNI) TLS extension/servers rely on the Server Name Indication (SNI) TLS extension [RFC 6066]/ Section 2.1: Why is parental controls in quotes? Section 2.2: s/Encrypting the SNI now will complete this push/Encrypting the SNI completes this push/ (for timelessness) Section 2.3: In the first paragraph I would suggest trying to use the present tense more so that this still makes sense far in the future. s/At the moment/At the time of this writing/
Done in PR
Adam Roach has entered the following ballot position for draft-ietf-tls-sni-encryption-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Thanks to everyone who worked on this. It seems that it will be a useful tool for evaluating potential solutions. : Nit: "URL follows:" : This final sentence appears to be missing some kind of citation before the comma. : It's a bit unclear why this is described as part of the injection of a third party into the scenario. As far as I understand, the described attack exists today, in the absence of any SNI encrypting schemes. If there's a new twist introduced by a multi-party security context, the current text doesn't seem to explain what it is. : Nit: "...including, for example, SMTP..." Nit: "URL XMPP..." Nit: "...benefit from SNI..." Nit: "HTTP-only..." : Nit: "URL" : I think you're missing a comma between the two Martins.
Done in PR
COMMENT: Thank you for the work put into this document. It is well-written and easy to follow. Please find below a couple of comments and nits. Reading " In practice, it may well be that no solution can meet every requirement, and that practical solutions will have to make some compromises." in the abstract brought a smile on my face Same for "employees of the UK National Cyber Security Centre" at the end Regards, -éric == COMMENTS == -- Section 2.1 -- C.1) I would suggest to use the words "network operators" rather than ISP as enterprise or parents for home networks are also relying on clear-text SNI to enforce some policies. -- Section 2.2 -- C.2) The word "abuses" seems a little strong in the first paragraph, I prefer the wording used in 2.1 "unanticipated usage". But, this is only one comment. -- Section 3.6 -- C.3) It is rather a question for my own curiosity... "The fronting service could be pressured by adversaries. " is an obvious attack but even if SNI is protected, the fronting service can still apply any policy to a protected service as it has the knowledge of protected services by design. Hence, I wonder why this case is mentioned here. -- Security section -- Like Warren, I find the content of this section unusual. == NITS == -- Section 2.1 -- Probably worth expanding "MITM" at first use. --Section 3.3 -- Probably worth expanding "DOS" at first use.
Barry Leiba commented: Actually, "DoS" (with the small "o") is in the RFC Editor's list of abbreviations that do not need to be expanded. That, of course, doesn't mean that it shouldn't be expanded. But it should be spelled with the small "o", in any case.
Done in PR

Revised text:
Progressive deployment of solutions like DNS in TLS RFC7858 and DNS over HTTPS RFC8484 mitigates the disclosure of DNS information.  More and more services are colocated on multiplexed servers, loosening the  <ins> relation between IP address and web service.  For example, in virtual hosting solutions, multiple services can be hosted as co-tenants on the same server, and the IP address and port do not uniquely identify a service.  In cloud or Content Delivery Networks (CDNs) solutions, a given platform hosts the services or servers servers of a lot of organization, and looking up to what netblock an IP address belongs reveals little.  However, multiplexed servers rely on the Service Name Information (SNI) TLS extension RFC6066 to direct connections to the appropriate service implementation.  This protocol element is transmitted in clear text.  As the other methods of monitoring get blocked, monitoring focuses on the clear text SNI.  The purpose of SNI encryption and privacy is to prevent that. </ins> Replacing clear text SNI transmission by an encrypted variant will improve the privacy and reliability of TLS connections, but the The SNI was defined to facilitate management of servers, but the developers of middleboxes found out that they could take advantage of the information.  Many examples of such usage are reviewed in  <ins> RFC8404.  Other examples came out during discussions of this draft. They include: </ins> The SNI is probably also included in the general collection of metadata by pervasive surveillance actors, for example to identify The clear-text transmission of the SNI was not flagged as a problem in the security consideration sections of RFC3546, RFC4366, or RFC6066.  These specifications did not anticipate the alternative  <ins> usage described in snileak.  One reason may be that, when these RFCs were written, the SNI information was available through a variety of other means, such as tracking IP addresses, DNS names, or server certificates. </ins> Many deployments still allocate different IP addresses to different services, so that different services can be identified by their IP  <ins> addresses.  However, CDNs commonly serve a large number of services through a comparatively small number of addresses. </ins> The SNI carries the domain name of the server, which is also sent as part of the DNS queries.  Most of the SNI usage described in snileak The decoupling of IP addresses and server names, deployment of DNS privacy, and protection of server certificate transmissions all contribute to user privacy in the face of an RFC3552-style adversary.  <ins> Encrypting the SNI completes this push for privacy and make it harder to censor or otherwise provide differential treatment to specific internet services. </ins> 2.3.  <ins> Deploying SNI encryption helps thwart most of the unanticipated SNI usages including censorship and pervasive surveillance, but it also will break or reduce the efficacy of the operational practices and techniques implemented in middle-boxes as described in snileak.  Most of these functions can, however, be realized by other means.  For example, some DNS service providers offer customers the provision to "opt in" filtering services for parental control and phishing protection.  Per-stream QoS could be provided by a combination of packet marking and end-to-end agreements.  As SNI encryption becomes common, we can expect more deployment of such "end-to-end" solutions. At the time of this writing, enterprises have the option of installing a firewall performing SNI filtering to prevent connections to certain websites.  With SNI encryption this becomes ineffective. Obviously, managers could block usage of SNI encryption in enterprise computers, but this wide-scale blocking would diminish the privacy protection of traffic leaving the enterprise, which may not be desirable.  Enterprise managers could rely instead on filtering software and management software deployed on the enterprise's computers. </ins> 3. Over the past years, there have been multiple proposals to add an SNI  <ins> encryption option in TLS.  A review of the TLS mailing list archives shows that many of these proposals appeared promising but were rejected after security reviews identified plausible attacks.  In this section, we collect a list of these known attacks. </ins> 3.1. encrypted SNI values and forcing the multiplexed server to spend resources in useless decryption attempts.  <ins> It may be argued that this is not an important Denial of Service Attacks (DoS) avenue, as regular TLS connection attempts also require the server to perform a number of cryptographic operations.  However, in many cases, the SNI decryption will have to be performed by a front-end component with limited resources, while the TLS operations are performed by the component dedicated to their respective services.  SNI-based DoS attacks could target the front-end component. </ins> 3.4. The SNI encryption requirement does not stop with HTTP over TLS. Multiple other applications currently use TLS, including, for  <ins> example, SMTP RFC5246, DNS RFC7858, IMAP RFC8314, and XMPP RFC7590. </ins> These applications, too, will benefit from SNI encryption.  HTTP-only methods like those described in httpfrontingtunnels would not apply there.  In fact, even for the HTTPS case, the HTTPS tunneling service 4. In the absence of TLS-level SNI encryption, many sites rely on an  <ins> "HTTP Co-Tenancy" solution, often refered to as Domain Fronting domfront.  The TLS connection is established with the fronting server, and HTTP requests are then sent over that connection to the hidden service.  For example, the TLS SNI could be set to "fronting.example.com", the fronting server, and HTTP requests sent over that connection could be directed to "hidden.example.com", </ins> accessing the hidden service.  This solution works well in practice when the fronting server and the hidden server are "co-tenants" of the same multiplexed server. implementations, trust, and applicability: The discovery issue is common to most SNI encryption solutions.  The  <ins> browser issue was solved in domfront by implementing domain fronting as a pluggable transport for the Tor browser.  The multi-protocol issue can be mitigated by using implementation of other applications over HTTP, such as for example DNS over HTTPS RFC8484.  The trust issue, however, requires specific developments. </ins> 4.1. In practice, this attack is well mitigated when the hidden service is accessed through a specialized application.  The name of the fronting server can then be programmed in the code of the application.  But  <ins> the attack is harder to mitigate when the hidden service has to be accessed through general purpose web browsers. </ins> There are several proposed solutions to this problem, such as creating a special form of certificate to codify the relation between fronting and hidden server, or obtaining the relation between hidden and fronting service through the DNS, possibly using DNSSEC to avoid  <ins> spoofing.  The experiment described in domfront solved the issue by integrating with the Lantern Internet circumvention circumvention tool. We can observe that CDNs have a similar requirement.  They need to convince the client that "www.example.com" can be accessed through the seemingly unrelated "cdn-node-xyz.example.net".  Most CDNs have deployed DNS-based solutions to this problem.  However, the CDN often holds the authoritative certificate of the origin.  There is simultaneously verification of a relationship between the origin and the CDN, through the certificate, and a risk that the CDN can spoof the content from the origin. </ins> 4.3.