Telechat Review of draft-ietf-tls-sni-encryption-05
review-ietf-tls-sni-encryption-05-tsvart-telechat-aboba-2019-09-18-00
Request | Review of | draft-ietf-tls-sni-encryption |
---|---|---|
Requested revision | No specific revision (document currently at 09) | |
Type | Telechat Review | |
Team | Transport Area Review Team (tsvart) | |
Deadline | 2019-09-17 | |
Requested | 2019-09-09 | |
Requested by | Mirja Kühlewind | |
Authors | Christian Huitema , Eric Rescorla | |
I-D last updated | 2019-09-18 | |
Completed reviews |
Opsdir Last Call review of -05
by Dan Romascanu
(diff)
Genart Last Call review of -05 by Meral Shirazipour (diff) Tsvart Telechat review of -05 by Dr. Bernard D. Aboba (diff) |
|
Comments |
This seems relevant to TSV as well! |
|
Assignment | Reviewer | Dr. Bernard D. Aboba |
State | Completed | |
Request | Telechat review on draft-ietf-tls-sni-encryption by Transport Area Review Team Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/tsv-art/2QHigyhkVzOW0PzgvapEs0PsEJM | |
Reviewed revision | 05 (document currently at 09) | |
Result | Ready w/nits | |
Completed | 2019-09-18 |
review-ietf-tls-sni-encryption-05-tsvart-telechat-aboba-2019-09-18-00
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 tsv-art@ietf.org 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.