On Tue, Mar 06, 2018 at 10:42:10AM +0000, Sara Dickinson <s...@sinodun.com> wrote a message of 198 lines which said:
> There is a new draft (very much a placeholder at the moment) that > attempts to start the discussion around Best Practices for Operators > of DNS Privacy Services. It is submitted here for initial review and > for feedback on the best forum for future versions of this > document. I've read draft-dickinson-bcp-op-00. No strong opinion on the best forum to discuss it so, in the mean time: > Other documents that provide further specifications related to DNS > privacy include [I-D.ietf-dprive-dtls-and-tls-profiles], [RFC7830] > and [I-D.ietf-dprive-padding-policy]. RFC 7816 is mentioned later but it comes out of the blue, it would make sense to mention it here. > In recent years there has been an increase in the availability of > "open" resolvers. "Public resolvers" draft-ietf-dnsop-terminology-bis-08: "the term "public resolver" is used more with open resolvers that are meant to be open, as compared to the vast majority of open resolvers that are probably misconfigured to be open" > 3.1. General capabilities Padding (RFC 7830) is not mentioned here (it should). > A .onion [RFC7686] service endpoint I don't understand. You mean a public privacy-wise DNS resolver should be a Tor entry node as well? > o Aggressive Use of DNSSEC-Validated Cache [RFC8198] to reduce the > number of queries to authoritative servers to increase privacy. And NXDOMAIN cut (RFC 8020) as well (specially for the domains without DNSSEC, or with NSEC3+optout). > Should we say anything here about filtering responses or DNSSEC > validation e.g. operators SHOULD provide an unfiltered service on an > alternative IP address I would rephrase it as "operators who filters responses SHOULD also provide an unfiltered service", without mentioning "alternative IP address", because other means are possible (such as a future EDNS option "do not lie"). (There is also the possibility of whitelisting *client* IP addresses, like Cisco OpenDNS does but it is obviously bad for privacy.) > 3.4.2. Management of SPKI pins Is it about generation, security of the private part, or about publication ("operator MUST publish it on a HTTPS Web page")? Or both? > 3.4.3. TLSA records We should just reference here RFC 7671. > 4.2. Anycast deployments "Anycast deployments is possible and useful, but we draw the attention of operators on the fact that it means that, sometimes, IP packets will come in for an unknown TCP connection, or in an unknown DTLS session. The service MUST reply with the appropriate message (RST for TCP) and MUST NOT silently drop such IP packets. They are not malicious, and are normal for an anycast service." > 5. Server data handling After the paragraph on data retention. "One possibility is to have two (or more) sets of data, one with a lot of data, but a very short retention period, intended for daily operations, and one with a longer retention period, but with less data (source IP addresses shortened, for instance), intended for analytics." > TODO: Compare main elements of Google vs Quad9 vs OpenDNS policies Google <https://developers.google.com/speed/public-dns/privacy> Quad9 <https://quad9.net/privacy/> OpenDNS Cannot find. An URL? The link on their page is just to <https://www.cisco.com/c/en/us/about/legal/privacy-full.html>, a general Cisco privacy policy, nothing about DNS. Google policy and Quad9 policy are very close, to the point where I suspect copy-and-paste. Google is more detailed on the retention duration (and they have a temporary/permanent split), Quad9 is more detailed about the sharing (Google apparently does not talk about sharing, not even to claim "we don't share"). > 8. Security considerations Add "There are no _technical_ means for the user of a privacy-enabled DNS resolver to check if the operator follows its published policy. The user must therefore perform his or her assessment, based on knowledge of the operator, legal or social means to enforce compliance, etc." Otherwise, do we recommend or not things like TLS chain extension and TLS raw keys? _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy