On 2/10/20 9:18 PM, Eric Rescorla wrote:
On Mon, Feb 10, 2020 at 8:14 AM Mohit Sethi M <mohit.m.sethi=40ericsson....@dmarc.ietf.org<mailto:40ericsson....@dmarc.ietf.org>> wrote: Hi Sara, I understand the desire to get this done with. However, I have some further comments in-line: On 1/24/20 5:29 PM, Sara Dickinson wrote: 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<mailto: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>. 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<https://protect2.fireeye.com/v1/url?k=91d59bed-cd5e90d7-91d5db76-86925ec6fd56-2a24500b228246a8&q=1&e=f2be251d-f590-4578-b7a9-ac8390a7396e&u=http%3A%2F%2F5.1.2.1%2F5.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<https://protect2.fireeye.com/v1/url?k=5f5ab97a-03d1b240-5f5af9e1-86925ec6fd56-8fb25ccf521d98d2&q=1&e=f2be251d-f590-4578-b7a9-ac8390a7396e&u=http%3A%2F%2F5.1.2.1%2F5.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? I was hoping that the text would be more precise rather than a cursory reference to another RFC. You could say something along the lines: 'The TLS client and server MUST use Certificate Status Requests [RFC6066] for the server's certificate chain and the client MUST treat a CertificateEntry (except the trust anchor) without a valid CertificateStatus extension as invalid and abort the handshake with an appropriate alert.'. In the same vein, I would expect that you would strongly mandate the use of TLS 1.3 with DoH and DNS over TLS? Mohit: I actually don't think we should require OCSP at all. For instance, most browsers are moving away from it. We should require or at least strongly encourage revocation checking. And what is it being replaced with? i found this blog on OCSP stapling in firefox: https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/. Is there an updated blog post about new techniques for revocation checking? --Mohit -Ekr 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. Personally, I find the phrase 'Authentication domain name' very unclear. From the phrase, it doesn't look like it has anything to do with DNS? On first reading, I interpreted it as the domain name where I should authenticate. Since the IESG let this through for RFC 8310, I guess we will have to live with this (poor) choice. 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? I leave it to Alissa and IESG to decide what they want here. 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… My question was specifically about using Bloom filters? Which DNS operators are currently using it? Do we have sufficient evidence other than the research publication that this is 'Best Current Practice'? 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.”thorita 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. thorita Okay. Thanks. I hadn't seen this. I have a question related to the following text: o Aggressive Use of DNSSEC-Validated Cache [RFC8198<https://tools.ietf.org/html/rfc8198>] and [RFC8020<https://tools.ietf.org/html/rfc8020>] (NXDOMAIN: There Really Is Nothing Underneath) to reduce the number of queries to authoritative servers to increase privacy. Suppose I own the domain mydomain.com<http://mydomain.com>? My application requires clients to lookup for non-existent sub domains. So if a client sends a query to the local resolver for non-existent1.mydomain.com<http://non-existent1.mydomain.com> and non-existent2.mydomain.com<http://non-existent2.mydomain.com>, will both be sent to the authoritative server for mydomain.com<http://mydomain.com>? 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." Think of the reader of this document. Appendix A.1 says that DoH can increase privacy. The Appendix A.2 says that with DoH 'identification and tracking may be increased' Should I use DoH or not? I recommend to re-phrase the text in A.2 along the lines 'While DoH can increase privacy, section 8 of RFC 8484 outlines potential mechanisms that can nonetheless be used by on-path adversaries for correlation and tracking. As recommended in RFC 8484, DNS resolvers that offer DoH need to consider the benefit and privacy impact of these features, and their deployment context when deciding what features are enabled. Resolver implementations are advised to expose the minimal set of data needed to achieve the desired feature set.' 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….? Yes, please do. It will help with readability. Thanks for the rest of the changes. --Mohit 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. _______________________________________________ dns-privacy mailing list dns-priv...@ietf.org<mailto:dns-priv...@ietf.org> https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
