Summary: Has 2 DISCUSSes. Needs one more YES or NO OBJECTION position to pass.
I have added more detail to point #3 below as requested on today's telechat. (1) Picking up on a Gen-ART review comment: Section 5.1.7 seems to be aimed at entities other than the operators of DNS privacy services. That is, the "impact" seems like it is on third-party entities, but then the "optimization" talks about DNS privacy service operators using "alternative means for traffic monitoring." I guess what I don't understand is why the DNS privacy service operators need alternative means, since they still have access to the cleartext. (2) I think Section 6 needs to clarify that it is providing suggestions only on matters relating to the technical operation of DNS privacy services that may be described in DROP policies, and not on any other matters. There are numerous other matters that are typically addressed in privacy statements (e.g., what form of legal process the operator requires to supply data to law enforcement, how the operator handles data about children, etc.). This document should not give the impression that the listed items in the subsections are an exhaustive list, nor should it attempt to offer an exhaustive list. (3) I do not think item #5 in Section 6.1.2 belongs in this document. I don't see how it is within scope for the IETF to be specifying these sorts of best practices, which are not technical or operational in nature but focus on legal matters and likely require the involvement of lots of lawyers in order to get the provisions written. This section implies that the DROP documents would become legal/compliance documents by nature, which may or may not be a good choice but is not within the remit of the IETF to specify. Also, I think what this section asks for is not the norm today and therefore it seems odd for the IETF to specify a best practice that operators may not have any chance of being able to comply with (e.g., listing specific law enforcement agencies, privacy laws, or countries where data centers will reside and the data will never move from them).
Section 1: "This document does not, however, define a particular Privacy statement, nor does it seek to provide legal advice or recommendations as to the contents." This is not accurate. The document does make recommendations about the contents. Section 3: "the privacy of the DNS" strikes me as a bit of an odd term as the DNS itself doesn't have privacy needs. Perhaps this means the privacy properties of the DNS. Section 5.2.3: I think the table and its associated text belongs in Appendix B. It is not BCP material itself and is not readily understandable without the rest of the text in Appendix B anyway. Section 5.2.4: "Resolvers _might_ receive client identifiers e.g. MAC addresses in EDNS(0) options - some Customer-premises equipment (CPE) devices are known to add them." It would be great to add a citation there if one exists. Section 5.3.3: "Operators should not provide identifiable data to third-parties without explicit consent from clients (we take the stance here that simply using the resolution service itself does not constitute consent)." I'm not convinced its appropriate for this document to be commenting on what constitutes consent. I also think that as a general matter the research in this area demonstrates that privacy-by-consent is broken and that the number of cases in which an individual providing consent for identifiable data sharing actually reads, understands, and agrees with the terms of the sharing is miniscule. It seems like the real best current practice mitigation here is to not share identifiable data. Section 6.1.1: "Make an explicit statement that IP addresses are treated as PII." PII is a bit of a jurisdiction-specific term. I would recommend using the definition of personal data from RFC 6973. Section 6.2: This section should be an appendix. Section A.2: I don't understand why the reference to Section 8 of RFC 8484 isn't just in the bulleted list with all the other documents, and why there is a generic note included with it when the specific privacy implications are more completely discussed in the referenced section of RFC 8484 (just like with the other documents in the list).
[updated to add one discuss point and a comment section] This document is trying to make normative references to sections of draft-ietf-dprive-rfc7626-bis that have not existed since the -00 of that document, with the content having been removed for being too controversial. Do we need to delay processing this document until 7626bis has settled down and it is clear what content we can refer to in that vs. needing to incorporate into this document? (It's unclear that such content would be less controversial in this document than in that one.) Specifically, Section 5.1.2 of this document refers to Section 2.5.3 of that document ("Rogue Servers"). [new discuss point] This is perhaps more a flaw in RFC 8310 than in this document, but I'd still like to discuss it: in Section 5.1.2 we read that: When using DNS-over-TLS clients that select a 'Strict Privacy' usage profile [RFC8310] (to mitigate the threat of active attack on the client) require the ability to authenticate the DNS server. To enable this, DNS privacy services that offer DNS-over-TLS should provide credentials in the form of either X.509 certificates [RFC5280] or Subject Public Key Info (SPKI) pin sets [RFC8310]. Authenticating the DoT server via X.509 certificate as described here and in RFC 8310 seesm to involve looking for an ADN in the certificate; however, I could not find any discussion of how to know what CA(s) or trust anchors to trust to certify the ADN in a certificate. It's possible that RFC 8310's use of "PKIX Certificate" is supposed to imply that Web PKI trust anchors are used, but that's not immediately clear. It may be the case that we need to mention provisioning a trust anchor as well as the X.509 certificate information, here.
In general, I support this document. It is good to help educate folks on what should be included in a privacy statement, but as Alissa notes, there is no "one size fits all". Especially if one implies a cookie cutter type of form with check marks will be adequate to compare offerings. I don't think this is what was intended - considering the detailed assessment on the DROP form - but there's a couple of sentence stragglers that infer the DROP form is the form *for all*. Support Alissa's and Ben's Discuss. A couple of my concerns: 5.3.3 Both Alissa (and Stephen previously) noted there is no meaningful way to obtain explicit "consent". Considering this document is a "best practice", suggest simply removing, and recommending as Alissa says "not share". 6.1.2 #5 agree with Alissa - this should be removed. 6.2 "We note that the existing set of policies vary widely in style, content and detail and it is not uncommon for the full text for a given operator to equate to more than 10 pages of moderate font sized A4 text. It is a non-trivial task today for a user to extract a meaningful overview of the different services on offer." I'm not sure what this is trying to say? The purpose of this document is to advocate for comprehensive privacy statements. As Alissa notes (2), this document alone is not sufficient to give adequate description for a service. This sentence implies a 10-page document is bad because it is 10 pages (yet this document's DROP example has 5 pages requiring detailed information and lists to complete). And the last sentence negatively prejudges a user's reading capability or specific interest. Suggest drop the last sentence and it will remove the negativity as I don't think the DROP example is any easier on a user to read.
** Per 6.1.1. Item 2. Per “Data Collection and sharing … and in each case whether it is aggregated, pseudonymized, or anonymized and the conditions of data transfer”, would be useful to also have the policy describe the technique used to realize this minimization? ** Section 6.1.2. Item 5. Per “Jurisdiction. This section should communicate the applicable jurisdictions and law enforcement regimes …”, what’s a “law enforcement regime” (and why is that different than a “jurisdiction”)? ** Section 6.2.1. Per item 5.4. Why restrict disclosure to “law enforcement agencies, or other public and private parties dealing with security and intelligence”, and not request disclosure of all parties who get access with “Specify whether the operator has any agreement in place with public or private parties to give them access to the server and/or to the data”? One party’s assessment of an entity as “security” (captured in the current text) is another’s “public safety” (not captured in the current text but captured the recommend text) ** Editorial Nits -- Section 6.1.2. Typo. s/section Section 5/Section 5/g -- Section 6.1.2 Editorial Nit. Per item 5.2, “… and how to contact the operator to enforce them”, it is more appropriate to say “exercise them”, e.g., a user contacts the operator to exercise their “right to be forgotten” (not enforce their right to be forgotten).
* Section 5.2.3. I found Table 1 to be extremely confusing. It is not clear from the table whether all of the properties are concurrently applicable to a certain technique when an "X" appears there. e.g. TC has marks for Format preserving, Prefix preserving, Reordering/Shuffling, and Random substitution. Some of these seem to be mutually exclusive. It would be good if you can clarify. I support Alissa and Ben's Discusses.
A couple of small comments/questions: 1) RFC2119/RFC8174 disclaimer is present in section 4, however, it does seem to be the case that normative language is used. I would recommend to actually use normative language in this doc! 2) Can you actually provide references for the techniques listed in Table 1? 3) Sec 22.214.171.124: “A DNS-over-TLS privacy service on both port 853 and 443. This practice may not be possible if e.g. the operator deploys DoH on the same IP address.” Isn’t 443 basically DoH? Why would you deploy DoT over 853? Is that a common practice? Sorry if I miss something... 4) As a side node to the AD and shepherd: Answer to question 7 in shepherd write-up is “(7) No IPR Disclosures” which does not really answer the question if all author have confirmed that they are not aware of any additional IPR they would need to disclose…
I support Ben’s DISCUSS. Other comments: Throughout, “privacy-related” needs the hyphen, as it’s a compound modifier. — Section 1 — For example the user has a clear expectation of which resolvers have visibility of their query data however this resolver/ transport selection may provide an added mechanism to track them as they move across network environments. This sentence needs some punctuation: certainty, a comma after “for example”, and probably one before “however”. Even with those, it’s an awkward sentence and you might consider rephrasing it. It is an untested area that simply using a DNS resolution service constitutes consent from the user for the operator to process their query data. NEW Whether simply using a DNS resolution service constitutes consent from the user for the operator to process their query data is as yet untested. END o To introduce the DNS Recursive Operator Privacy (DROP) statement and present a framework to assist writers of this document. When I read this, I thought you meant *this* document, and that didn’t make sense. You mean “that document”, or, better, “writers of a DROP statement.” DROP statement is a document that an operator can publish outlining their operational practices and commitments with regard to privacy thereby providing a means for clients to evaluate the privacy properties of a given DNS privacy service. This needs at least a comma before “thereby”. I might also change to “publish, which outlines ... privacy, and thereby provides a means”. (At this point I’m going to stop calling out all but the most hard-to-follow editorial issues.) — Section 2 — Whilst the issues raised here are targeted at those operators who choose to offer a DNS privacy service, considerations for areas 2 and 3 could equally apply to operators who only offer DNS over unencrypted transports but who would like to align with privacy best practice. If we’re considering encryption to be part of the best practice, this seems odd. Maybe say “but who would otherwise like to align...”? — Section 5.1.1 — o DNS-over-TLS [RFC7858] and [RFC8310]. o DoH [RFC8484]. There’s no reason to hyphenate the former, and the latter should also be expanded here: NEW o DNS over TLS [RFC7858] and [RFC8310]. o DNS over HTTPS [RFC8484]. END Similarly, take the hyphens out of “DNS over DTLS” in the next paragraph, and out of “DNS over TLS” throughout the document. — Section 126.96.36.199 — It’s “forgo” (give up), not “forego” (go before). — Section 8 — For a document such as this, the Security Considerations sectiin seems very meagre. As the Sec ADs have not called this out, I’ll presume they think it’s OK, and I won’t press the issue. Perhaps all relevant information is already elsewhere in the document.
I think this is a very useful document and I am looking forward to it getting published. I support updated Ben’s DISCUSS. ********************************************************************** * Note, that I am conducting an experiment when people aspiring to be* * Area Directors get exposed to AD work ("AD shadowing experiment"). * * As a part of this experiment they get to review documents on IESG * * telechats according to IESG Discuss criteria document and their * * comments get relayed pretty much verbatim to relevant editors/WGs. * * As an AD I retain responsibility in defending their position when * * I agree with it. * * Recipients of these reviews are encouraged to reply to me directly * * about perceived successes or failures of this experiment. * ********************************************************************** The following comments were provided by Benjamin Schwartz <firstname.lastname@example.org>: Benjamin would have balloted *DISCUSS* on this document. He wrote: This draft is close to ready, but it contains some elements that are not appropriate for IETF publication or lack IETF consensus. ## Section 1 Typo: “For example the user has a clear expectation of which resolvers have visibility of their query data however this...” -> Add a period before “however”. Inappropriate subject matter: It is an untested area that simply using a DNS resolution service constitutes consent from the user for the operator to process their query data. This is legal speculation, not appropriate for IETF. Strike this sentence. Clarity: Privacy considerations specifically from the perspective of an end user ... are out of scope. This seems confusing as written: surely it is the privacy of end users (and not of resolver operators) that this draft seeks to protect. Please rephrase or omit this disclaimer. ## Section 5.1 Version skew: dprive-rfc7626-bis no longer has a Section 2.4.2 or 2.5.3. ## Section 5.1.2 Clarity: Redirection of traffic to rogue servers does not match the usual definition of “surveillance”. I would suggest adding an explanation of how this active attack is a privacy threat. Presumably you are referring to merely intercepting the user’s DNS queries, as opposed to substituting modified DNS responses in order to monitor post-DNS network activity, but the text is not clear on this distinction. ## Section 188.8.131.52 Current practices: I don’t think either EDNS(0) Keepalive or DNS Stateful Operations is currently in use with DNS-over-TLS, so this recommendation seems too strong for a BCP. For example, this could say “Management of TLS connections as described in RFC 7766. EDNS(0) Keepalive and DNS Stateful Operations may provide additional performance benefits.” Scope: The optimizations here are performance optimizations, which seem out of place in this document. I would suggest focusing the document on “Encrypted DNS Service Privacy Recommendations”, and remove any recommendations related to performance and reliability, which are already well-covered by standards-track RFCs. ## Section 5.2.1 Content: I think there’s a missing mitigation here, which is employed virtually universally among large DNS Privacy deployments: IP erasure. DNS operators typically distinguish between PII-logs, which are retained at most briefly, and non-PII logs, which are retained for a longer period. I believe this is a best practice and worth documenting. ## Section 5.3.1 Document interaction: This section comes awfully close to updating or deprecating ECS, which we do not have IETF consensus for. I think the BCP here should restrict itself to disclosing the server’s ECS behavior and imposed prefix length limit. ## Section 6.1.1 Terminology: “PII” appears here for the first time, and is not defined.
I support Ben's DISCUSS.
Thanks to the document authors, as well as everyone else who contributed to this document for all the work that went into its creation. I have a handful of editorial suggestions that you may wish to take into account prior to publication. (I also have one request and one question in the list below.) I also support the first point of Alissa's discuss, and have elided several comments about Section 5.1.7 from my review below with the expectation that it will be removed. --------------------------------------------------------------------------- §1: > Community insight [or judgment?] about operational practices can > change quickly, and experience shows that a Best Current Practice > (BCP) document about privacy and security is a point-in-time > statement. Readers are advised to seek out any errata or updates > that apply to this document. RFC Errata are intended only to correct documents to reflect what the community believed they should have said at the time of publication (e.g., typographic errors, omissions in state machines), and not to provide updates to reflect later thinking. Please remove "errata or" from this sentence. --------------------------------------------------------------------------- §5.1.1: > o DNS-over-TLS [RFC7858] and [RFC8310]. > > o DoH [RFC8484]. Nit: For the sake of consistency, I would recommend either contracting both of these (e.g., "DoT" and "DoH"), or expanding them both. This same comment applies to the prose in section 5.1.2, as well as the titles of 184.108.40.206 and 220.127.116.11. --------------------------------------------------------------------------- §18.104.22.168: > o Mis-identification of a server by a client e.g. typos in URLs or > authentication domain names [RFC8310]. It's a bit unclear which kind of URLs this is referring to. Based on the proposed mitigation, I suspect it's talking about the use of URLs to configure a DNS server? Consider clarifying the URL's purpose in this text. --------------------------------------------------------------------------- §22.214.171.124: The use of EDNS(0) padding is conspicuous by its absence from this section. Is this intentional? --------------------------------------------------------------------------- §5.1.4: > DNS Privacy Threats: > > o Users may be directed to bogus IP addresses for e.g. websites > where they might reveal personal information to attackers. You might want to consider a different example than websites here. 80% of worldwide website traffic is secured by HTTPS, which means than any such attempts will be prevented by WebPKI certificate mismatches. Notably, this means that the mitigation proposed is of diminished value for DNS servers that are used primarily or exclusively for resolving web server addresses, and the calculus of whether the overhead of implementing DNSSEC in such servers is worth the value it provides may vary radically from that which applies to general-purpose name resolvers. Given the fairly absolute language in the current mitigation section (only three mitigations use something as strong as "must"), it is probably worthwhile adding some text that acknowledges that the value of this mitigation varies depending on the applications that use the DNS service. --------------------------------------------------------------------------- §6.1.1: > 4. Associated entities. Declare any partners, third-party > affiliations, or sources of funding. Having looked at a number of such disclosures recently, I've noticed that it has become fashionable to make such disclosures in the form of "<Corporation> may share information about our customers among the <corporation> family of companies," while eliding information that, for example, one such company is a user-tracking-based advertising network. So, if we're making suggestions for ideal policies, I might suggest something a bit more explicit, like: 4. Associated entities. Declare and explicitly enumerate any partners, third-party affiliations, or sources of funding. --------------------------------------------------------------------------- §B.2: > Since 2006, PowerDNS have included a de-identification tool > Appendix B.2 with their PowerDNS product. There appears to be a spurious "Appendix B.2" on the second line of this paragraph.