idnits 2.17.1 draft-hoffman-dprive-dns-tls-alpn-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 3471 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 and ALPN for Privacy Between DNS Stub and Recursive Resolvers 8 draft-hoffman-dprive-dns-tls-alpn-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 transport DNS queries 18 and responses under TLS on port 443 using ALPN. 20 Discussion of this draft should take place in the DPRIVE WG. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 25, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Other Designs . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Specification of Using HTTPS Between a DNS Stub Resolver and 60 a Recursive Resolver . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Design Rationale . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Stub Resolver Policy . . . . . . . . . . . . . . . . . . 5 63 2.3. Privacy Through DNS Forwarders . . . . . . . . . . . . . 5 64 2.4. Use by Authoritative Servers . . . . . . . . . . . . . . 5 65 3. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. ALPN Identification Sequence . . . . . . . . . . . . . . 6 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 7.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 As described in [I-D.bortzmeyer-dnsop-dns-privacy], there are many 78 reasons why a user or system making a DNS query would like the query 79 and the response to not be seen by others. The best way to make a 80 query and response private is to use encryption, and TLS is a 81 commonly-deployed protocol that provides encryption to clients and 82 servers. This document describes how to use TLS for encrypting DNS 83 traffic between a system acting as a stub resolver and a system 84 acting as a recursive resolver. 86 This document defines how to transport DNS [RFC1035] queries and 87 responses under TLS on port 443 using ALPN [RFC7301]. Using ALPN for 88 this allows the use of the commonly-allowed port 443 while not 89 confusing any HTTP servers that might be running under TLS. 91 Because there is currently no expectation of privacy for DNS queries, 92 this document defines the use of opportunistic security as described 93 in [I-D.dukhovni-opportunistic-security] for adding privacy for DNS 94 traffic between a stub resolver and a recursive resolver. 96 The protocol described in this document cannot be used by a stub 97 resolver to trust the DNSSEC validation status of responses from a 98 recursive server. Such trust might be described in a different 99 protocol that always uses authenticated TLS, but not the one here. 101 1.1. Other Designs 103 There have been many designs proposed for using TLS to protect DNS 104 traffic between a stub resolver and a recursive resolver. Among them 105 are: 107 o [draft-hzhwm-dprive-start-tls-for-dns] describes DNS over TCP 108 begun on port 53 as normal, but there is an in-band signal to 109 change the transport to TLS. 111 o [draft-hoffman-dprive-dns-tls-https] describes how to easily wrap 112 DNS queries in HTTP requests and interpret DNS responses in the 113 HTTP respones; the HTTP here is always run under TLS on port 443. 115 o [draft-hoffman-dprive-dns-tls-newport] describes DNS over TCP is 116 begun on a port specific to the protocol. 118 (Yet a different design, call DNSCrypt, has a fair amount of 119 deployment. A pointer will be added here for the technical 120 specification of that design if it becomes available.) 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 HTTPS Between a DNS Stub Resolver and a 160 Recursive Resolver 162 A stub resolver MAY attempt to communicate with a recursive resolver 163 using TLS [RFC5246] over port 443. 165 The protocol in this document runs the DNS protocol directly under 166 TLS on port 443. The way that a server knows that the client is 167 going to run DNS instead of other protocols that run on port 443 is 168 by using ALPN [RFC7301]. 170 If the recursive resolver responds on port 443, both the client and 171 the server MUST use the ALPN [RFC7301] extension to TLS, and MUST use 172 "dns" as the identification sequence in ALPN. After the TLS 173 connection is established, the client and server communicate using 174 the normal DNS protocol defined in [RFC1035] and all the relevant 175 updates. 177 The MUST-level requirement for ALPN is because a server might host 178 both DNS and secure web services on the same IP address. 180 2.1. Design Rationale 182 A recursive resolver SHOULD offer authentication using one or more of 183 the many methods allowed by TLS, and the stub resolver SHOULD 184 authenticate the recursive resolver if it can. However, if the stub 185 resolver cannot authenticate the recursive resolver during TLS setup, 186 the stub resolver SHOULD still complete the handshake in order to 187 achieve encrypted communication. 189 A typical form of authentication for a recursive resolver would be a 190 PKIX [RFC5280] certificate that has a CommonName (CN) that is the IP 191 address that stub resolvers use to connect to it. Note that there 192 are many other standardized types of TLS authentication that can be 193 used, such as raw public keys keys [RFC7250]. 195 The TLS connection is kept up for as long as each party is willing to 196 do so. 198 2.2. Stub Resolver Policy 200 A stub resolver MAY use policy to allow unauthenticated encryption 201 (which can possibly be intercepted by an on-path adversary) or 202 authenticated encryption (which might prevent all DNS resolution if 203 the server does not have correct authentication credentials) when 204 contacting a recursive resolver using this protocol. 206 It is expected that users will want one of the following policies 207 available to them: 209 o The stub resolver MUST achieve authenticated TLS with a recursive 210 server; if that can't be achieved, the stub resolver refuses to 211 send out DNS queries 213 o The stub resolver tries to achieve authenticated TLS with a 214 recursive server; if it cannot achieve authenticated TLS, it tries 215 to achieve unauthenticated TLS; if that can't be achieved, the 216 stub resolver refuses to send out DNS queries 218 o The stub resolver tries to achieve authenticated TLS with a 219 recursive server; if it cannot achieve authenticated TLS, it tries 220 to achieve unauthenticated TLS; if that can't be achieved, the 221 stub resolver uses normal DNS cleartext on port 53 223 o The stub resolver doesn't want to try TLS at all, and uses normal 224 DNS cleartext on port 53 226 2.3. Privacy Through DNS Forwarders 228 A stub resolver cannot tell whether it is sending queries to a 229 recursive resolver or to a DNS forwarder. Therefore, a DNS forwarder 230 that acts as a TLS server for DNS requests SHOULD attempt to use TLS 231 with its upstream resolver(s) to maximize the confidentiality of its 232 stub clients. 234 2.4. Use by Authoritative Servers 236 There is absolutely no expectation that any authoritative server will 237 deploy this protocol. Thus, a DNS recursive resolver that tries to 238 contact an authoritative server on TCP port 443 in hopes of keeping 239 its communication private is probably wasting its time and delaying 240 getting the actual answer over port 53. 242 3. Privacy Considerations 244 This entire document is about improving privacy for DNS requests and 245 responses. 247 4. IANA Considerations 249 4.1. ALPN Identification Sequence 251 IANA is requested add the following value to the "Application-Layer 252 Protocol Negotiation (ALPN) Protocol IDs" registry. That registry is 253 populated by expert review, and such a review will be requested if 254 this document progresses. 256 Protocol Identification Sequence Reference 257 DNS 0x64 0x6e 0x73 ("dns") This document 259 5. Security Considerations 261 An adversary who can observe encrypted queries from stub resolvers, 262 and can simultaneously observe the cleartext queries from a recursive 263 resolver to authoritative servers, might be able to associate those 264 two sets of queries and thus ascertain that a particular client asked 265 a particular query. Such observations can be prevented by the 266 recursive resolver already having the answer in its cache. If a 267 recursive resolver has ample room in its cache, it can make the 268 adversary's job harder by refreshing entries in its cache before the 269 TTL on those entries time out, thereby preventing the adversary's 270 ability to associate encrypted queries with cleartext ones. 272 6. Acknowledgements 274 Many people have thought about protecting DNS queries and responses, 275 and various discussions with those people resulted in this document. 277 The following have made significant contributions to this document: 278 Jacob Appelbaum, Carsten Bormann, Tatuya JINMEI, Warren Kumari, and 279 Paul Wouters. 281 7. References 282 7.1. Normative References 284 [RFC1035] Mockapetris, P., "Domain names - implementation and 285 specification", STD 13, RFC 1035, November 1987. 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, March 1997. 290 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 291 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 293 7.2. Informative References 295 [I-D.bortzmeyer-dnsop-dns-privacy] 296 Bortzmeyer, S., "DNS privacy considerations", draft- 297 bortzmeyer-dnsop-dns-privacy-02 (work in progress), April 298 2014. 300 [I-D.dukhovni-opportunistic-security] 301 Dukhovni, V., "Opportunistic Security: Some Protection 302 Most of the Time", draft-dukhovni-opportunistic- 303 security-04 (work in progress), August 2014. 305 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 306 Housley, R., and W. Polk, "Internet X.509 Public Key 307 Infrastructure Certificate and Certificate Revocation List 308 (CRL) Profile", RFC 5280, May 2008. 310 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 311 152, RFC 5625, August 2009. 313 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 314 T. Kivinen, "Using Raw Public Keys in Transport Layer 315 Security (TLS) and Datagram Transport Layer Security 316 (DTLS)", RFC 7250, June 2014. 318 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 319 "Transport Layer Security (TLS) Application-Layer Protocol 320 Negotiation Extension", RFC 7301, July 2014. 322 [draft-hoffman-dprive-dns-tls-https] 323 Hoffman, P., "Using HTTPS for Privacy Between DNS Stub and 324 Recursive Resolvers", draft-hoffman-dns-tls-https , 325 October 2014. 327 [draft-hoffman-dprive-dns-tls-newport] 328 Hoffman, P., "Using TLS on a New Port for Privacy Between 329 DNS Stub and Recursive Resolvers", draft-hoffman-dns-tls- 330 newport , October 2014. 332 [draft-hzhwm-dprive-start-tls-for-dns] 333 Hu, Z., "TLS for DNS: Initiation and Performance 334 Considerations", draft-hzhwm-dprive-start-tls-for-dns , 335 October 2014. 337 Author's Address 339 Paul Hoffman 340 VPN Consortium 342 Email: paul.hoffman@vpnc.org