Internet DRAFT - draft-dickinson-bcp-op
draft-dickinson-bcp-op
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, <https://www.rfc-editor.org/info/rfc5077>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015, <https://www.rfc-
editor.org/info/rfc7626>.
[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,
<https://www.rfc-editor.org/info/rfc7766>.
[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve
Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
<https://www.rfc-editor.org/info/rfc7816>.
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, <https://www.rfc-
editor.org/info/rfc7828>.
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
DOI 10.17487/RFC7830, May 2016, <https://www.rfc-
editor.org/info/rfc7830>.
[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, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
<https://www.rfc-editor.org/info/rfc7873>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017, <https://www.rfc-
editor.org/info/rfc8094>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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,
<https://powerdns.org/ipcipher/>.
[Pitfalls-of-DNS-Encryption]
Shulman, H., "Pretty Bad Privacy: Pitfalls of DNS
Encryption", 2014, <https://www.ietf.org/mail-archive/web/
dns-privacy/current/pdfWqAIUmEl47.pdf>.
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,
<https://www.rfc-editor.org/info/rfc6841>.
[RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use
Domain Name", RFC 7686, DOI 10.17487/RFC7686, October
2015, <https://www.rfc-editor.org/info/rfc7686>.
[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, <https://www.rfc-
editor.org/info/rfc7706>.
[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
July 2017, <https://www.rfc-editor.org/info/rfc8198>.
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]
