idnits 2.17.1 draft-hoffman-dns-tls-stub-02.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 (August 30, 2014) is 3520 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 August 30, 2014 5 Expires: March 3, 2015 7 Using TLS for Privacy Between DNS Stub and Recursive Resolvers 8 draft-hoffman-dns-tls-stub-02 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 provides two alternatives that are 18 based on different design goals. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 3, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Two Designs, At Least For Now . . . . . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Specification of Using TLS Between a Stub Resolver and a 58 Recursive Resolver . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Plan A . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Plan H . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.3. Design Common to Both Plans . . . . . . . . . . . . . . . 5 62 2.4. Stub Resolver Policy . . . . . . . . . . . . . . . . . . 6 63 2.5. Privacy Through DNS Forwarders . . . . . . . . . . . . . 6 64 2.6. Use by Authoritative Servers . . . . . . . . . . . . . . 6 65 3. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 5.1. ALPN Identification Sequence . . . . . . . . . . . . . . 7 69 5.2. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 7 70 5.3. Media Type . . . . . . . . . . . . . . . . . . . . . . . 8 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 8.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 As described in [I-D.bortzmeyer-dnsop-dns-privacy], there are many 81 reasons why a user or system making a DNS query would like the query 82 and the response to not be seen by others. The best way to make a 83 query and response private is to use encryption, and TLS is a 84 commonly-deployed protocol that provides encryption to clients and 85 servers. This document describes how to use TLS for encrypting DNS 86 traffic between a system acting as a stub resolver and a system 87 acting as a recursive resolver. 89 Because there is currently no expectation of privacy for DNS queries, 90 this document defines the use of opportunistic security as described 91 in [I-D.dukhovni-opportunistic-security] for adding privacy for DNS 92 traffic between a stub resolver and a recursive resolver. 94 The protocol described in this document cannot be used by a stub 95 resolver to trust the DNSSEC validation status of responses from a 96 recursive server. Such trust might be described in a different 97 protocol that always uses authenticated TLS, but not the one here. 99 1.1. Two Designs, At Least For Now 101 There are two different designs in this document, called "Plan A" and 102 "Plan H". The author hopes that the IETF community picks just one of 103 the two so that software only need to implement one of the two. The 104 two designs are detailed throughout the document, but introduced here 105 briefly. 107 "Plan A" runs the DNS protocol directly under TLS on port 443. The 108 way that a server knows that the client is going to run DNS instead 109 of other protocols that run on port 443 is by using ALPN [RFC7301] 110 (and thus the "A" in "Plan A"). 112 "Plan H" encapsulates DNS messages in regular HTTP (thus the "H" in 113 "Plan H") that is then run over TLS on port 443. 115 Plan A is simpler to implement than Plan H and should work fine for 116 stub resolvers in operating systems. However, there is a desire for 117 programs running in Javascript in browsers to be able to make DNS 118 requests, particularly to get DNSSEC-protected responses such as for 119 DANE [RFC6698] queries. Plan A will not work for that use case, but 120 Plan H will. 122 1.2. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED, "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in RFC 127 2119, BCP 14 [RFC2119]. 129 The roles of agents that make DNS requests, and those that give DNS 130 responses have been loosely named over time. Because this protocol 131 is meant to be used between specific types of agents, they need to be 132 defined here. [[ Note: if these are adequately defined in existing 133 RFCs in ways that the community agrees on, it would be better to 134 simply repeat those definitions. ]] 136 Stub resolver: A system that sends DNS queries with the intention of 137 using the answers locally. 139 Authoritative server: A system that responds to DNS queries with 140 information about zones for which it is authoritative. 142 Recursive resolver: A system that receives DNS queries and either 143 responds to those queries from a local cache or sends queries to 144 authoritative servers in order to get the answers to the original 145 queries. These systems are also commonly called "recursive 146 servers". 148 DNS forwarder: A system receives a DNS query from a stub resolver, 149 possibly changes the query, sends the resulting query to a 150 recursive resolver, receives the response from the recursive 151 resolver, possibly changes the response, and sends the resulting 152 response to the stub resolver. [RFC5625] does not give a specific 153 definition for DNS forwarder, but describes in detail what 154 features they need to support. The protocol interfaces for DNS 155 forwarders are exactly the same as those for recursive resolvers 156 (for interactions with DNS stubs) and as those for stub resolvers 157 (for interactions with recursive resolvers). 159 2. Specification of Using TLS Between a Stub Resolver and a Recursive 160 Resolver 162 A stub resolver MAY attempt to communicate with a recursive resolver 163 using TLS [RFC5246] over port 443. 165 2.1. Plan A 167 If the recursive resolver responds on port 443, both the client and 168 the server MUST use the ALPN [RFC7301] extension to TLS, and MUST use 169 "dns" as the identification sequence in ALPN. After the TLS 170 connection is established, the client and server communicate using 171 the normal DNS protocol defined in [RFC1035] and all the relevant 172 updates. 174 2.2. Plan H 176 Plan H: An https: URI [RFC3986] is resolved. The URI uses the 177 "/.well-known/" prefix defined in [RFC5785]. 179 The URI is marshaled as follows: 181 1. The URI scheme MUST be "https:". (To restate the obvious, the 182 URI scheme MUST NOT be "http:" or any other scheme.) 184 2. The authority MAY be a domain name, but is much more likely to be 185 an IP address. 187 3. It is unlikely that there will be a port number, meaning that 188 port 443 will be used. 190 4. The path begins with ".well-known/dns-in-https/". 192 5. The octets in the DNS request (defined in [RFC1035] and all the 193 relevant updates) are converted to base64url encoding from 194 [RFC4648] and appended to the path. 196 The URI is resolved using a standard HTTP client, such as the "curl" 197 or "wget" tools or the libraries that support them. 199 If the HTTP request is successful, the server uses an HTTP 200 200 response and sends back a single part that is of type application/ 201 dns-response. The body of the response is the octets of the DNS 202 response. Note that a DNS request that returns a DNS error is still 203 considered an HTTP request that is successful and should be served 204 with a 200 response. 206 If the request is not successful, the server might return HTTP 207 responses in the 400 or 500 ranges with empty bodies. Note that HTTP 208 response in the 300 range are also possible, such as if the DNS 209 server has moved. 211 For example, a request URI would look as follows (with a line break 212 due to publication limits): 214 https://8.8.8.8/.well-known/dns-in-https/ 215 TN4AAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE= 217 This example is based on a request for the A record for example.com. 218 The set of octets in the query is: 220 0x4CDE00000001000000000000076578616D706C6503636F6D0000010001 222 2.3. Design Common to Both Plans 224 A recursive resolver SHOULD offer authentication using one or more of 225 the many methods allowed by TLS, and the stub resolver SHOULD 226 authenticate the recursive resolver if it can. However, if the stub 227 resolver cannot authenticate the recursive resolver during TLS setup, 228 the stub resolver SHOULD still complete the handshake in order to 229 achieve encrypted communication. 231 A typical form of authentication for a recursive resolver would be a 232 PKIX [RFC5280] certificate that has a CommonName (CN) that is the IP 233 address that stub resolvers use to connect to it. Note that there 234 are many other standardized types of TLS authentication that can be 235 used, such as raw public keys keys [RFC7250]. 237 The TLS connection is kept up for as long as each party is willing to 238 do so. 240 2.4. Stub Resolver Policy 242 A stub resolver MAY use policy to allow unauthenticated encryption 243 (which can possibly be intercepted by an on-path adversary) or 244 authenticated encryption (which might prevent all DNS resolution if 245 the server does not have correct authentication credentials) when 246 contacting a recursive resolver using this protocol. 248 It is expected that users will want one of the following policies 249 available to them: 251 o The stub resolver MUST achieve authenticated TLS with a recursive 252 server; if that can't be achieved, the stub resolver refuses to 253 send out DNS queries 255 o The stub resolver tries to achieve authenticated TLS with a 256 recursive server; if it cannot achieve authenticated TLS, it tries 257 to achieve unauthenticated TLS; if that can't be achieved, the 258 stub resolver refuses to send out DNS queries 260 o The stub resolver tries to achieve authenticated TLS with a 261 recursive server; if it cannot achieve authenticated TLS, it tries 262 to achieve unauthenticated TLS; if that can't be achieved, the 263 stub resolver uses normal DNS cleartext on port 53 265 o The stub resolver doesn't want to try TLS at all, and uses normal 266 DNS cleartext on port 53 268 2.5. Privacy Through DNS Forwarders 270 A stub resolver cannot tell whether it is sending queries to a 271 recursive resolver or to a DNS forwarder. Therefore, a DNS forwarder 272 that acts as a TLS server for DNS requests SHOULD attempt to use TLS 273 with its upstream resolver(s) to maximize the confidentiality of its 274 stub clients. 276 2.6. Use by Authoritative Servers 278 There is absolutely no expectation that any authoritative server will 279 deploy this protocol. Thus, a DNS recursive resolver that tries to 280 contact an authoritative server on TCP port 443 in hopes of keeping 281 its communication private is probably wasting its time and delaying 282 getting the actual answer over port 53. 284 3. Design Rationale 286 For Plan A, the MUST-level requirement for ALPN is because a server 287 might host both DNS and secure web services on the same IP address. 289 For Plan H, using HTTP-under-TLS as a substrate was chosen for many 290 of the reasons given in [RFC3205]. Plan H follows the restrictions 291 of RFC 3205, including using generic HTTP clients and servers, not 292 adding restrictions on HTTP, and so on. It is expected that this 293 protocol would work just fine (maybe even better) under HTTP/2 294 [I-D.ietf-httpbis-http2]. 296 A different design is proposed in [I-D.hzhwm-start-tls-for-dns]. 297 There, DNS over TCP is begun on port 53 as normal, but there is an 298 in-band signal to change the transport to TLS. 300 Yet a different design, call DNSCrypt, has a fair amount of 301 deployment. A pointer will be added here for the technical 302 specification of that design if it becomes available. 304 4. Privacy Considerations 306 This entire document is about improving privacy for DNS requests and 307 responses. 309 5. IANA Considerations 311 5.1. ALPN Identification Sequence 313 If Plan A is adopted, IANA is requested add the following value to 314 the "Application-Layer Protocol Negotiation (ALPN) Protocol IDs" 315 registry. That registry is populated by expert review, and such a 316 review will be requested as this document progresses. 318 Protocol Identification Sequence Reference 319 DNS 0x64 0x6e 0x73 ("dns") This document 321 5.2. Well-Known URI 323 If Plan H is adopted, IANA is requested add the following value to 324 the "Well-Known URIs" registry. That registry is populated by expert 325 review, and such a review will be requested as this document 326 progresses. 328 URI suffix: dns-in-https 329 Change controller: IETF 330 Specification document(s): This document 331 Related information: None 333 5.3. Media Type 335 If Plan H is adopted, IANA is requested add the following value to 336 the "Media Types" registry. That registry is populated by expert 337 review, and such a review will be requested as this document 338 progresses. 340 Type name: application 341 Subtype name: dns-response 342 Required parameters: N/A 343 Optional parameters: N/A 344 Encoding considerations: N/A 345 Security considerations: Given in this document 346 Interoperability considerations: N/A 347 Published specification: This document 348 Applications that use this media type: This document 349 Fragment identifier considerations: N/A 350 Additional information: None 351 Person & email address to contact for further information: 352 Paul Hoffman, paul.hoffman@vpnc.org 353 Intended usage: COMMON 354 Restrictions on usage: N/A 355 Author: Paul Hoffman 356 Change controller: IESG 357 Provisional registration? (standards tree only): No 359 6. Security Considerations 361 An adversary who can observe encrypted queries from stub resolvers, 362 and can simultaneously observe the cleartext queries from a recursive 363 resolver to authoritative servers, might be able to associate those 364 two sets of queries and thus ascertain that a particular client asked 365 a particular query. Such observations can be prevented by the 366 recursive resolver already having the answer in its cache. If a 367 recursive resolver has ample room in its cache, it can make the 368 adversary's job harder by refreshing entries in its cache before the 369 TTL on those entries time out, thereby preventing the adversary's 370 ability to associate encrypted queries with cleartext ones. 372 7. Acknowledgements 374 Many people have thought about protecting DNS queries and responses, 375 and various discussions with those people resulted in this document. 377 The following have made significant contributions to this document: 378 Jacob Appelbaum, Carsten Bormann, Tatuya JINMEI, and Paul Wouters. 380 The Plan A proposal in this document would not have been possible 381 without the work done on ALPN and NPN (the predecessor to ALPN). 383 8. References 385 8.1. Normative References 387 [I-D.ietf-httpbis-http2] 388 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 389 Protocol version 2", draft-ietf-httpbis-http2-14 (work in 390 progress), July 2014. 392 [RFC1035] Mockapetris, P., "Domain names - implementation and 393 specification", STD 13, RFC 1035, November 1987. 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, March 1997. 398 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 399 Resource Identifier (URI): Generic Syntax", STD 66, RFC 400 3986, January 2005. 402 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 403 Encodings", RFC 4648, October 2006. 405 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 406 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 408 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 409 Uniform Resource Identifiers (URIs)", RFC 5785, April 410 2010. 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 8.2. Informative References 418 [I-D.bortzmeyer-dnsop-dns-privacy] 419 Bortzmeyer, S., "DNS privacy considerations", draft- 420 bortzmeyer-dnsop-dns-privacy-02 (work in progress), April 421 2014. 423 [I-D.dukhovni-opportunistic-security] 424 Dukhovni, V., "Opportunistic Security: Some Protection 425 Most of the Time", draft-dukhovni-opportunistic- 426 security-04 (work in progress), August 2014. 428 [I-D.hzhwm-start-tls-for-dns] 429 Zi, Z., Zhu, L., Heidemann, J., Mankin, A., and D. 430 Wessels, "Starting TLS over DNS", draft-hzhwm-start-tls- 431 for-dns-01 (work in progress), July 2014. 433 [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, 434 RFC 3205, February 2002. 436 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 437 Housley, R., and W. Polk, "Internet X.509 Public Key 438 Infrastructure Certificate and Certificate Revocation List 439 (CRL) Profile", RFC 5280, May 2008. 441 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 442 152, RFC 5625, August 2009. 444 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 445 of Named Entities (DANE) Transport Layer Security (TLS) 446 Protocol: TLSA", RFC 6698, August 2012. 448 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 449 T. Kivinen, "Using Raw Public Keys in Transport Layer 450 Security (TLS) and Datagram Transport Layer Security 451 (DTLS)", RFC 7250, June 2014. 453 Author's Address 455 Paul Hoffman 456 VPN Consortium 458 Email: paul.hoffman@vpnc.org