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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 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, . [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, . [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, . 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]