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

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