idnits 2.17.1 draft-hoffman-dns-tls-stub-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 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 20, 2014) is 3536 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 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-06) exists of draft-dukhovni-opportunistic-security-03 -- Obsolete informational reference (is this intentional?): RFC 3205 (Obsoleted by RFC 9205) Summary: 1 error (**), 0 flaws (~~), 3 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 20, 2014 5 Expires: February 21, 2015 7 Using TLS for Privacy Between DNS Stub and Recursive Resolvers 8 draft-hoffman-dns-tls-stub-01 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. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 21, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Specification of Using TLS Between a Stub Resolver and a 56 Recursive Resolver . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Stub Resolver Policy . . . . . . . . . . . . . . . . . . 4 58 2.2. Privacy Through DNS Forwarders . . . . . . . . . . . . . 4 59 2.3. Use by Authoritative Servers . . . . . . . . . . . . . . 5 60 3. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 8.2. Informative References . . . . . . . . . . . . . . . . . 6 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 As described in [I-D.bortzmeyer-dnsop-dns-privacy], there are many 73 reasons why a user or system making a DNS query would like the query 74 and the response to not be seen by others. The best way to make a 75 query and response private is to use encryption, and TLS is a 76 commonly-deployed protocol that provides encryption to clients and 77 servers. This document describes how to use TLS for encrypting DNS 78 traffic between a system acting as a stub resolver and a system 79 acting as a recursive resolver. 81 Because there is currently no expectation of privacy for DNS queries, 82 this document defines the use of opportunistic security as described 83 in [I-D.dukhovni-opportunistic-security] for adding privacy for DNS 84 traffic between a stub resolver and a recursive resolver. 86 The protocol described in this document cannot be used by a stub 87 resolver to trust the DNSSEC validation status of responses from a 88 recursive server. Such trust might be described in a different 89 protocol that always uses authenticated TLS, but not the one here. 91 1.1. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED, "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in RFC 96 2119, BCP 14 [RFC2119]. 98 The roles of agents that make DNS requests, and those that give DNS 99 responses have been loosely named over time. Because this protocol 100 is meant to be used between specific types of agents, they need to be 101 defined here. [[ Note: if these are adequately defined in existing 102 RFCs in ways that the community agrees on, it would be better to 103 simply repeat those definitions. ]] 105 Stub resolver: A system that sends DNS queries with the intention of 106 using the answers locally. 108 Authoritative server: A system that responds to DNS queries with 109 information about zones for which it is authoritative. 111 Recursive resolver: A system that receives DNS queries and either 112 responds to those queries from a local cache or sends queries to 113 authoritative servers in order to get the answers to the original 114 queries. These systems are also commonly called "recursive 115 servers". 117 DNS forwarder: A system receives a DNS query from a stub resolver, 118 possibly changes the query, sends the resulting query to a 119 recursive resolver, receives the response from the recursive 120 resolver, possibly changes the response, and sends the resulting 121 response to the stub resolver. [RFC5625] does not give a specific 122 definition for DNS forwarder, but describes in detail what 123 features they need to support. The protocol interfaces for DNS 124 forwarders are exactly the same as those for recursive resolvers 125 (for interactions with DNS stubs) and as those for stub resolvers 126 (for interactions with recursive resolvers). 128 2. Specification of Using TLS Between a Stub Resolver and a Recursive 129 Resolver 131 A stub resolver MAY attempt to communicate with a recursive resolver 132 using TLS [RFC5246] over port 443. If the recursive resolver 133 responds on port 443, both the client and the server MUST use the 134 ALPN [RFC7301] extension to TLS, and MUST use "dns" as the 135 identification sequence in ALPN. After the TLS connection is 136 established, the client and server communicate using the normal DNS 137 protocol defined in [RFC1035] and all the relevant updates. 139 A recursive resolver SHOULD offer authentication using one or more of 140 the many methods allowed by TLS, and the stub resolver SHOULD 141 authenticate the recursive resolver if it can. However, if the stub 142 resolver cannot authenticate the recursive resolver during TLS setup, 143 the stub resolver SHOULD still complete the handshake in order to 144 achieve encrypted communication. 146 A typical form of authentication for a recursive resolver would be a 147 PKIX [RFC5280] certificate that has a CommonName (CN) that is the IP 148 address that stub resolvers use to connect to it. Note that there 149 are many other standardized types of TLS authentication that can be 150 used, such as raw public keys keys [RFC7250]. 152 2.1. Stub Resolver Policy 154 A stub resolver MAY use policy to allow unauthenticated encryption 155 (which can possibly be intercepted by an on-path adversary) or 156 authenticated encryption (which might prevent all DNS resolution if 157 the server does not have correct authentication credentials) when 158 contacting a recursive resolver using this protocol. 160 It is expected that users will want one of the following policies 161 available to them: 163 o The stub resolver MUST achieve authenticated TLS with a recurive 164 server; if that can't be achieved, the stub resolver refuses to 165 send out DNS queries 167 o The stub resolver tries to achieve authenticated TLS with a 168 recurive server; if it cannot achieve authenticated TLS, it tries 169 to achieve unauthenticated TLS; if that can't be achieved, the 170 stub resolver refuses to send out DNS queries 172 o The stub resolver tries to achieve authenticated TLS with a 173 recurive server; if it cannot achieve authenticated TLS, it tries 174 to achieve unauthenticated TLS; if that can't be achieved, the 175 stub resolver uses normal DNS cleartext on port 53 177 o The stub resolver doesn't want to try TLS at all, and uses normal 178 DNS cleartext on port 53 180 2.2. Privacy Through DNS Forwarders 182 A stub resolver cannot tell whether it is sending queries to a 183 recursive resolver or to a DNS forwarder. Therefore, a DNS forwarder 184 that acts as a TLS server for DNS requests SHOULD attempt to use TLS 185 with its upstream resolver(s) to maximize the confidentiality of its 186 stub clients. 188 2.3. Use by Authoritative Servers 190 There is absolutely no expectation that any authoritative server will 191 deploy this protocol. Thus, a DNS recursive resolver that tries to 192 contact an authoritative server on TCP port 443 in hopes of keeping 193 its communication private is probably wasting its time and delaying 194 getting the actual answer over port 53. 196 3. Design Rationale 198 The MUST-level requirement for ALPN is because a server might host 199 both DNS and secure web services on the same IP address. ALPN was 200 chosen instead of wrapping DNS in HTTP because restrictions in 201 [RFC3205] make doing DNS-over-HTTP fragile, while sending DNS through 202 a TLS tunnel is trivial. 204 A different design is proposed in [I-D.hzhwm-start-tls-for-dns]. 205 There, DNS over TCP is begun on port 53 as normal, but there is an 206 in-band signal to change the transport to TLS. 208 Yet a different design, call DNSCrypt, has a fair amount of 209 deployment. A pointer will be added here for the technical 210 specification of that design if it becomes available. 212 4. Privacy Considerations 214 This entire document is about improving privacy for DNS requests and 215 responses. 217 5. IANA Considerations 219 IANA is requested add the following value to the "Application-Layer 220 Protocol Negotiation (ALPN) Protocol IDs" registry. That registry is 221 populated by expert review, and such a review will be requested as 222 this document progresses. 224 Protocol Identification Sequence Reference 225 DNS 0x64 0x6e 0x73 ("dns") This document 227 6. Security Considerations 229 An adversary who can observe encrypted queries from stub resolvers, 230 and can simultaneously observe the cleartext queries from a recursive 231 resolver to authoritative servers, might be able to associate those 232 two sets of queries and thus ascertain that a particular client asked 233 a particular query. Such observations can be prevented by the 234 recursive resolver already having the answer in its cache. If a 235 recursive resolver has ample room in its cache, it can make the 236 adversary's job harder by refreshing entries in its cache before the 237 TTL on those entries time out, thereby preventing the adversary's 238 ability to associate encrypted queries with cleartext ones. 240 7. Acknowledgements 242 Many people have thought about protecting DNS queries and responses, 243 and various discussions with those people resulted in this document. 245 The following have made significant contributions to this document: 246 Jacob Appelbaum, Carsten Bormann, Tatuya JINMEI, and Paul Wouters. 248 The proposal in this document would not have been possible without 249 the work done on ALPN and NPN (the predecessor to ALPN). 251 8. References 253 8.1. Normative References 255 [RFC1035] Mockapetris, P., "Domain names - implementation and 256 specification", STD 13, RFC 1035, November 1987. 258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 259 Requirement Levels", BCP 14, RFC 2119, March 1997. 261 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 262 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 264 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 265 "Transport Layer Security (TLS) Application-Layer Protocol 266 Negotiation Extension", RFC 7301, July 2014. 268 8.2. Informative References 270 [I-D.bortzmeyer-dnsop-dns-privacy] 271 Bortzmeyer, S., "DNS privacy considerations", draft- 272 bortzmeyer-dnsop-dns-privacy-02 (work in progress), April 273 2014. 275 [I-D.dukhovni-opportunistic-security] 276 Dukhovni, V., "Opportunistic Security: Some Protection 277 Most of the Time", draft-dukhovni-opportunistic- 278 security-03 (work in progress), August 2014. 280 [I-D.hzhwm-start-tls-for-dns] 281 Zi, Z., Zhu, L., Heidemann, J., Mankin, A., and D. 282 Wessels, "Starting TLS over DNS", draft-hzhwm-start-tls- 283 for-dns-01 (work in progress), July 2014. 285 [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, 286 RFC 3205, February 2002. 288 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 289 Housley, R., and W. Polk, "Internet X.509 Public Key 290 Infrastructure Certificate and Certificate Revocation List 291 (CRL) Profile", RFC 5280, May 2008. 293 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 294 152, RFC 5625, August 2009. 296 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 297 T. Kivinen, "Using Raw Public Keys in Transport Layer 298 Security (TLS) and Datagram Transport Layer Security 299 (DTLS)", RFC 7250, June 2014. 301 Author's Address 303 Paul Hoffman 304 VPN Consortium 306 Email: paul.hoffman@vpnc.org