idnits 2.17.1 draft-hoffman-dprive-dns-tls-https-latest-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 22, 2014) is 3445 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 (-17) exists of draft-ietf-httpbis-http2-14 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) == Outdated reference: A later version (-06) exists of draft-dukhovni-opportunistic-security-04 -- Obsolete informational reference (is this intentional?): RFC 3205 (Obsoleted by RFC 9205) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft VPN Consortium 4 Intended status: Standards Track October 22, 2014 5 Expires: April 25, 2015 7 Using HTTPS for Privacy Between DNS Stub and Recursive Resolvers 8 draft-hoffman-dprive-dns-tls-https-latest-00 10 Abstract 12 DNS queries and responses can contain information that reveals 13 important information about the person who caused the queries, and it 14 would be better if eavesdroppers were unable to see DNS traffic. 15 This document describes how to use TLS for encrypting DNS traffic 16 between a system acting as a DNS stub resolver and a system acting as 17 a DNS recursive resolver. It defines how to easily wrap DNS queries 18 in HTTP requests and interpret DNS responses in the HTTP respones; 19 the HTTP here is always run under TLS on port 443. 21 Discussion of this draft should take place in the DPRIVE WG. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 25, 2015. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Other Designs . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Specification of Using HTTPS Between a DNS Stub Resolver and 61 a Recursive Resolver . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Design Rationale . . . . . . . . . . . . . . . . . . . . 5 63 2.2. Stub Resolver Policy . . . . . . . . . . . . . . . . . . 6 64 2.3. Privacy Through DNS Forwarders . . . . . . . . . . . . . 6 65 2.4. Use by Authoritative Servers . . . . . . . . . . . . . . 6 66 3. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 4.1. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 7 69 4.2. Media Type . . . . . . . . . . . . . . . . . . . . . . . 7 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 7.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 As described in [I-D.bortzmeyer-dnsop-dns-privacy], there are many 80 reasons why a user or system making a DNS query would like the query 81 and the response to not be seen by others. The best way to make a 82 query and response private is to use encryption, and TLS is a 83 commonly-deployed protocol that provides encryption to clients and 84 servers. This document describes how to use TLS for encrypting DNS 85 traffic between a system acting as a stub resolver and a system 86 acting as a recursive resolver. 88 There is a desire for programs running in Javascript in browsers to 89 be able to make DNS requests, particularly to get DNSSEC-protected 90 responses such as for DANE [RFC6698] queries. The design in this 91 document allows Javascript and other languages and environments that 92 require connections to come from URLs to perform DNS requests. 94 This document defines how to easily wrap DNS queries in HTTP requests 95 and interpret DNS responses in the HTTP respones; the HTTP here is 96 always run under TLS on port 443. Using HTTP-under-TLS as a 97 substrate was chosen for many of the reasons given in [RFC3205]. The 98 specification in this document follows the restrictions of RFC 3205, 99 including using generic HTTP clients and servers, not adding 100 restrictions on HTTP, and so on. It is expected that this protocol 101 would work just fine (maybe even better) under HTTP/2 102 [I-D.ietf-httpbis-http2]. 104 Because there is currently no expectation of privacy for DNS queries, 105 this document defines the use of opportunistic security as described 106 in [I-D.dukhovni-opportunistic-security] for adding privacy for DNS 107 traffic between a stub resolver and a recursive resolver. 109 The protocol described in this document cannot be used by a stub 110 resolver to trust the DNSSEC validation status of responses from a 111 recursive server. Such trust might be described in a different 112 protocol that always uses authenticated TLS, but not the one here. 114 1.1. Other Designs 116 There have been many designs proposed for using TLS to protect DNS 117 traffic between a stub resolver and a recursive resolver. Among them 118 are: 120 o [draft-hzhwm-dprive-start-tls-for-dns] describes DNS over TCP 121 begun on port 53 as normal, but there is an in-band signal to 122 change the transport to TLS. 124 o [draft-hoffman-dprive-dns-tls-alpn] describes DNS over TCP begun 125 on port 443, with ALPN [RFC7301] being used to specify that the 126 DNS protocol will be run after TLS is set up. 128 o [draft-hoffman-dprive-dns-tls-newport] describes DNS over TCP is 129 begun on a port specific to the protocol. 131 (Yet a different design, call DNSCrypt, has a fair amount of 132 deployment. A pointer will be added here for the technical 133 specification of that design if it becomes available.) 135 1.2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED, "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in RFC 140 2119, BCP 14 [RFC2119]. 142 The roles of agents that make DNS requests, and those that give DNS 143 responses have been loosely named over time. Because this protocol 144 is meant to be used between specific types of agents, they need to be 145 defined here. [[ Note: if these are adequately defined in existing 146 RFCs in ways that the community agrees on, it would be better to 147 simply repeat those definitions. ]] 149 Stub resolver: A system that sends DNS queries with the intention of 150 using the answers locally. 152 Authoritative server: A system that responds to DNS queries with 153 information about zones for which it is authoritative. 155 Recursive resolver: A system that receives DNS queries and either 156 responds to those queries from a local cache or sends queries to 157 authoritative servers in order to get the answers to the original 158 queries. These systems are also commonly called "recursive 159 servers". 161 DNS forwarder: A system receives a DNS query from a stub resolver, 162 possibly changes the query, sends the resulting query to a 163 recursive resolver, receives the response from the recursive 164 resolver, possibly changes the response, and sends the resulting 165 response to the stub resolver. [RFC5625] does not give a specific 166 definition for DNS forwarder, but describes in detail what 167 features they need to support. The protocol interfaces for DNS 168 forwarders are exactly the same as those for recursive resolvers 169 (for interactions with DNS stubs) and as those for stub resolvers 170 (for interactions with recursive resolvers). 172 2. Specification of Using HTTPS Between a DNS Stub Resolver and a 173 Recursive Resolver 175 A stub resolver MAY attempt to communicate with a recursive resolver 176 using TLS [RFC5246] over port 443. 178 An https: URI [RFC3986] is resolved. The URI uses the "/.well- 179 known/" prefix defined in [RFC5785]. 181 The URI is marshaled as follows: 183 1. The URI scheme MUST be "https:". (To restate the obvious, the 184 URI scheme MUST NOT be "http:" or any other scheme.) 186 2. The authority MAY be a domain name, but is much more likely to be 187 an IP address. 189 3. A port number MAY be specified, but if it is not present, port 190 443 is assumed. 192 4. The path begins with ".well-known/dns-in-https/". 194 5. The octets in the DNS request (defined in [RFC1035] and all the 195 relevant updates) are converted to base64url encoding from 196 [RFC4648] and appended to the path. 198 The URI is resolved using a standard HTTP client, such as the "curl" 199 or "wget" tools or the libraries that support them. 201 If the HTTP request is successful, the server uses an HTTP 200 202 response and sends back a single part that is of type application/ 203 dns-response. The body of the response is the octets of the DNS 204 response. Note that a DNS request that returns a DNS error is still 205 considered an HTTP request that is successful and should be served 206 with a 200 response. 208 If the request is not successful, the server might return HTTP 209 responses in the 400 or 500 ranges with empty bodies. Note that HTTP 210 response in the 300 range are also possible, such as if the DNS 211 server has moved. 213 For example, a request URI would look as follows (with a line break 214 due to publication limits): 216 https://8.8.8.8/.well-known/dns-in-https/ 217 TN4AAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE= 219 This example is based on a request for the A record for example.com. 220 The set of octets in the query (expressed here in hex notation) is: 222 0x4CDE00000001000000000000076578616D706C6503636F6D0000010001 224 2.1. Design Rationale 226 A recursive resolver SHOULD offer authentication using one or more of 227 the many methods allowed by TLS, and the stub resolver SHOULD 228 authenticate the recursive resolver if it can. However, if the stub 229 resolver cannot authenticate the recursive resolver during TLS setup, 230 the stub resolver SHOULD still complete the handshake in order to 231 achieve encrypted communication. 233 A typical form of authentication for a recursive resolver would be a 234 PKIX [RFC5280] certificate that has a CommonName (CN) that is the IP 235 address that stub resolvers use to connect to it. Note that there 236 are many other standardized types of TLS authentication that can be 237 used, such as raw public keys keys [RFC7250]. 239 The TLS connection is kept up for as long as each party is willing to 240 do so. 242 2.2. Stub Resolver Policy 244 A stub resolver MAY use policy to allow unauthenticated encryption 245 (which can possibly be intercepted by an on-path adversary) or 246 authenticated encryption (which might prevent all DNS resolution if 247 the server does not have correct authentication credentials) when 248 contacting a recursive resolver using this protocol. 250 It is expected that users will want one of the following policies 251 available to them: 253 o The stub resolver MUST achieve authenticated TLS with a recursive 254 server; if that can't be achieved, the stub resolver refuses to 255 send out DNS queries 257 o The stub resolver tries to achieve authenticated TLS with a 258 recursive server; if it cannot achieve authenticated TLS, it tries 259 to achieve unauthenticated TLS; if that can't be achieved, the 260 stub resolver refuses to send out DNS queries 262 o The stub resolver tries to achieve authenticated TLS with a 263 recursive server; if it cannot achieve authenticated TLS, it tries 264 to achieve unauthenticated TLS; if that can't be achieved, the 265 stub resolver uses normal DNS cleartext on port 53 267 o The stub resolver doesn't want to try TLS at all, and uses normal 268 DNS cleartext on port 53 270 2.3. Privacy Through DNS Forwarders 272 A stub resolver cannot tell whether it is sending queries to a 273 recursive resolver or to a DNS forwarder. Therefore, a DNS forwarder 274 that acts as a TLS server for DNS requests SHOULD attempt to use TLS 275 with its upstream resolver(s) to maximize the confidentiality of its 276 stub clients. 278 2.4. Use by Authoritative Servers 280 There is absolutely no expectation that any authoritative server will 281 deploy this protocol. Thus, a DNS recursive resolver that tries to 282 contact an authoritative server on TCP port 443 in hopes of keeping 283 its communication private is probably wasting its time and delaying 284 getting the actual answer over port 53. 286 3. Privacy Considerations 288 This entire document is about improving privacy for DNS requests and 289 responses. 291 4. IANA Considerations 293 4.1. Well-Known URI 295 IANA is requested add the following value to the "Well-Known URIs" 296 registry. That registry is populated by expert review, and such a 297 review will be requested if this document progresses. 299 URI suffix: dns-in-https 300 Change controller: IETF 301 Specification document(s): This document 302 Related information: None 304 4.2. Media Type 306 IANA is requested add the following value to the "Media Types" 307 registry. That registry is populated by expert review, and such a 308 review will be requested as this document progresses. 310 Type name: application 311 Subtype name: dns-response 312 Required parameters: N/A 313 Optional parameters: N/A 314 Encoding considerations: N/A 315 Security considerations: Given in this document 316 Interoperability considerations: N/A 317 Published specification: This document 318 Applications that use this media type: This document 319 Fragment identifier considerations: N/A 320 Additional information: None 321 Person & email address to contact for further information: 322 Paul Hoffman, paul.hoffman@vpnc.org 323 Intended usage: COMMON 324 Restrictions on usage: N/A 325 Author: Paul Hoffman 326 Change controller: IESG 327 Provisional registration? (standards tree only): No 329 5. Security Considerations 331 An adversary who can observe encrypted queries from stub resolvers, 332 and can simultaneously observe the cleartext queries from a recursive 333 resolver to authoritative servers, might be able to associate those 334 two sets of queries and thus ascertain that a particular client asked 335 a particular query. Such observations can be prevented by the 336 recursive resolver already having the answer in its cache. If a 337 recursive resolver has ample room in its cache, it can make the 338 adversary's job harder by refreshing entries in its cache before the 339 TTL on those entries time out, thereby preventing the adversary's 340 ability to associate encrypted queries with cleartext ones. 342 6. Acknowledgements 344 Many people have thought about protecting DNS queries and responses, 345 and various discussions with those people resulted in this document. 347 The following have made significant contributions to this document: 348 Jacob Appelbaum, Carsten Bormann, Tatuya JINMEI, Warren Kumari, and 349 Paul Wouters. 351 7. References 353 7.1. Normative References 355 [I-D.ietf-httpbis-http2] 356 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 357 Protocol version 2", draft-ietf-httpbis-http2-14 (work in 358 progress), July 2014. 360 [RFC1035] Mockapetris, P., "Domain names - implementation and 361 specification", STD 13, RFC 1035, November 1987. 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, March 1997. 366 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 367 Resource Identifier (URI): Generic Syntax", STD 66, RFC 368 3986, January 2005. 370 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 371 Encodings", RFC 4648, October 2006. 373 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 374 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 376 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 377 Uniform Resource Identifiers (URIs)", RFC 5785, April 378 2010. 380 7.2. Informative References 382 [I-D.bortzmeyer-dnsop-dns-privacy] 383 Bortzmeyer, S., "DNS privacy considerations", draft- 384 bortzmeyer-dnsop-dns-privacy-02 (work in progress), April 385 2014. 387 [I-D.dukhovni-opportunistic-security] 388 Dukhovni, V., "Opportunistic Security: Some Protection 389 Most of the Time", draft-dukhovni-opportunistic- 390 security-04 (work in progress), August 2014. 392 [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, 393 RFC 3205, February 2002. 395 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 396 Housley, R., and W. Polk, "Internet X.509 Public Key 397 Infrastructure Certificate and Certificate Revocation List 398 (CRL) Profile", RFC 5280, May 2008. 400 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 401 152, RFC 5625, August 2009. 403 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 404 of Named Entities (DANE) Transport Layer Security (TLS) 405 Protocol: TLSA", RFC 6698, August 2012. 407 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 408 T. Kivinen, "Using Raw Public Keys in Transport Layer 409 Security (TLS) and Datagram Transport Layer Security 410 (DTLS)", RFC 7250, June 2014. 412 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 413 "Transport Layer Security (TLS) Application-Layer Protocol 414 Negotiation Extension", RFC 7301, July 2014. 416 [draft-hoffman-dprive-dns-tls-alpn] 417 Hoffman, P., "Using TLS and ALPN for Privacy Between DNS 418 Stub and Recursive Resolvers", draft-hoffman-dns-tls-alpn 419 , October 2014. 421 [draft-hoffman-dprive-dns-tls-newport] 422 Hoffman, P., "Using TLS on a New Port for Privacy Between 423 DNS Stub and Recursive Resolvers", draft-hoffman-dns-tls- 424 newport , October 2014. 426 [draft-hzhwm-dprive-start-tls-for-dns] 427 Hu, Z., "TLS for DNS: Initiation and Performance 428 Considerations", draft-hzhwm-dprive-start-tls-for-dns , 429 October 2014. 431 Author's Address 433 Paul Hoffman 434 VPN Consortium 436 Email: paul.hoffman@vpnc.org