Mohit, I’m out of the office next week so in order to try to move the draft along I have published an -08 version which I think addresses most of your comments (there were a few questions in my response below). Please let me know if any are still outstanding.
Best regards Sara. > On 17 Jan 2020, at 15:33, Sara Dickinson <s...@sinodun.com> wrote: > > >> On 29 Dec 2019, at 13:50, Mohit Sethi via Datatracker <nore...@ietf.org >> <mailto: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 >> <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 >> <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
