idnits 2.17.1 draft-hoffman-dns-last-hop-01.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 date (December 8, 2010) is 4886 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) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 3205 (Obsoleted by RFC 9205) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 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 December 8, 2010 5 Expires: June 11, 2011 7 Wrapping Last-Hop DNS for Traffic Protection 8 draft-hoffman-dns-last-hop-01 10 Abstract 12 DNS queries from one resolver to an upstream resolver are often run 13 over connections with no protection of any kind. The stub resolvers 14 that initiate queries for an application are ofte called "last-hop", 15 and their queries go to trusted recursive resolvers. The connection 16 between last-hop resolvers and their upstream resolver is currently 17 susceptible to both malicious and unintentional alteration that 18 prevents the querying resolver from being sure that the results it 19 receives are valid. Some middleboxes can prevent a stub resolver, 20 even one that does DNSSEC validation, from getting enough information 21 to validate a response. Further, a non-validating stub resolver is 22 susceptible to active attacks in which the results are purposely 23 altered. 25 The protocol described in this document provides a method to avoid 26 these problems and thus make resolution significantly more secure. 27 This protocol can be used between any two DNS resolvers, but the 28 focus of this document is on last-hop resolvers. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on June 11, 2011. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 1. Introduction 63 In the original specification of DNS (which is broadly defined in 64 [RFC1034], [RFC1035], and others), queries travel between a resolver 65 and a server without any cryptographic integrity protection. DNSSEC 66 (which is broadly defined in RFCs 4033, 4034, and 4035 ([RFC4033], 67 [RFC4034], and [RFC4035]) adds integrity protection of the response 68 message and thus allows a validating resolver to verify that a 69 message has not been altered in transit. 71 RFCs 1034, 1035, and 4033 have many definitions that apply to the 72 discussion here. The term "resolver" is defined in RFC 1034. A 73 "stub resolver" is a resolver that sends queries in recursive mode to 74 a recursive resolver, but does not do recursion itself. In the 75 context of these definitions, "security-aware" means supports the 76 EDNS0 message size extension from [RFC2671] and the DO bit from 77 [RFC3225], and supports the RR types and message header bits defined 78 in the DNSSEC documents. A "security-aware resolver" is an entity 79 that acts as a resolver and that understands DNSSEC. Two types of 80 stub resolvers are discussed in this document. A "validating stub 81 resolver" is a security-aware resolver that sends queries in 82 recursive mode but that performs signature validation on its own 83 rather than just blindly trusting an upstream security-aware 84 recursive name server. A "non-validating stub resolver" is a 85 security-aware resolver that trusts one or more security-aware 86 recursive name servers to perform DNSSEC validation on its behalf. 88 In typical deployments of DNS, there is a stub resolver that is the 89 original source of the DNS query. This query usually traverses one 90 or more recursive DNS servers on its way to the authoritative server 91 for the data. DNSSEC provides a mode (using the AD bit) in which a 92 security-aware but non-validating resolver (usually a stub resolver) 93 may trust that the data it receives has been validated, but only if 94 the connection between it and the upstream resolver that applied the 95 AD bit is secured with cryptographic integrity protection. It is 96 currently not clear how useful the AD bit will be in practice, but 97 without a secured connection between the stub resolver and the 98 validating resolver at the next hop, it is certainly useless. 100 A challenge facing deployment of DNSSEC is that non-validating stub 101 resolvers often have no way of trusting their connection to the 102 validating resolver at the next hop. Worse, for a client that wants 103 to do its own validation, some ISPs block or otherwise alter traffic 104 on the DNS port, so that it is not possible to receive an unaltered 105 response that will pass DNSSEC validation. Other challenges include 106 travelling users who are behind firewalls that modify DNS requests 107 and responses, and only allow access to ports 80 and 443. 109 1.1. Known Problems with Intermediaries and Attackers 111 DNS intermediaries have been found to cause a number of tenacious and 112 difficult-to-solve problems. An intermediary might change a query 113 traversing it, might redirect the query to a different resolver, 114 might alter a response coming back to a query, might try to parse a 115 query or response and drop it if the intermediary doesn't understand 116 it, or a combination of two or more of the above. [RFC5625] talks 117 about some of the many ways that intermediaries have been known to 118 make DNS resolution unstable (and, in some cases, unusable). 120 Attackers have shown great creativity in finding ways to spoof DNS 121 responses. [RFC5452] describes some of these, but more are being 122 discovered at a frequent pace. Spoofing does not affect DNS 123 responses that are protected by DNSSEC that are sent to resolvers 124 that validate; note, however, that non-validating resolvers, 125 particularly non-validating stub resolvers, are quite common. Also 126 note that this document only tries to prevent active attacks, and 127 does not attempt to deal with denial-of-service (DoS) attacks on 128 resolvers. 130 1.2. Proposed Solution 132 This document defines a method to tunnel in TLS [RFC5246] DNS traffic 133 that is wrapped in HTTP [RFC2616]. Although these might at first 134 seem like an ugly hack, they achieve the following goals: 136 o Hiding DNS traffic from intermediaries that change DNS requests 137 and/or responses on port 53 139 o Cryptographic integrity protection for DNS responses sent to non- 140 validating resolvers 142 o Easy implementation in resolvers using existing toolkits and 143 software 145 o No changes to the DNS, HTTP, PKIX, or TLS protocols 147 o Does not require that the responding resolvers run DNS protocols 148 such as SIG(0) and TKEY that are open to trivial denial-of-service 149 attacks. 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in RFC 2119 [RFC2119]. 155 2. Description of the Protocol 157 This section defines the a protocol that first wraps encoded DNS in 158 HTTP, then tunnels wrapped DNS in TLS. 160 The following steps are used by the querying resolver to create and 161 send wrapped queries from one DNS resolver to a second resolver: 163 1. Start with the binary query that would have been sent to the 164 second resolver. 166 2. Create a 128-bit nonce. Prepend it to the binary query from the 167 previous step. 169 3. Encode the combined nonce-and-query with base64, as described in 170 Section 4 of [RFC4648]. This results in a string of ASCII 171 characters. 173 4. Create a URI with a path component consisting of "/.well-known/ 174 dnsreq/" prepended to the encoded nonce-and-query. (The "/.well- 175 known/" prefix comes from [RFC5785]; the string "dnsreq" is 176 registered with IANA later in this document.) 178 5. If a TLS session to the second resolver is already set up, that 179 session is reused. If not, start a TLS session on port 443 with 180 the second resolver. The querying resolver MUST verify that the 181 TLS session is set up correctly before continuing. 183 6. Send an HTTP GET request with the URI from the previous step in 184 the TLS tunnel. This request has an empty message body. Wait 185 for the HTTP response. 187 Responding resolvers listen for TLS queries on TCP port 443. As 188 appropriate, they leave the TLS session open to handle further 189 requests from the same client after the HTTP response is sent. 191 The following steps are used by the responding resolver to create and 192 send wrapped responses to wrapped queries that come in from the HTTP 193 GET request: 195 1. Strip off the "/.well-known/dnsreq/" preamble. If that preamble 196 is not present in the request, then the request is for a 197 different service and should be handled by that service. 199 2. The request to process is the remainder after stripping the 200 preamble. Decode the request to process using base64. The first 201 128 bits of the decoded request is a nonce, and the rest is a DNS 202 query. 204 3. Process the DNS request as one would any DNS request, as 205 described in the DNS (and possibly DNSSEC) protocol documents. 206 The result is a binary DNS response 208 4. Prepend the nonce to DNS response from the previous step and 209 encode the resulting nonce-and-response using base64. 211 5. Respond to the HTTP request using a status code of 200, a media 212 type of "text/plain", and the encoded DNS nonce-and-response in 213 the HTTP response body. In order to help prevent overloading of 214 any HTTP cache that may be between the HTTP server and client, 215 the HTTP response SHOULD include a "Cache-Control" general-header 216 field with the "no-store" directive, as described in RFC 2616. 218 The HTTP status code returned in the response is important to the 219 querying resolover. 221 o Every DNS response MUST always be sent with an HTTP status code of 222 200 ("OK"). For example, even if the DNS response that is encoded 223 is SERVFAIL or NXDOMAIN, the HTTP status code is still 200. 224 Another way to look at this is if the HTTP service actually 225 executes a query, the result will have an HTTP status code of 200. 226 This design prevents the protocol from having to state one-by-one 227 which DNS responses are "significant enough" errors to warrant an 228 HTTP status code from the 4xx family. 230 o If the HTTP server knows that it cannot do the above processing, 231 the HTTP response code MUST be 503 ("Service Unavailable"). An 232 example of this would be if the HTTP server is up but that server 233 knows that the DNS resolver service is down or cannot be reached 234 from the HTTP server. 236 o The HTTP server MAY send a status code in the 3xx family if the 237 server has been moved to a different location; however, note that 238 the client might not be able to follow this redirection, 239 particularly if the location is given with a host name instead of 240 an IP address. 242 o Other HTTP-level error conditions (such as malformed request 243 message, unexpected server-side problems, and so on) may yield 244 other responses in the 4xx (client error) and 5xx (server error) 245 range. 247 There are two possible types of HTTP responses, differentiated by the 248 HTTP status code in the response. The originating DNS resolver acts 249 differently for the two types of responses. 251 o If the response has an HTTP status code of 200, the body of the 252 HTTP response contains a single body part that is plain text. 253 Decode the text using base64: the result of decoding is the 128- 254 bit nonce followed by the DNS response. Validate that the nonce 255 received is the same as the nonce that was sent; if not, ignore 256 the response. 258 o If the response has an HTTP status code of anything other than 259 200, the HTTP message body of the response can be ignored, and the 260 only the HTTP status code (and possibly the HTTP status reason) is 261 used by the querying resolver. 263 In order for the resolver to communicate over TLS to the second 264 resolver using this protocol, the querying resolver needs a trust 265 anchor to which the certificate proffered by the TLS server will 266 chain. Without such a trust anchor, the TLS session will not start. 268 To reduce processing stress on the client and server, and to reduce 269 DNS query times, TLS sessions SHOULD be long-lived. Further, for the 270 same reason, TLS clients and servers SHOULD support TLS session 271 resumption [RFC5077]. 273 3. IANA Considerations 275 This document requests a new registration for a well-known URI, as 276 defined in RFC 5785. The registration template is: 278 URI suffix: dnsreq 280 Change controller: IETF (when approved) 282 Specification document(s): This document 284 4. Security Considerations 286 The security considerations for the protocol are the same as those 287 for TLS. 289 It is important to note that the nonce is only used to prevent cached 290 HTTP responses from being served, not to prevent replay attacks in 291 the inner HTTP protocol. If the inner HTTP queries and responses are 292 cached, and the client reuses a nonce with the same DNS query, it 293 could receive an out-of-date response instead of a fresh response. 294 The use of fresh random nonces prevents this problem. 296 5. Acknowledgements 298 The ideas of wrapping DNS in HTTP-in-TLS have been discussed in many 299 places by many people for a long time; the author of this document 300 comes to the discussion quite late. 302 Andrew Sullivan did an early review of this document and contributed 303 some of the text. Julian Reschke gave some good suggestions for the 304 HTTP handling. Suggestions to ditch the HTTP-without-TLS protocol in 305 an earlier draft came from many people. 307 6. References 309 6.1. Normative References 311 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 312 STD 13, RFC 1034, November 1987. 314 [RFC1035] Mockapetris, P., "Domain names - implementation and 315 specification", STD 13, RFC 1035, November 1987. 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, March 1997. 320 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 321 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 322 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 324 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 325 Encodings", RFC 4648, October 2006. 327 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 328 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 330 6.2. Informative References 332 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 333 RFC 2671, August 1999. 335 [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, 336 RFC 3205, February 2002. 338 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 339 RFC 3225, December 2001. 341 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 342 Rose, "DNS Security Introduction and Requirements", 343 RFC 4033, March 2005. 345 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 346 Rose, "Resource Records for the DNS Security Extensions", 347 RFC 4034, March 2005. 349 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 350 Rose, "Protocol Modifications for the DNS Security 351 Extensions", RFC 4035, March 2005. 353 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 354 "Transport Layer Security (TLS) Session Resumption without 355 Server-Side State", RFC 5077, January 2008. 357 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 358 Resilient against Forged Answers", RFC 5452, January 2009. 360 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 361 BCP 152, RFC 5625, August 2009. 363 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 364 Uniform Resource Identifiers (URIs)", RFC 5785, 365 April 2010. 367 Appendix A. Appropriateness of Using HTTP as a Substrate 369 [RFC3205] describes best practices for using HTTP as a substrate, 370 such as is done in this document. The following is an approximate 371 checklist of how this protocol matches those practices. The section 372 numbers are those from RFC 3205. 374 o 2.1: The complexity of HTTP is not significant here because 375 standard clients and servers are used. No new headers or status 376 codes are introduced, and normal HTTP paradigms like content 377 encoding are handled in their standard fashion. 379 o 2.2: The overhead is minimal for the size of DNS requests and 380 responses. 382 o 2.3: The inner HTTP protocol does not expect to add any security 383 to DNS. Authentication of the server in the full protocol is 384 provided by TLS. Authentication of the client in the full 385 protocol is not needed for DNS, although admission control to the 386 server can be achieved in this protocol in the same way that it is 387 for typical DNS, namely by IP address. 389 o 2.4: Compatibility with proxies, firewalls, and NATs is maximized 390 by using TLS on port 443 in the protocol. Even if the HTTP in the 391 inner protocol interacts with caching proxies, the nonce will 392 cause caching proxies to never have repeated queries, and the 393 SHOULD-level directive to include a "Cache-Control" general-header 394 field with the "no-store" directive reduces the chance that HTTP- 395 compliant proxies will be burdened by the high overhead of 396 queries. 398 o 2.5, bullet 1: The payload size is only slightly increased, and 399 DNS queries and response patterns can be similar to those seen on 400 popular web sites. 402 o 2.5, bullet 2: This protocol is not meant to be used by web 403 browsers. 405 o 2.5, bullet 3: Additional authentication is not needed in the 406 inner HTTP protocol, and TLS adds the needed authentication for 407 the full protocol. 409 o 2.5, bullet 4: Current HTTP status codes are fine for this 410 protocol. 412 o 2.5, bullet 5: DNS servers do not normally support HTTP or other 413 public-facing protocols. 415 o 3: The inner HTTP described in the protocol is not a substantially 416 new service. It uses normal HTTP with the only significant 417 restriction being on which response codes are used. 419 o 4: The http: and https: schemes are not expected to be used here. 420 Instead, the HTTP requests that are wrapped in TLS are used 421 directly. 423 o 5, bullet 1: An existing media type is used. 425 o 5, bullet 2: There is no need for multipart or messages when 426 wrapping a DNS response. 428 o 5, bullet 3: Electronic mail is not a consideration here. 430 o 5, bullet 4: There is only one set of semantics for bodies in 431 responses. 433 o 6: The GET method is used. 435 o 7: All existing client and server toolkits should be able to 436 handle the few limitations in the protocol. 438 o 8: HTTP status codes are used as-is, and no new ones are created 439 for the protocol. 441 Author's Address 443 Paul Hoffman 444 VPN Consortium 446 Email: paul.hoffman@vpnc.org