idnits 2.17.1 draft-hoffman-dprive-dns-tls-newport-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 3474 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-04 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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 TLS on a New Port for Privacy Between DNS Stub and Recursive 8 Resolvers 9 draft-hoffman-dprive-dns-tls-newport-00 11 Abstract 13 DNS queries and responses can contain information that reveals 14 important information about the person who caused the queries, and it 15 would be better if eavesdroppers were unable to see DNS traffic. 16 This document describes how to use TLS for encrypting DNS traffic 17 between a system acting as a DNS stub resolver and a system acting as 18 a DNS recursive resolver. It defines how to transport DNS queries 19 and responses under TLS on a port that will be assigned when this 20 document is published. 22 Discussion of this draft should take place in the DPRIVE WG. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 25, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Other Designs . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Specification of Using HTTPS Between a DNS Stub Resolver and 62 a Recursive Resolver . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Design Rationale . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Stub Resolver Policy . . . . . . . . . . . . . . . . . . 5 65 2.3. Privacy Through DNS Forwarders . . . . . . . . . . . . . 5 66 2.4. Use by Authoritative Servers . . . . . . . . . . . . . . 5 67 3. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Port Definition . . . . . . . . . . . . . . . . . . . . . 6 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 74 7.2. Informative References . . . . . . . . . . . . . . . . . 7 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 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 This document defines how to transport DNS queries and responses 89 [RFC1035] under TLS on a port that will be assigned when this 90 document is published. This design is probably closest to the 91 original intention of port assignments, but it also restricts the 92 usability of this protocol where middleboxes block unknown or newly- 93 assigned ports. 95 Because there is currently no expectation of privacy for DNS queries, 96 this document defines the use of opportunistic security as described 97 in [I-D.dukhovni-opportunistic-security] for adding privacy for DNS 98 traffic between a stub resolver and a recursive resolver. 100 The protocol described in this document cannot be used by a stub 101 resolver to trust the DNSSEC validation status of responses from a 102 recursive server. Such trust might be described in a different 103 protocol that always uses authenticated TLS, but not the one here. 105 1.1. Other Designs 107 There have been many designs proposed for using TLS to protect DNS 108 traffic between a stub resolver and a recursive resolver. Among them 109 are: 111 o [draft-hzhwm-dprive-start-tls-for-dns] describes DNS over TCP 112 begun on port 53 as normal, but there is an in-band signal to 113 change the transport to TLS. 115 o [draft-hoffman-dprive-dns-tls-https] describes how to easily wrap 116 DNS queries in HTTP requests and interpret DNS responses in the 117 HTTP respones; the HTTP here is always run under TLS on port 443. 119 o [draft-hoffman-dprive-dns-tls-alpn] describes DNS over TCP begun 120 on port 443, with ALPN [RFC7301] being used to specify that the 121 DNS protocol will be run after TLS is set up. 123 (Yet a different design, call DNSCrypt, has a fair amount of 124 deployment. A pointer will be added here for the technical 125 specification of that design if it becomes available.) 127 1.2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED, "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in RFC 132 2119, BCP 14 [RFC2119]. 134 The roles of agents that make DNS requests, and those that give DNS 135 responses have been loosely named over time. Because this protocol 136 is meant to be used between specific types of agents, they need to be 137 defined here. [[ Note: if these are adequately defined in existing 138 RFCs in ways that the community agrees on, it would be better to 139 simply repeat those definitions. ]] 141 Stub resolver: A system that sends DNS queries with the intention of 142 using the answers locally. 144 Authoritative server: A system that responds to DNS queries with 145 information about zones for which it is authoritative. 147 Recursive resolver: A system that receives DNS queries and either 148 responds to those queries from a local cache or sends queries to 149 authoritative servers in order to get the answers to the original 150 queries. These systems are also commonly called "recursive 151 servers". 153 DNS forwarder: A system receives a DNS query from a stub resolver, 154 possibly changes the query, sends the resulting query to a 155 recursive resolver, receives the response from the recursive 156 resolver, possibly changes the response, and sends the resulting 157 response to the stub resolver. [RFC5625] does not give a specific 158 definition for DNS forwarder, but describes in detail what 159 features they need to support. The protocol interfaces for DNS 160 forwarders are exactly the same as those for recursive resolvers 161 (for interactions with DNS stubs) and as those for stub resolvers 162 (for interactions with recursive resolvers). 164 2. Specification of Using HTTPS Between a DNS Stub Resolver and a 165 Recursive Resolver 167 A stub resolver MAY attempt to communicate with a recursive resolver 168 using TLS [RFC5246] over port 443. 170 The protocol in this document runs the DNS protocol directly under 171 TLS on a port that will be defined by IANA when the document is 172 published. 174 2.1. Design Rationale 176 A recursive resolver SHOULD offer authentication using one or more of 177 the many methods allowed by TLS, and the stub resolver SHOULD 178 authenticate the recursive resolver if it can. However, if the stub 179 resolver cannot authenticate the recursive resolver during TLS setup, 180 the stub resolver SHOULD still complete the handshake in order to 181 achieve encrypted communication. 183 A typical form of authentication for a recursive resolver would be a 184 PKIX [RFC5280] certificate that has a CommonName (CN) that is the IP 185 address that stub resolvers use to connect to it. Note that there 186 are many other standardized types of TLS authentication that can be 187 used, such as raw public keys keys [RFC7250]. 189 The TLS connection is kept up for as long as each party is willing to 190 do so. 192 2.2. Stub Resolver Policy 194 A stub resolver MAY use policy to allow unauthenticated encryption 195 (which can possibly be intercepted by an on-path adversary) or 196 authenticated encryption (which might prevent all DNS resolution if 197 the server does not have correct authentication credentials) when 198 contacting a recursive resolver using this protocol. 200 It is expected that users will want one of the following policies 201 available to them: 203 o The stub resolver MUST achieve authenticated TLS with a recursive 204 server; if that can't be achieved, the stub resolver refuses to 205 send out DNS queries 207 o The stub resolver tries to achieve authenticated TLS with a 208 recursive server; if it cannot achieve authenticated TLS, it tries 209 to achieve unauthenticated TLS; if that can't be achieved, the 210 stub resolver refuses to send out DNS queries 212 o The stub resolver tries to achieve authenticated TLS with a 213 recursive server; if it cannot achieve authenticated TLS, it tries 214 to achieve unauthenticated TLS; if that can't be achieved, the 215 stub resolver uses normal DNS cleartext on port 53 217 o The stub resolver doesn't want to try TLS at all, and uses normal 218 DNS cleartext on port 53 220 2.3. Privacy Through DNS Forwarders 222 A stub resolver cannot tell whether it is sending queries to a 223 recursive resolver or to a DNS forwarder. Therefore, a DNS forwarder 224 that acts as a TLS server for DNS requests SHOULD attempt to use TLS 225 with its upstream resolver(s) to maximize the confidentiality of its 226 stub clients. 228 2.4. Use by Authoritative Servers 230 There is absolutely no expectation that any authoritative server will 231 deploy this protocol. Thus, a DNS recursive resolver that tries to 232 contact an authoritative server on TCP with the port number assigned 233 here in hopes of keeping its communication private is probably 234 wasting its time and delaying getting the actual answer over port 53. 236 3. Privacy Considerations 238 This entire document is about improving privacy for DNS requests and 239 responses. 241 4. IANA Considerations 243 4.1. Port Definition 245 IANA is requested add the following value to the "Service Name and 246 Transport Protocol Port Number Registry" registry. That registry is 247 populated by expert review, and such a review will be requested if 248 this document progresses. 250 Service Name DNS-in-TLS 251 Transport Protocol(s) TCP 252 Assignee IESG 253 Contact Paul Hoffman paul.hoffman@vpnc.org 254 Description DNS query-response protocol run under TLS 255 Reference This document 257 5. Security Considerations 259 An adversary who can observe encrypted queries from stub resolvers, 260 and can simultaneously observe the cleartext queries from a recursive 261 resolver to authoritative servers, might be able to associate those 262 two sets of queries and thus ascertain that a particular client asked 263 a particular query. Such observations can be prevented by the 264 recursive resolver already having the answer in its cache. If a 265 recursive resolver has ample room in its cache, it can make the 266 adversary's job harder by refreshing entries in its cache before the 267 TTL on those entries time out, thereby preventing the adversary's 268 ability to associate encrypted queries with cleartext ones. 270 6. Acknowledgements 272 Many people have thought about protecting DNS queries and responses, 273 and various discussions with those people resulted in this document. 275 The following have made significant contributions to this document: 276 Jacob Appelbaum, Carsten Bormann, Tatuya JINMEI, Warren Kumari, and 277 Paul Wouters. 279 7. References 280 7.1. Normative References 282 [RFC1035] Mockapetris, P., "Domain names - implementation and 283 specification", STD 13, RFC 1035, November 1987. 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, March 1997. 288 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 289 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 291 7.2. Informative References 293 [I-D.bortzmeyer-dnsop-dns-privacy] 294 Bortzmeyer, S., "DNS privacy considerations", draft- 295 bortzmeyer-dnsop-dns-privacy-02 (work in progress), April 296 2014. 298 [I-D.dukhovni-opportunistic-security] 299 Dukhovni, V., "Opportunistic Security: Some Protection 300 Most of the Time", draft-dukhovni-opportunistic- 301 security-04 (work in progress), August 2014. 303 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 304 Housley, R., and W. Polk, "Internet X.509 Public Key 305 Infrastructure Certificate and Certificate Revocation List 306 (CRL) Profile", RFC 5280, May 2008. 308 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 309 152, RFC 5625, August 2009. 311 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 312 T. Kivinen, "Using Raw Public Keys in Transport Layer 313 Security (TLS) and Datagram Transport Layer Security 314 (DTLS)", RFC 7250, June 2014. 316 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 317 "Transport Layer Security (TLS) Application-Layer Protocol 318 Negotiation Extension", RFC 7301, July 2014. 320 [draft-hoffman-dprive-dns-tls-alpn] 321 Hoffman, P., "Using TLS and ALPN for Privacy Between DNS 322 Stub and Recursive Resolvers", draft-hoffman-dns-tls-alpn 323 , October 2014. 325 [draft-hoffman-dprive-dns-tls-https] 326 Hoffman, P., "Using HTTPS for Privacy Between DNS Stub and 327 Recursive Resolvers", draft-hoffman-dns-tls-https , 328 October 2014. 330 [draft-hzhwm-dprive-start-tls-for-dns] 331 Hu, Z., "TLS for DNS: Initiation and Performance 332 Considerations", draft-hzhwm-dprive-start-tls-for-dns , 333 October 2014. 335 Author's Address 337 Paul Hoffman 338 VPN Consortium 340 Email: paul.hoffman@vpnc.org