[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/