> On 29 Dec 2019, at 13:50, Mohit Sethi via Datatracker <nore...@ietf.org> > wrote: > > 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.
Many thanks for the detailed review! Ben, Rob I hope theses fixes also address your comments. > > 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? What exactly are you thinking of here - something that just says “Server operators should also follow the best practices with regard to OCSP as described in RFC7525”? If something more could you please suggest text? > > 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. It is defined in the terminology section of RFC8310: "Authentication domain name: A domain name that can be used to authenticate a privacy-enabling DNS server. Sources of authentication domain names are discussed in Section 7." I have added a reference for RFC8310 after the first use of ‘authentication domain name’ and made sure every instance of 'authentication name' is updated to 'authentication domain name' for clarity. > > 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. Yes, good catch - will do. > > Section 5.1.7 says "discussion on the use of Bloom Filters in Appendix A". It > is pointing to the wrong appendix. Fixed - thanks. > 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? You are correct that the there are differing concerns but I don’t believe this document should tackle that - the audience of the document is specifically operators of DNS privacy services, typically monitoring to prevent DDoS or similar, not network operators in general (although they may be both in some cases). For the more general case I think the impact is covered in RFC8404 'Effects of Pervasive Encryption on Operators’? I do notice a couple of places where just ‘operators’ is used in the text so could add ‘DNS Privacy Service’ before that to clarify? > 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. Given the specific scope discussed above I think it is fair. The privacy policies of most of the public resolver operators and ISPs that offer encrypted DNS are pretty good today in terms of how they try to minimise the user data retained and I’m sure they all still have monitoring in place… > > 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. If we go down this road then I think to be consistent we would need to add text for all 16 sections 5.1.1 to 5.3.3. I could do this but I have a feeling it would be come quite repetitive with respect to the section title text and I think if we could get the titles correct (and possibly add more text to section 5) this might be unnecessary. I suggest: Section 5: Add a first paragraph: “In the following sections we first outline the threats relevant to the specific topic and then discuss the potential actions that can be taken to mitigate them.” And for section 5.1.8 change the title to “Limitations of fronting a DNS Privacy Service with a pure TLS proxy”. Happy to update any other headers you thought too vague. Would that address the issue or do you still think additional text is required? > > 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’.. I was confused by this and then realised it is a hangover from a much earlier version of the draft that used EXPECTED/OUGHT/MIGHT keywords defined in the draft to described the various levels of actions…. so as you suggest: OLD: “For example, a resolver with a very small community of users risks exposing data in this way and OUGHT obfuscate this...” NEW: “For example, a resolver with a very small community of users risks exposing data in this way and ought to obfuscate this..." > > 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”? Sections 5.3.1 and 5.3.2 do have them. In earlier versions several more sections but they have been removed. > > 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. A slight hangover from the fact the DNS-over-TLS spec was published in 2015 before TLS 1.3 was standardised (so it just says TLS 1.2 or later) and so most of the early DoT services used just TLS 1.2. Section 5.1.3.1 had the text ‘RFC8446’ but it wasn’t actually a reference so I’ve fixed that - thanks. I’ve added a bullet point to Appendix A.2 “RFC8446 Appendix C.4 describes Client Tracking Prevention in TLS 1.3" > > 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? The point is that the use of HTTP headers in DoH can add additional privacy concerns over the other DNS transports, but that RFC8484 leaves that as an implementation decision. I suggest replacing the text with “Note that Section 8 of RFC8484 outlines the privacy considerations of DoH. Depending on the specifics of a DoH implementation there may be increased identification and tracking compared to other DNS transports." > > 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. Thanks - have fixed. I have now used the American English forms (z not s) throughout. > > In Table 1, Crytpographic should be Cryptographic. Ack. > > Maybe you could use an Oxford comma when using lists of items. Had it some places, but not all - should be fixed now. > > 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’? All fixed - thanks. > > 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. I’m currently using markdown which won’t let me do that…. :-( I do think that would be better so I suggest adding a note that this is done at RFC editor time….? > > 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’. Fixed. > > 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. Replaced events with actions. Best regards Sara.
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
