Reviewer: Mohit Sethi Review result: On the Right Track I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dprive-bcp-op-07 Reviewer: Mohit Sethi Review Date: 2019-12-29 IETF LC End Date: 2020-01-02 IESG Telechat date: Not scheduled for a telechat Summary: This draft discusses privacy challenges for recursive DNS resolvers. It then describes policy and security considerations that DNS service providers can use for enhanced user privacy. The draft is 'On the Right Track' but not yet ready. Major issues: I wonder if section 5.1.2.1/5.1.3.1 should also talk about recommending OCSP stapling (RFC 6066)? I looked at RFC 8310 and it mentions RFC 7525. Do you want to mention it here in section 5.1.2.1/5.1.3.1? In section 5.1.2.1, what is meant by 'authentication domain names'? Later, the text says 'authentication name for the service'. I guess you are implying the authentic domain name of the DNS resolver service that the client software should verify through the common name (CN) in the certificate? Some more explanation here would be beneficial. In section 5.1.4, should 'DNS Roadblock avoidance' be 'DNSSEC Roadblock avoidance'? And please add a reference to RFC 8027 here if that is the case. Section 5.1.7 says "discussion on the use of Bloom Filters in Appendix A". It is pointing to the wrong appendix. Also, this section talks about implementing traffic monitoring by the DNS service provider. I would argue that in most deployments, the traffic monitoring is required (and implemented) by a different entity. Think of a home network router that has a parental control. Or an enterprise restricting employees from visiting certain sites (to prevent insider attacks)? The impact of encryption is more serious for them and less so for a DNS service provider. What is the BCP advice for them? Also, is it fair to say that this is a best current practice? It feels that we need more experience before we start recommending it as an optimization. This comment applies to all 5.1.1-5.1.8. Each subsection starts rather abruptly by discussing threats. It would be nice if you add a sentence at the beginning of each sub-section telling the reader what are they heading into. This is probably most obvious from section 5.1.8. Without even telling the reader what is a pure TLS proxy, you start listing the DNS privacy threats. Only later on you mention option that operators may implement DNS-over-TLS using a TLS proxy. In section 5.3.2 'way and OUGHT obfuscate'. OUGHT is not part of RFC 2119/8174. Why is it capitalized? And, 'ought' ought to be followed by a 'to'. At the beginning of section 5, you describe three classes of actions. However, none of the subsections contain clear "Additional options" that operators need to follow for "maximal compliance"? The document seems focused on TLS 1.2 (and does not talk about TLS 1.3). In fact, RFC 8446 is not even in the list of references even though section 5.1.3.1 mentions it. Similarly, Appendix A.2 mentions TLS session resumption without server-side state. How about servers using TLS 1.3 and PSK resumption? RFC 8446 has text on client tracking in appendix C.4: https://tools.ietf.org/html/rfc8446#appendix-C.4. There is something wrong about the last sentence of Appendix A.2 'Note that depending on the specifics of the implementation [RFC8484] may also provide increased tracking'. You already mention RFC 8484 in Appendix A.1 as a means to increase privacy. Perhaps you wanted to cite a different RFC here? Minor issues: Nits/editorial comments: There is mixed usage of Anonymisation (in Table 1) vs Anonymization. The same with Pseudoanonymisation (in Table 1) vs pseudonymization in text. Please check with the RFC editor on what is expected and use that consistently. Also noticed optimisation. In Table 1, Crytpographic should be Cryptographic. Maybe you could use an Oxford comma when using lists of items. In section 5.1.2.1, there is stray space character at the end of the bullet on "Follow the guidance in Section 6.5 of [RFC7525] with regards to certificate revocation ." Perhaps expand DNSSEC on first usage: Domain Name System Security Extensions (DNSSEC). In section 5.1.6 'in terms of such options as filtering' should instead be 'in terms of options such as filtering'. In section 5.1.8 'a DNS aware proxy such as [dnsdist] which offer custom (similar to that proposed in'. Consider using 'offers' instead of 'offer' and 'similar to those proposed in' instead of 'similar to that proposed in'. In section 5.2.2 'presents and overview' should be 'presents an overview'. Consider rephrasing 'the better to resist brute force'. Also, in 'agreed solution or any Standards to inform', why is standards capitalized? In section 5.2.4 'queries on multiple TCP session' should be 'queries on multiple TCP sessions'. Please expand CPE on first usage. In section 6.3 'This is by analogy with e.g. several TLS or website' could instead be 'This is analogous to several TLS or website'. In Appendix A.1 'documents apply to recursive to authoritative DNS' shouldn't there be an 'and'? In Appendix C.1, consider changing the format for the sub bullets of '2. Data collection and sharing.'. Instead of numbering them with 1/2/3, perhaps use a/b/c. In Appendix C.1 'of use of system' could be 'of system use'. Also why is there a line break between 'items that are' and 'included'? There is an extraneous 'the' in 'available with the our threat intelligence'. Consider re-wording parts of paragraph '3. Sharing of data. '. At one place you say 'with our threat intelligence partners' and a few words later you say 'with its threat intelligence partners'. In Appendix C.1 'In the event of events or observed behaviors' is a bit hard to parse. Consider rephrasing the 'event of events' part. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
