dprive S. Dickinson Internet-Draft Sinodun IT Intended status: Best Current Practice R. van Rijswijk-Deij Expires: September 6, 2018 SURFnet bv A. Mankin Salesforce March 5, 2018 Recommendations for DNS Privacy Service Operators draft-dickinson-bcp-op-00 Abstract This document presents operational, policy and security considerations for DNS operators who choose to offer DNS Privacy services including, but not limited to, DNS-over-TLS [RFC7858]. This document also presents a framework to assist writers of DNS Privacy Policy and Practices Statements (analogous to DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements described in [RFC6841]). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 6, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Dickinson, et al. Expires September 6, 2018 [Page 1] Internet-Draft DNS Privacy Service Recommendations March 2018 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Server capabilities to maximise DNS privacy . . . . . . . . . 5 3.1. General capabilities . . . . . . . . . . . . . . . . . . 5 3.2. Client query obfuscation . . . . . . . . . . . . . . . . 5 3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Authentication of DNS privacy services . . . . . . . . . 6 3.4.1. Generation and publication of certificates . . . . . 6 3.4.2. Management of SPKI pins . . . . . . . . . . . . . . . 6 3.4.3. TLSA records . . . . . . . . . . . . . . . . . . . . 6 4. Operational management . . . . . . . . . . . . . . . . . . . 7 4.1. Limitations of using a pure TLS proxy . . . . . . . . . . 7 4.2. Anycast deployments . . . . . . . . . . . . . . . . . . . 7 5. Server data handling . . . . . . . . . . . . . . . . . . . . 7 5.1. Psuedo-anonymisation and de-identification methods . . . 8 5.1.1. ipcipher . . . . . . . . . . . . . . . . . . . . . . 8 5.1.2. Bloom filters . . . . . . . . . . . . . . . . . . . . 8 6. DNS privacy policy and practice statement . . . . . . . . . . 8 6.1. Current privacy statements . . . . . . . . . . . . . . . 8 6.2. Recommended contents of a DPPPS . . . . . . . . . . . . . 8 6.3. Enforcement/accountability . . . . . . . . . . . . . . . 9 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security considerations . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 11 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction [NOTE: This document is submitted to the IETF for initial review and for feedback on the best forum for future versions of this document.] The Domain Name System (DNS) was not originally designed with strong security or privacy mechanisms. [RFC7626] describes the privacy issues associated with the use of the DNS by Internet users including Dickinson, et al. Expires September 6, 2018 [Page 2] Internet-Draft DNS Privacy Service Recommendations March 2018 those related to un-encrypted DNS messages on the wire and DNS 'query log' data maintained on DNS servers. Two documents that provide ways to increase DNS privacy between DNS clients and DNS servers are: o Specification for DNS over Transport Layer Security (TLS) [RFC7858], referred to here as simply 'DNS-over-TLS' o DNS over Datagram Transport Layer Security (DTLS) [RFC8094], referred to here simply as 'DNS-over-DTLS'. Note that this document has the Category of Experimental. Both documents are limited in scope to communications between stub clients and recursive resolvers and the same scope is applied to this document. 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]. Note that [I-D.ietf-dnsop-dns-tcp-requirements] discusses operational requirements for DNS-over-TCP but does not provide specific guidance on DNS privacy protocols. This document includes operational guidance related to [RFC7858] and [RFC8094]. In recent years there has been an increase in the availability of "open" resolvers. Operators of some open resolvers choose to enable protocols which encrypt DNS on the wire to cater for users who are privacy conscious. Whilst protocols that encrypt DNS messages on the wire provide protection against certain attacks, the resolver operator still has (in principle) full visibility of the query data for each user and therefore a trust relationship exists. The ability of the operator to provide a transparent, well documented, and secure privacy service will likely serve as a major differentiating factor for privacy conscious users. More recently the global legislative landscape with regard to personal data collection, retention, and psuedo-anonymisation has seen significant activity with differing requirements active in different jurisdictions. The impact of these changes on data pertaining to the users of Internet Service Providers and specifically DNS open resolvers is not fully understood at the time of writing. It may be in certain cases that these requirement may well conflict with the IETF's end-to-end encryption principles. Dickinson, et al. Expires September 6, 2018 [Page 3] Internet-Draft DNS Privacy Service Recommendations March 2018 This document also attempts to outline options for data handling for operators of DNS privacy services. TODO/QUESTION: Discuss alternative (non-standard) schemes not covered by this document e.g. DNSCrypt, IPsec, VPNs. For example, should the data handling practices be recommended for any service that encrypts DNS/makes claims about DNS data privacy or is that outside the scope of this document? This document also presents a framework to assist writers of DNS Privacy Policy and Practice Statements (DPPPS). These are documents an operator can publish outlining their operational practices and commitments with regard to privacy providing a means for clients to evaluate the privacy properties of a given DNS privacy service. In particular, the framework identifies the elements that should be considered in formulating a DPPPS. It does not, however, define a particular Policy or Practice Statement, nor does it seek to provide legal advice or recommendations as to the contents. Community knowledge 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. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC8174]. o Privacy-enabling DNS server: A DNS server that implements DNS- over-TLS [RFC7858] and may optionally implement DNS-over-DTLS [RFC8094]. The server should also offer at least one of the credentials described in Section 8 of [I-D.ietf-dprive-dtls-and-tls-profiles] and implement the (D)TLS profile described in Section 9 of [I-D.ietf-dprive-dtls-and-tls-profiles]. o DPPPS: DNS Privacy Policy and Practice Statement, see Section 6. o DNS privacy service: The service that is offered via a privacy- enabling DNS server and is documented either in an informal statement of policy and practice with regard to users privacy or a formal DPPPS. Dickinson, et al. Expires September 6, 2018 [Page 4] Internet-Draft DNS Privacy Service Recommendations March 2018 3. Server capabilities to maximise DNS privacy 3.1. General capabilities In addition to Sections 9 and 11.1 of [I-D.ietf-dprive-dtls-and-tls-profiles] DNS privacy services SHOULD offer the following capabilities/options: o QNAME minimisation [RFC7816] o Management of TLS connections to optimise performance for clients using either * [RFC7766] and EDNS(0) Keepalive [RFC7828] and/or * DNS Stateful Operations [I-D.ietf-dnsop-session-signal] o No requirement that clients must use TLS session resumption [RFC5077] (or Domain Name System (DNS) Cookies [RFC7873]) DNS privacy services MAY offer the following capabilities: o DNS privacy service on both port 853 and 443 (to circumvent blocking of port 853) o A .onion [RFC7686] service endpoint o Aggressive Use of DNSSEC-Validated Cache [RFC8198] to reduce the number of queries to authoritative servers to increase privacy. o Run a copy of the root zone on loopback [RFC7706] to avoid making queries to the root servers that might leak information. QUESTION: Should we say anything here about filtering responses or DNSSEC validation e.g. operators SHOULD provide an unfiltered service on an alternative IP address if the 'main' DNS privacy address filters responses? Or simply just to say that the DNS privacy service should not differ from the 'normal' DNS service in terms of such options. 3.2. Client query obfuscation Since queries from recursive resolvers to authoritative servers are performed using cleartext (at the time of writing), resolver services need to consider the extent to which they may be directly leaking information about their client community via these upstream queries and what they can do to mitigate this further. Note, that even when all the relevant techniques described above are employed there may Dickinson, et al. Expires September 6, 2018 [Page 5] Internet-Draft DNS Privacy Service Recommendations March 2018 still be attacks possible, e.g. [Pitfalls-of-DNS-Encryption]. For example, a resolver with a very small community of users risks exposing data in this way and MAY want to obfuscate this traffic by mixing it with 'generated' traffic to make client characterisation harder. 3.3. Availability As a general model of trust between users and service providers DNS privacy services should have high availability. Denying access to an encrypted protocol for DNS queries forces the user to switch providers, fallback to cleartext or accept no DNS service for the outage. 3.4. Authentication of DNS privacy services To enable users to select a 'Strict Privacy' usage profile [I-D.ietf-dprive-dtls-and-tls-profiles] DNS privacy services should provide credentials in the form of either X.509 certificates, SPKI pinsets or TLSA records. This in effect commits the DNS privacy service to a public identity users will trust. Anecdotal evidence to date highlights this requirement as one of the more challenging aspects of running a DNS privacy service as management of such credentials is new to DNS operators. 3.4.1. Generation and publication of certificates It is RECOMMENDED that operators: o Choose a short, memorable authentication name for their service o Automate the generation and publication of certificates o Monitor certificates to prevent accidental expiration of certificates 3.4.2. Management of SPKI pins TODO 3.4.3. TLSA records TODO Dickinson, et al. Expires September 6, 2018 [Page 6] Internet-Draft DNS Privacy Service Recommendations March 2018 4. Operational management 4.1. Limitations of using a pure TLS proxy Some operators may choose to implement DNS-over-TLS using a TLS proxy (e.g. nginx [1] or haproxy [2]) in front of a DNS nameserver because of proven robustness and capacity when handling large numbers of client connections, load balancing capabilities and good tooling. Currently, however, because such proxies typically have no specific handling of DNS as a protocol over TLS or DTLS using them can restrict traffic management at the proxy layer and at the DNS server. For example, all traffic received by a nameserver behind such a proxy will appear to originate from the proxy and DNS techniques such as ACLs or RRL will be hard or impossible to implement in the nameserver. 4.2. Anycast deployments TODO: 5. Server data handling The following are common activities for DNS service operators and in all cases should be minimised or completely avoided if possible for DNS privacy services. If data is retained it should be encrypted and either aggregated, psuedo-anonymised or de-identified whenever possible. o Logging and Monitoring: Only that required to sustain operation of the service and meet regulatory requirements. o Data retention: Data SHOULD be retained for the shortest period deemed operationally feasible. o User tracking: DNS privacy services SHOULD not track users. An exception may be malicious or anomalous use of the service. o Providing data to third-parties (sharing, selling or renting): Operators SHOULD not provide data to third-parties without explicit consent from users (simply using the resolution service itself does not constitute consent). o Access to stored personal data: Access SHOULD be minimised to only those personal who require access to perform operational duties. Dickinson, et al. Expires September 6, 2018 [Page 7] Internet-Draft DNS Privacy Service Recommendations March 2018 5.1. Psuedo-anonymisation and de-identification methods There is active discussion in the space of effective psuedo- anonymisation of personal data in DNS query logs. To-date this has focussed on psuedo-anonymisation of client IP addresses, however there are as yet no standards for this that are unencumbered by patents. This section briefly references some know methods in this space at the time of writing. 5.1.1. ipcipher [ipcipher-spec] is a psuedo-anonymisation technique which encrypts IPv4 and IPv6 addresses such that any address encrypts to a valid address. At the time of writing the specification is under review and may be the subject of a future IETF draft. 5.1.2. Bloom filters There is also on-going work in the area of using Bloom filters as a privacy-enhancing technology for DNS monitoring [DNS-bloom-filter]. The goal of this work is to allow operators to identify so-called Indicators of Compromise (IOCs) originating from specific subnets without storing information about, or be able to monitor the DNS queries of an individual user. 6. DNS privacy policy and practice statement 6.1. Current privacy statements TODO: Compare main elements of Google vs Quad9 vs OpenDNS policies 6.2. Recommended contents of a DPPPS o Policy: This section should explain the policy for gathering and disseminating information collected by the DNS privacy service. * Specify clearly what data (including whether it is aggregated, psuedo-anonymised or de-identified) is * Collected and retained by the operator (and for how long) * Shared with, sold or rented to third-parties * Specify any exceptions to the above, for example malicious or anomalous behaviour * Declare any third-party affiliations or funding Dickinson, et al. Expires September 6, 2018 [Page 8] Internet-Draft DNS Privacy Service Recommendations March 2018 * Whether user DNS data is correlated or combined with any other personal information held by the operator o Practice: This section should explain the current operational practices of the service. * Specify any temporary or permanent deviations from the policy for operational reasons * Provide specific details of which capabilities are provided on which address and ports * Specify the authentication name to be used (if any) * Specify the SPKI pinsets to be used (if any) and policy for rolling keys * Provide a contact email address for the service 6.3. Enforcement/accountability Transparency reports may help with building user trust that operators adhere to their policies and practices. Independent monitoring should be performed where possible of: o ECS, QNAME minimisation, EDNS(0) padding, etc. o Filtering o Uptime 7. IANA considerations None 8. Security considerations TODO: e.g. New issues for DoS defence, server admin policies 9. Acknowledgements Many thanks to John Dickinson for review of and input to the first draft of this document. Thanks to Benno Overeinder and John Todd for discussions on this topic. Dickinson, et al. Expires September 6, 2018 [Page 9] Internet-Draft DNS Privacy Service Recommendations March 2018 10. Changelog draft-dickinson-dprive-bcp-op-00 o Initial commit 11. References 11.1. Normative References [I-D.ietf-dnsop-session-signal] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., Mankin, A., and T. Pusateri, "DNS Stateful Operations", draft-ietf-dnsop-session-signal-05 (work in progress), January 2018. [I-D.ietf-dprive-dtls-and-tls-profiles] Dickinson, S., Gillmor, D., and T. Reddy, "Usage and (D)TLS Profiles for DNS-over-(D)TLS", draft-ietf-dprive- dtls-and-tls-profiles-11 (work in progress), September 2017. [I-D.ietf-dprive-padding-policy] Mayrhofer, A., "Padding Policy for EDNS(0)", draft-ietf- dprive-padding-policy-04 (work in progress), February 2018. [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, . [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, . [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, . [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, . Dickinson, et al. Expires September 6, 2018 [Page 10] Internet-Draft DNS Privacy Service Recommendations March 2018 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/RFC7828, April 2016, . [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, DOI 10.17487/RFC7830, May 2016, . [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, . [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References [DNS-bloom-filter] van Rijswijk-Deij, R., Bomhoff, M., and R. Dolmans, "Let a Thousand Filters Bloom. DNS-Based Threat Monitoring That Respects User Privacy", 2018, < https://tnc18.geant.org/ getfile/3823>. [I-D.ietf-dnsop-dns-tcp-requirements] Kristoff, J. and D. Wessels, "DNS Transport over TCP - Operational Requirements", draft-ietf-dnsop-dns-tcp- requirements-01 (work in progress), November 2017. [ipcipher-spec] Hubert, B., "ipcipher: encrypting IP addresses", 2018, . [Pitfalls-of-DNS-Encryption] Shulman, H., "Pretty Bad Privacy: Pitfalls of DNS Encryption", 2014, . Dickinson, et al. Expires September 6, 2018 [Page 11] Internet-Draft DNS Privacy Service Recommendations March 2018 [RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A Framework for DNSSEC Policies and DNSSEC Practice Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013, . [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 2015, . [RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root Servers by Running One on Loopback", RFC 7706, DOI 10.17487/RFC7706, November 2015, . [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, July 2017, . 11.3. URIs [1] https://nginx.org/ [2] https://www.haproxy.org/ Authors' Addresses Sara Dickinson Sinodun IT Magdalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom Email: sara@sinodun.com Roland M. van Rijswijk-Deij SURFnet bv PO Box 19035 Utrecht 3501 DA Utrecht The Netherlands Email: roland.vanrijswijk@surfnet.nl Dickinson, et al. Expires September 6, 2018 [Page 12] Internet-Draft DNS Privacy Service Recommendations March 2018 Allison Mankin Salesforce Email: allison.mankin@gmail.com Dickinson, et al. Expires September 6, 2018 [Page 13]