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

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