Change:
These proposed edits address the feedback from Bernard Aboba (Issue ).
NAME Can you check the proposed fixes? Thanks.
Thanks, NAME
Document: draft-ietf-tls-sni-encryption Reviewer: Bernard Aboba Review result: Ready with Nits This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC EMAIL if you reply to or forward this review. I have not identified any transport related issues. NITS Expansion of acronyms on first use: Abstract: TLS Section 1: DNS Section 2.1: ISP, QoS, MITM Section 2 s/mutiple/multiple/ Section 2.1 s/fradulent/fraudulent/ Section 3.6 The downside is the the client will not verify the identity of the fronting service with risks discussed in , but solutions will have to mitigate this risks. [BA] Several problems with this sentence: s/the the/the/ s/this risks/the risk/ s/discussed in ,/discussed in [REF-TBD],/ Section 3.7.1 This section seems somewhat out of place in a section on Security and Privacy Requirements for SNI Encryption, given that it relates to hiding of the ALPN, and the text admits a weak case for linking the two problems: Using the same technique for hiding the ALPN and encrypting the SNI may result in excess complexity. It might be preferable to encrypt these independently. You might consider moving this section to Section 4.3.1, under Section 4.3 Related Work. Section 5 The first paragraph of this section strikes me as being potentially better suited to inclusion in Section 1 Introduction. Replacing clear text SNI transmission by an encrypted variant will improve the privacy and reliability of TLS connections, but the design of proper SNI encryption solutions is difficult. This document does not present the design of a solution, but provides guidelines for evaluating proposed solutions.
Thanks for the feedback, Bernard. We already fixed in the editor copy some of the issues that you described based on other feedback received during last call, but not all. Your comments about section 3.7.1 and section 5 are interesting. I like your suggestion of moving some of the text from section 5 to the introduction and believe that it will improve the document. Regarding section 3.7.1, you suggest adding a comment on related work, and perhaps moving some of the discussion of ALPN there. I understand the rationale, but I am a bit worried about going too far there -- the current text reflects discussions and feedback on the TLS list. Also, if we did add a section on related work we would probably need to reference the deployment of encrypted DNS services, and I am a bit worried about doing that late in the production cycle. How about a compromise, such as pointing the issue in the introduction with a forward reference to section 3.7.1? -- Christian Huitema
Regarding abbreviations: TLS, DNS, ISP, and QoS are considered "well known" acronyms according to URL, and do not need to be spelled out. Changes for spelling our MITM are proposed in PR .
Fixed in Pr

Discussion:
of monitoring get blocked, monitoring focuses on the clear text SNI. The purpose of SNI encryption and privacy is to prevent that. <del> In the past, there have been multiple attempts at defining SNI encryption.  These attempts have generally floundered, because the simple designs fail to mitigate several of the attacks listed in snisecreq.  In the absence of a TLS-level solution, the most popular approach to SNI privacy for web services is HTTP-level fronting, which we discuss in httpfronting. </del> <ins> Replacing clear text SNI transmission by an encrypted variant will improve the privacy and reliability of TLS connections, but the design of proper SNI encryption solutions is difficult.  In the past, there have been multiple attempts at defining SNI encryption.  These attempts have generally floundered, because the simple designs fail to mitigate several of the attacks listed in snisecreq.  In the absence of a TLS-level solution, the most popular approach to SNI privacy for web services is HTTP-level fronting, which we discuss in httpfronting. This document does not present the design of a solution, but provides guidelines for evaluating proposed solutions.  The need for related work on the encryption of the Application Layer Protocol Negotiation (ALPN) parameters of TLS is discussed in hiding-alpn. </ins> 2.

5. <del> Replacing clear text SNI transmission by an encrypted variant will improve the privacy and reliability of TLS connections, but the design of proper SNI encryption solutions is difficult.  This document does not present the design of a solution, but provides guidelines for evaluating proposed solutions. </del> This document lists a number of attacks against SNI encryption in snisecreq, and also in delegationtokens, and presents a list of requirements to mitigate these attacks.  Current HTTP-based solutions

[1]. Thanks to Daniel Kahn Gillmor for a pretty detailed review of the <del> initial draft.  Thanks to Mike Bishop, Stephen Farrell, Barry Leiba, Martin Rex, Meral Shirazipour, Martin Thomson and employees of the UK National Cyber Security Centre for their reviews. </del> <ins> initial draft.  Thanks to Bernard Aboba, Mike Bishop, Stephen Farrell, Barry Leiba, Martin Rex, Meral Shirazipour, Martin Thomson and employees of the UK National Cyber Security Centre for their reviews. </ins> 8.  References