Internet DRAFT - draft-dickinson-doh-dohpe

draft-dickinson-doh-dohpe







Network Working Group                                       S. Dickinson
Internet-Draft                                                Sinodun IT
Intended status: Standards Track                               W. Toorop
Expires: January 19, 2019                                     NLnet Labs
                                                           July 18, 2018


                  DoHPE: DoH with Privacy Enhancements
                      draft-dickinson-doh-dohpe-00

Abstract

   This document describes DoHPE (DoH with Privacy Enhancements) - a
   privacy and anonymity profile for DoH [I-D.ietf-doh-dns-over-https]
   clients.  The profile provides guidelines on the composition of DoH
   messages, designed to minimize disclosure of identifying information.

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 January 19, 2019.

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
   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.



Dickinson & Toorop      Expires January 19, 2019                [Page 1]

Internet-Draft    DoHPE: DoH with Privacy Enhancements         July 2018


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Protocol specification  . . . . . . . . . . . . . . . . . . .   4
     3.1.  Selection of DoH server . . . . . . . . . . . . . . . . .   4
     3.2.  HTTPS connections . . . . . . . . . . . . . . . . . . . .   4
     3.3.  HTTP version  . . . . . . . . . . . . . . . . . . . . . .   5
     3.4.  HTTP method . . . . . . . . . . . . . . . . . . . . . . .   5
     3.5.  HTTP headers  . . . . . . . . . . . . . . . . . . . . . .   5
       3.5.1.  User agent  . . . . . . . . . . . . . . . . . . . . .   5
       3.5.2.  Other headers . . . . . . . . . . . . . . . . . . . .   5
     3.6.  Client authentication . . . . . . . . . . . . . . . . . .   5
     3.7.  Other HTTP functionality  . . . . . . . . . . . . . . . .   5
     3.8.  Countermeasures to Traffic Analysis . . . . . . . . . . .   5
   4.  IANA considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Implementations . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   The DoH protocol [I-D.ietf-doh-dns-over-https] is currently under
   development with stated potential use cases of:

   "... preventing on-path devices from interfering with DNS operations
   and allowing web applications to access DNS information via existing
   browser APIs in a safe way consistent with Cross Origin Resource
   Sharing (CORS)."

   Whilst DoH has clear benefits in terms of encryption, authentication,
   traffic obfuscation and ease of implementation, it introduce new
   privacy concerns when compared with DNS over UDP, TCP or TLS
   (RFC7858) simply because it introduces a new transport layer (HTTPS)
   that can contain client identifiers (e.g.  user-agent, accept-
   language) not present in any existing DNS transport.

   The privacy considerations section of that draft state the following:

   "The DoH protocol design allows applications to fully leverage the
   HTTP ecosystem, including features that are not enumerated here.
   Utilizing the full set of HTTP features enables DoH to be more than
   an HTTP tunnel, but at the cost of opening up implementations to the
   full set of privacy considerations of HTTP."



Dickinson & Toorop      Expires January 19, 2019                [Page 2]

Internet-Draft    DoHPE: DoH with Privacy Enhancements         July 2018


   In other words a design choice was made with DoH not to add
   constraints to the protocol on privacy grounds; specific choices of
   functionality verses privacy are left to the implementation.

   In the absence of a common standard and with many possible use cases
   for DoH, different application developers are likely to implement
   this compromise in different ways.  Monitoring entities could then
   use the differences to identify not only the device but the software
   originating the DNS queries.  A similar problem exists for DHCP
   clients which [RFC7844] attempts to address.

   The proposed profile provides a common standard that minimizes
   information disclosure, including the disclosure of implementation
   identifiers.  Whilst fingerprinting in the TLS layer is of course
   also possible, minimising the additional differences introduced by
   HTTPS attempts to provide a DoH profile that has parity with DNS-
   over-TLS from a privacy/anonymity perspective.

   One use case for this profile is a client wishing to use DoH to
   leverage several of the key advantages including:

   o  Encryption and authentication of the connection to the server

   o  Obfuscation of DNS traffic by using HTTPS on port 443 (to
      preventing on-path devices from interfering with DNS operations)

   o  Ability to optionally use either DNS-over-TLS or DoH servers
      depending on availability, reachability and latency

   but to:

   o  introduce the minimum possible privacy concerns compared to e.g.
      DNS-over-TLS

   o  not 'stand-out' among a DoH client population

   The cost of this decision is limitations on the HTTPS functionality
   available to the client which for this use case is considered
   acceptable.  An example of such a client is a system stub resolver
   that offers multiple transports for DNS or a Tor exit node.

   One advantage of standardizing this approach is that users of DoHPE
   clients will have clear privacy expectations which is not necessarily
   the case with general DoH clients because the choice of balancing
   functionality against privacy is implementation specific.

   Whilst a simple model using HTTP CONNECT to set up RFC7858 sessions
   would be an option given the privacy centric goal of this



Dickinson & Toorop      Expires January 19, 2019                [Page 3]

Internet-Draft    DoHPE: DoH with Privacy Enhancements         July 2018


   specification building on top of DoH has several advantages including
   clients being able to take advantage of media-types defined in future
   DoH specifications.

   Two issues need to be taken into account when considering how
   deployable this profile is:

   1.  Interoperability issues in the absence of certain headers might
       be expected

   2.  Some HTTPS libraries add several headers by default and so
       implementors will need to take care to override this behaviour

   As with DoH, this document focuses on communication between DNS
   clients (such as operating system stub resolvers) and recursive
   resolvers.

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].

3.  Protocol specification

   The protocol specification for DoHPE is that of DoH
   [I-D.ietf-doh-dns-over-https] with the guidelines described in the
   following sections.

3.1.  Selection of DoH server

   In order that all connections from a given device appear as similar
   as possible DoHPE clients SHOULD by default use a system wide setting
   for the DoH server if one exists and can be discovered.

3.2.  HTTPS connections

   DoHPE clients SHOULD send queries over connections used solely for
   DoHPE ('dedicated DoHPE connections') to avoid mixing with other
   HTTPS traffic that might contain HTTPS messages with client
   identifiers.

   TODO: Consider if DoHPE clients SHOULD expose configuration options
   for users to select if they are willing to fall back to using
   existing connections for DoHPE queries if issues are encountered with
   the use of dedicated DoHPE connections.





Dickinson & Toorop      Expires January 19, 2019                [Page 4]

Internet-Draft    DoHPE: DoH with Privacy Enhancements         July 2018


3.3.  HTTP version

   In order that all DoH connections from a device appear as similar as
   possible DoHPE clients MUST use HTTP/2 [RFC7540] or later.

3.4.  HTTP method

   TODO: Consider specifying that DoHPE clients SHOULD use either GET or
   POST to increase similarity?

3.5.  HTTP headers

   This profile obviously requires clients to include all mandatory
   headers as specified on [RFC7540] and other applicable
   specifications.  [I-D.ietf-doh-dns-over-https] also makes
   recommendations about the "Accept" header which apply to this
   profile.

3.5.1.  User agent

   DoHPE clients SHOULD omit the user-agent header.  DoHPE clients MAY
   set this header to 'DoHPE client' if interoperability issues are
   encountered.

3.5.2.  Other headers

   DoHPE clients SHOULD omit all other headers.

   TODO: Consider if DoHPE clients should expose configuration options
   so users can choose to include specific headers if interoperability
   issues are encountered.  Note that such configuration could serve to
   allow fingerprinting.

3.6.  Client authentication

   HTTP Cookies MUST NOT be sent by DoHPE clients.

3.7.  Other HTTP functionality

   TODO: What else should be considered here?

3.8.  Countermeasures to Traffic Analysis

   This section makes suggestions for measures that can reduce the
   ability of attackers to infer information pertaining to encrypted
   client queries by other means (e.g., via an analysis of encrypted
   traffic size or via monitoring of the unencrypted traffic from a DNS
   recursive resolver to an authoritative server).



Dickinson & Toorop      Expires January 19, 2019                [Page 5]

Internet-Draft    DoHPE: DoH with Privacy Enhancements         July 2018


   DoHPE clients and servers SHOULD implement the following relevant DNS
   extensions:

   o  Extension Mechanisms for DNS (EDNS(0)) padding [RFC7830], which
      allows encrypted queries and responses to hide their size, making
      analysis of encrypted traffic harder.

   Guidance on padding policies for EDNS(0) is provided in
   [I-D.ietf-dprive-padding-policy].

   DoHPE clients SHOULD implement the following relevant DNS extensions:

   o  Privacy election per [RFC7871] ("Client Subnet in DNS Queries").
      If a DoHPE client does not include an edns-client-subnet EDNS0
      option with SOURCE PREFIX-LENGTH set to 0 in a query, the DNS
      server may potentially leak client address information to the
      upstream authoritative DNS servers.  A DoHPE client ought to be
      able to inform the DNS resolver that it does not want any address
      information leaked, and the DNS resolver should honor that
      request.

4.  IANA considerations

   None

5.  Implementations

   TODO: Add details of the next release of Stubby that will support
   DoHPE.

6.  Acknowledgements

   Thanks to Stephane Bortzmeyer, Ben Schwartz and many others for
   initial discussions on this topic.

7.  Changelog

   draft-dickinson-doh-dohpe-00

   o  Initial commit

8.  References

8.1.  Normative References







Dickinson & Toorop      Expires January 19, 2019                [Page 6]

Internet-Draft    DoHPE: DoH with Privacy Enhancements         July 2018


   [I-D.ietf-doh-dns-over-https]
              Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", draft-ietf-doh-dns-over-https-12 (work in
              progress), June 2018.

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015, <https://www.rfc-
              editor.org/info/rfc7540>.

   [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>.

8.2.  Informative References

   [I-D.ietf-dprive-padding-policy]
              Mayrhofer, A., "Padding Policy for EDNS(0)", draft-ietf-
              dprive-padding-policy-05 (work in progress), April 2018.

   [RFC7830]  Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
              DOI 10.17487/RFC7830, May 2016, <https://www.rfc-
              editor.org/info/rfc7830>.

   [RFC7844]  Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
              Profiles for DHCP Clients", RFC 7844,
              DOI 10.17487/RFC7844, May 2016, <https://www.rfc-
              editor.org/info/rfc7844>.

   [RFC7871]  Contavalli, C., van der Gaast, W., Lawrence, D., and W.
              Kumari, "Client Subnet in DNS Queries", RFC 7871,
              DOI 10.17487/RFC7871, May 2016, <https://www.rfc-
              editor.org/info/rfc7871>.

Authors' Addresses

   Sara Dickinson
   Sinodun IT
   Magdalen Centre
   Oxford Science Park
   Oxford  OX4 4GA
   United Kingdom

   Email: sara@sinodun.com







Dickinson & Toorop      Expires January 19, 2019                [Page 7]

Internet-Draft    DoHPE: DoH with Privacy Enhancements         July 2018


   Willem Toorop
   NLnet Labs
   Science Park 400
   Amsterdam  1098 XH
   The Netherlands

   Email: willem@nlnetLabs.nl












































Dickinson & Toorop      Expires January 19, 2019                [Page 8]