Change:
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> <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. <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> <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 <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> <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.

Discussion:
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