idnits 2.17.1 draft-dickinson-doh-dohpe-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The abstract seems to contain references ([I-D.ietf-doh-dns-over-https]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 18, 2018) is 2102 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-14) exists of draft-ietf-doh-dns-over-https-12 ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-06) exists of draft-ietf-dprive-padding-policy-05 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Dickinson 3 Internet-Draft Sinodun IT 4 Intended status: Standards Track W. Toorop 5 Expires: January 19, 2019 NLnet Labs 6 July 18, 2018 8 DoHPE: DoH with Privacy Enhancements 9 draft-dickinson-doh-dohpe-00 11 Abstract 13 This document describes DoHPE (DoH with Privacy Enhancements) - a 14 privacy and anonymity profile for DoH [I-D.ietf-doh-dns-over-https] 15 clients. The profile provides guidelines on the composition of DoH 16 messages, designed to minimize disclosure of identifying information. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 19, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Protocol specification . . . . . . . . . . . . . . . . . . . 4 55 3.1. Selection of DoH server . . . . . . . . . . . . . . . . . 4 56 3.2. HTTPS connections . . . . . . . . . . . . . . . . . . . . 4 57 3.3. HTTP version . . . . . . . . . . . . . . . . . . . . . . 5 58 3.4. HTTP method . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.5. HTTP headers . . . . . . . . . . . . . . . . . . . . . . 5 60 3.5.1. User agent . . . . . . . . . . . . . . . . . . . . . 5 61 3.5.2. Other headers . . . . . . . . . . . . . . . . . . . . 5 62 3.6. Client authentication . . . . . . . . . . . . . . . . . . 5 63 3.7. Other HTTP functionality . . . . . . . . . . . . . . . . 5 64 3.8. Countermeasures to Traffic Analysis . . . . . . . . . . . 5 65 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 66 5. Implementations . . . . . . . . . . . . . . . . . . . . . . . 6 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 68 7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 8.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 The DoH protocol [I-D.ietf-doh-dns-over-https] is currently under 77 development with stated potential use cases of: 79 "... preventing on-path devices from interfering with DNS operations 80 and allowing web applications to access DNS information via existing 81 browser APIs in a safe way consistent with Cross Origin Resource 82 Sharing (CORS)." 84 Whilst DoH has clear benefits in terms of encryption, authentication, 85 traffic obfuscation and ease of implementation, it introduce new 86 privacy concerns when compared with DNS over UDP, TCP or TLS 87 (RFC7858) simply because it introduces a new transport layer (HTTPS) 88 that can contain client identifiers (e.g. user-agent, accept- 89 language) not present in any existing DNS transport. 91 The privacy considerations section of that draft state the following: 93 "The DoH protocol design allows applications to fully leverage the 94 HTTP ecosystem, including features that are not enumerated here. 95 Utilizing the full set of HTTP features enables DoH to be more than 96 an HTTP tunnel, but at the cost of opening up implementations to the 97 full set of privacy considerations of HTTP." 98 In other words a design choice was made with DoH not to add 99 constraints to the protocol on privacy grounds; specific choices of 100 functionality verses privacy are left to the implementation. 102 In the absence of a common standard and with many possible use cases 103 for DoH, different application developers are likely to implement 104 this compromise in different ways. Monitoring entities could then 105 use the differences to identify not only the device but the software 106 originating the DNS queries. A similar problem exists for DHCP 107 clients which [RFC7844] attempts to address. 109 The proposed profile provides a common standard that minimizes 110 information disclosure, including the disclosure of implementation 111 identifiers. Whilst fingerprinting in the TLS layer is of course 112 also possible, minimising the additional differences introduced by 113 HTTPS attempts to provide a DoH profile that has parity with DNS- 114 over-TLS from a privacy/anonymity perspective. 116 One use case for this profile is a client wishing to use DoH to 117 leverage several of the key advantages including: 119 o Encryption and authentication of the connection to the server 121 o Obfuscation of DNS traffic by using HTTPS on port 443 (to 122 preventing on-path devices from interfering with DNS operations) 124 o Ability to optionally use either DNS-over-TLS or DoH servers 125 depending on availability, reachability and latency 127 but to: 129 o introduce the minimum possible privacy concerns compared to e.g. 130 DNS-over-TLS 132 o not 'stand-out' among a DoH client population 134 The cost of this decision is limitations on the HTTPS functionality 135 available to the client which for this use case is considered 136 acceptable. An example of such a client is a system stub resolver 137 that offers multiple transports for DNS or a Tor exit node. 139 One advantage of standardizing this approach is that users of DoHPE 140 clients will have clear privacy expectations which is not necessarily 141 the case with general DoH clients because the choice of balancing 142 functionality against privacy is implementation specific. 144 Whilst a simple model using HTTP CONNECT to set up RFC7858 sessions 145 would be an option given the privacy centric goal of this 146 specification building on top of DoH has several advantages including 147 clients being able to take advantage of media-types defined in future 148 DoH specifications. 150 Two issues need to be taken into account when considering how 151 deployable this profile is: 153 1. Interoperability issues in the absence of certain headers might 154 be expected 156 2. Some HTTPS libraries add several headers by default and so 157 implementors will need to take care to override this behaviour 159 As with DoH, this document focuses on communication between DNS 160 clients (such as operating system stub resolvers) and recursive 161 resolvers. 163 2. Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC8174]. 169 3. Protocol specification 171 The protocol specification for DoHPE is that of DoH 172 [I-D.ietf-doh-dns-over-https] with the guidelines described in the 173 following sections. 175 3.1. Selection of DoH server 177 In order that all connections from a given device appear as similar 178 as possible DoHPE clients SHOULD by default use a system wide setting 179 for the DoH server if one exists and can be discovered. 181 3.2. HTTPS connections 183 DoHPE clients SHOULD send queries over connections used solely for 184 DoHPE ('dedicated DoHPE connections') to avoid mixing with other 185 HTTPS traffic that might contain HTTPS messages with client 186 identifiers. 188 TODO: Consider if DoHPE clients SHOULD expose configuration options 189 for users to select if they are willing to fall back to using 190 existing connections for DoHPE queries if issues are encountered with 191 the use of dedicated DoHPE connections. 193 3.3. HTTP version 195 In order that all DoH connections from a device appear as similar as 196 possible DoHPE clients MUST use HTTP/2 [RFC7540] or later. 198 3.4. HTTP method 200 TODO: Consider specifying that DoHPE clients SHOULD use either GET or 201 POST to increase similarity? 203 3.5. HTTP headers 205 This profile obviously requires clients to include all mandatory 206 headers as specified on [RFC7540] and other applicable 207 specifications. [I-D.ietf-doh-dns-over-https] also makes 208 recommendations about the "Accept" header which apply to this 209 profile. 211 3.5.1. User agent 213 DoHPE clients SHOULD omit the user-agent header. DoHPE clients MAY 214 set this header to 'DoHPE client' if interoperability issues are 215 encountered. 217 3.5.2. Other headers 219 DoHPE clients SHOULD omit all other headers. 221 TODO: Consider if DoHPE clients should expose configuration options 222 so users can choose to include specific headers if interoperability 223 issues are encountered. Note that such configuration could serve to 224 allow fingerprinting. 226 3.6. Client authentication 228 HTTP Cookies MUST NOT be sent by DoHPE clients. 230 3.7. Other HTTP functionality 232 TODO: What else should be considered here? 234 3.8. Countermeasures to Traffic Analysis 236 This section makes suggestions for measures that can reduce the 237 ability of attackers to infer information pertaining to encrypted 238 client queries by other means (e.g., via an analysis of encrypted 239 traffic size or via monitoring of the unencrypted traffic from a DNS 240 recursive resolver to an authoritative server). 242 DoHPE clients and servers SHOULD implement the following relevant DNS 243 extensions: 245 o Extension Mechanisms for DNS (EDNS(0)) padding [RFC7830], which 246 allows encrypted queries and responses to hide their size, making 247 analysis of encrypted traffic harder. 249 Guidance on padding policies for EDNS(0) is provided in 250 [I-D.ietf-dprive-padding-policy]. 252 DoHPE clients SHOULD implement the following relevant DNS extensions: 254 o Privacy election per [RFC7871] ("Client Subnet in DNS Queries"). 255 If a DoHPE client does not include an edns-client-subnet EDNS0 256 option with SOURCE PREFIX-LENGTH set to 0 in a query, the DNS 257 server may potentially leak client address information to the 258 upstream authoritative DNS servers. A DoHPE client ought to be 259 able to inform the DNS resolver that it does not want any address 260 information leaked, and the DNS resolver should honor that 261 request. 263 4. IANA considerations 265 None 267 5. Implementations 269 TODO: Add details of the next release of Stubby that will support 270 DoHPE. 272 6. Acknowledgements 274 Thanks to Stephane Bortzmeyer, Ben Schwartz and many others for 275 initial discussions on this topic. 277 7. Changelog 279 draft-dickinson-doh-dohpe-00 281 o Initial commit 283 8. References 285 8.1. Normative References 287 [I-D.ietf-doh-dns-over-https] 288 Hoffman, P. and P. McManus, "DNS Queries over HTTPS 289 (DoH)", draft-ietf-doh-dns-over-https-12 (work in 290 progress), June 2018. 292 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 293 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 294 DOI 10.17487/RFC7540, May 2015, . 297 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 298 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 299 May 2017, . 301 8.2. Informative References 303 [I-D.ietf-dprive-padding-policy] 304 Mayrhofer, A., "Padding Policy for EDNS(0)", draft-ietf- 305 dprive-padding-policy-05 (work in progress), April 2018. 307 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 308 DOI 10.17487/RFC7830, May 2016, . 311 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 312 Profiles for DHCP Clients", RFC 7844, 313 DOI 10.17487/RFC7844, May 2016, . 316 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 317 Kumari, "Client Subnet in DNS Queries", RFC 7871, 318 DOI 10.17487/RFC7871, May 2016, . 321 Authors' Addresses 323 Sara Dickinson 324 Sinodun IT 325 Magdalen Centre 326 Oxford Science Park 327 Oxford OX4 4GA 328 United Kingdom 330 Email: sara@sinodun.com 331 Willem Toorop 332 NLnet Labs 333 Science Park 400 334 Amsterdam 1098 XH 335 The Netherlands 337 Email: willem@nlnetLabs.nl