idnits 2.17.00 (12 Aug 2021) /tmp/idnits3614/draft-hzhwm-start-tls-for-dns-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A DNS client that receives a response to its initial query using TCP transport that has the TO bit clear MUST not initiate a TLS handshake and SHOULD utilize the existing TCP connection for subsequent queries. DNS clients SHOULD remember server IP addresses that don't support DNS-over-TLS (including TLS handshake failures) and SHOULD NOT request DNS-over-TLS from them for reasonable period. (We suggest 1 hour, or when the client discovers a new resolver.) -- The document date (February 14, 2014) is 3018 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 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Hu 3 Internet-Draft L. Zhu 4 Intended status: Standards Track J. Heidemann 5 Expires: August 18, 2014 USC/Information Sciences 6 Institute 7 A. Mankin 8 D. Wessels 9 Verisign Labs 10 February 14, 2014 12 Starting TLS over DNS 13 draft-hzhwm-start-tls-for-dns-00 15 Abstract 17 This document describes a technique for upgrading a DNS TCP 18 connection to use Transport Layer Security (TLS) over standard ports. 19 Encryption provided by DNS-over-TLS eliminates opportunities for 20 eavesdropping of DNS queries in the network. The proposed mechanism 21 is backwards compatible with clients and servers that are not aware 22 of DNS-over-TLS. 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 August 18, 2014. 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 1. Introduction 58 Today, nearly all DNS queries ([RFC1034] and [RFC1035]) are sent 59 unencrypted, which makes them vulnerable to eavesdropping by an 60 attacker that has access to the network channel, reducing the privacy 61 of the querier. Recent news reports have elevated these concerns, 62 and ongoing efforts are beginning to identify privacy concerns about 63 DNS ([draft-bortzmeyer-dnsop-dns-privacy]). 65 Prior work has addressed some aspects of DNS security, but none 66 addresses privacy between a DNS client and server using standard 67 protocols. DNS Security Extensions (DNSSEC, [RFC4033]) provide 68 _response integrity_ by defining mechanisms to cryptographically sign 69 zones, allowing end-users (or their first-hop resolver) to verify 70 replies are correct. DNSSEC however does nothing to protect request 71 or response privacy. Traditionally, either privacy was not 72 considered a requirement for DNS traffic, or it was assumed that 73 network traffic was sufficiently private, however these perceptions 74 are evolving due to recent events. 76 More recently, DNSCurve [draft-dempsky-dnscurve] defines a method to 77 provide link-level confidentiality and integrity between DNS clients 78 and servers. However, it does so with a new cryptographic protocol 79 and so does not take advantage of TLS. ConfidentialDNS 80 [draft-wijngaards-confidentialdns] and IPSECA 81 [draft-osterweil-dane-ipsec] use opportunistic encryption to provide 82 privacy for DNS queries and responses. However, it is unclear how a 83 client can locate an RR specific to its first-hop resolver. Finally, 84 others have suggested DNS-over-TLS. Recent work suggests DNS-over- 85 TLS ([draft-bortzmeyer-dnsop-privacy-sol]), and the Unbound DNS 86 software [unbound] includes a DNS-over-TLS implementation. However, 87 neither defines methods to negotiate TLS use over an existing 88 connection; unbound instead requires DNS-over-TLS to run on a 89 different port. 91 The mechanism described in this document enables DNS clients and 92 servers to upgrade an existing DNS-over-TCP connection to a DNS-over- 93 TLS connection. It is analogous to STARTTLS [RFC2595] used in SMTP 94 [RFC3207], IMAP [RFC3501] and POP [RFC1939]. 96 This document defines only the protocol extensions necessary to 97 support TLS negotiation. It does not describe how DNS clients might 98 validate server certificates or specify trusted certificate 99 authorities. Solutions for certificate authentication are outside 100 the scope of this document. 102 1.1. Reserved Words 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 2. Protocol Changes 110 Clients and servers indicate their support for, and desire to use, 111 DNS-over-TLS by setting a bit in the Flags field of the EDNS0 112 [RFC6891] OPT meta-RR. The "TLS OK" (TO) bit is defined as the 113 second bit of the third and fourth bytes of the "extended RCODE and 114 flags" portion of the EDNS0 OPT meta-RR, immediately adjacent to the 115 "DNSSEC OK" (DO) bit [RFC4033]: 117 +0 (MSB) +1 (LSB) 118 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 119 0: | EXTENDED-RCODE | VERSION | 120 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 121 2: |DO|TO| Z | 122 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 124 2.1. Use by DNS Clients 126 2.1.1. Sending Queries 128 DNS clients MAY set the TO bit in queries sent using UDP transport to 129 signal their general ability to support DNS-over-TLS. [For 130 discussion: is this a bad idea because ignorant middleboxes might 131 drop the TO=1 UDP queries?] 133 DNS clients MAY set the TO bit in the initial query sent to a server 134 using TCP transport to signal their desire that the TCP connection be 135 upgraded to TLS. DNS clients MUST NOT set the TO bit on subsequent 136 queries when using TCP or TLS transport (to avoid ambiguity). 138 Since the motivation for DNS-over-TLS is to preserve privacy, DNS 139 clients SHOULD use a query that reveals no private information in the 140 initial TO=1 query to a server. To provide a standard "dummy" query, 141 it is RECOMMENDED to send the initial query with RD=0, 142 QNAME="STARTTLS", QCLASS=CH, and QTYPE=TXT ("STARTTLS/CH/TXT") 143 analogous to administrative queries already in widespread use 144 [RFC4892]. 146 After sending the initial TO=1 query using TCP transport, DNS clients 147 MUST wait for the initial response before sending any subsequent 148 queries over the same TCP connection. 150 2.1.2. Receiving Responses 152 A DNS client that receives a response using UDP transport that has 153 the TO bit set MUST handle that response as usual. It MAY record the 154 server's support for DNS-over-TLS and use that information as part of 155 its server selection algorithm in the case where multiple servers are 156 available to service a particular query. [For discussion: UDP is 157 subject to spoofing and a client which depends on TO=1 in a UDP 158 response may be tricked into never upgrading to TLS.] 160 A DNS client that receives a response to its initial query using TCP 161 transport that has the TO bit set MUST immediately initiate a TLS 162 handshake using the procedure described in [RFC5246]. 164 A DNS client that receives a response to its initial query using TCP 165 transport that has the TO bit clear MUST not initiate a TLS handshake 166 and SHOULD utilize the existing TCP connection for subsequent 167 queries. DNS clients SHOULD remember server IP addresses that don't 168 support DNS-over-TLS (including TLS handshake failures) and SHOULD 169 NOT request DNS-over-TLS from them for reasonable period. (We 170 suggest 1 hour, or when the client discovers a new resolver.) 172 2.2. Use by DNS Servers 174 2.2.1. Receiving Queries 176 A DNS server receiving a query over UDP MUST ignore the TO bit. 178 A DNS server receiving a query over an existing TLS connection MUST 179 ignore the TO bit. 181 A DNS server receiving an initial query over TCP that has the TO bit 182 set MAY inform the client it is willing to establish a TLS session, 183 as described in the next section. 185 A DNS server receiving subsequent queries over TCP MUST ignore the TO 186 bit. (A client wishing to start TLS after the initial query MUST 187 open a new TCP connection to do so.) 189 2.2.2. Sending Responses 191 A DNS server sending a response over UDP SHOULD set the TO bit to 192 indicate its general support for DNS-over-TLS, as long as it is 193 willing and able to support a TLS connection with the particular 194 client. 196 A DNS server receiving an initial query over TCP that has the TO bit 197 set MAY set the TO bit in its response. The server MUST then proceed 198 with the TLS handshake protocol. 200 A DNS server receiving a "dummy" STARTTLS/CH/TXT query over TCP MUST 201 respond with RCODE=0 and a TXT RR in the Answer section. Contents of 202 the TXT RR are strictly informative (for humans) and MUST NOT be 203 interpreted by the client software. Recommended TXT RDATA values are 204 "STARTTLS" or "NO_TLS". 206 2.3. Established Sessions 208 After TLS negotiation completes, the connection will be encrypted and 209 is now protected from eavesdropping and normal DNS queries SHOULD 210 take place. 212 Both clients and servers SHOULD follow existing DNS-over-TCP timeout 213 rules, which are often implementation- and situation-dependent. In 214 the absence of any other advice, the RECOMMENDED timeout values are 215 30 seconds for recursive name servers, 60 seconds for clients of 216 recursive name servers, 10 seconds for authoritative name servers, 217 and 20 seconds for clients of authoritative name servers. Current 218 work in this area may assist DNS-over-TLS clients and servers select 219 useful timeout values [draft-wouters-edns-tcp-keepalive] [tdns]. 221 As with current DNS-over-TCP, DNS servers MAY close the connection at 222 any time (e.g., due to resource constraints). As with current DNS- 223 over-TCP, clients MUST handle abrupt closes and be prepared to 224 reestablish connections and/or retry queries. DNS servers SHOULD use 225 the TLS close-notify request to shift TCP TIME-WAIT state to the 226 clients. 228 DNS servers SHOULD enable fast TLS session resumption [RFC5077] to 229 avoid keeping per-client session state. 231 2.4. Middleboxes 233 Middleboxes [RFC3234] may be present in some networks that interfere 234 with normal DNS resolution and create problems for DNS-over-TLS. A 235 DNS client attempting DNS-over-TLS with a middlebox could have one of 236 the following outcomes (as discussed in prior RFCs [RFC3207]): 238 1. The DNS client sends a TO=1 query and receives a TO=0 response. 239 In this case there is no upgrade to TLS and DNS resolution occurs 240 normally, without encryption. 242 2. The DNS client sends a TO=1 query and receives a TO=1 response, 243 but the TLS handshake fails because the server's certificate 244 cannot be authenticated. In this case the client SHOULD close 245 the established connection and fall back to unencrypted DNS for a 246 reasonable period (as discussed in Section 2.1.2). 248 3. The DNS client sends a TO=1 query and receives a TO=1 response, 249 but the middlebox does not understand the TLS negotiation. 250 Middleboxes SHOULD clear TO in replies if they are not prepared 251 to pass through TLS negotiation. Clients SHOULD retry DNS 252 without TO set if negotiation fails, and then retry with TLS 253 after a reasonable period (see Section 2.1.2). 255 4. The DNS client sends a TO=1 query but receives no response at 256 all. The middlebox might be silently dropping the query, despite 257 [RFC6891] stating that the "Z" Flags are to be ignored by 258 receivers. The client SHOULD fall back to normal (unencrypted) 259 DNS for a reasonable period (as discussed in Section 2.1.2). 261 In general, clients that attempt TLS and fail can either fall back on 262 unencrypted DNS, or wait and retry later, depending on their privacy 263 requirements. [For discussion: should IETF recommend defaulting to 264 postpone and retry instead of non-private operation? This is a 265 policy decision.] 267 3. Performance Considerations 269 DNS-over-TLS incurs additional latency at session startup. It also 270 requires additional state (memory) increased processing (CPU). 272 1. Latency: Compared to UDP, DNS-over-TCP requires an additional 273 round-trip-time (RTT) of latency to establish the connection. 274 The TLS handshake adds another two RTTs of latency. Using a 275 single connection for multiple requests amortizes the connection 276 setup costs. Moreover, TLS connection resumption can further 277 reduce the setup delay. 279 2. State: The use of connection-oriented TCP requires keeping 280 additional state in both kernels and applications. TLS has 281 marginal increases in state over TCP alone. The state 282 requirements are of particular concerns on servers with many 283 clients. Smaller timeout values will reduce the number of 284 concurrent connections, and servers can preemptively close 285 connections when resources limits are exceeded. 287 3. Processing: Use of TLS encryption algorithms necessarily results 288 in increased CPU usage. Servers can choose to refuse new DNS- 289 over-TCP clients if processing limits are exceeded. 291 A full performance evaluation is outside the scope of this 292 specification. A more detailed analysis of the performance 293 implications of DNS-over-TLS (and DNS-over-TCP) is discussed in a 294 technical report [tdns]. 296 4. IANA Considerations 298 This document defines a new bit ("TO") in the Flags field of the 299 EDNS0 OPT meta-RR. At the time of approval of this draft in the 300 standards track, as per the IANA Considerations of RFC 6891, IANA is 301 requested to reserve the second leftmost bit of the flags as the TO 302 bit, immediately adjacent to the DNSSEC DO bit, as shown in 303 Section 2. 305 5. Security Considerations 307 The goal of this proposal is to address the security risks that arise 308 because DNS queries may be eavesdropped upon, as described above. 309 There are a number of residual risks that may impact this goal. 311 1. There are known attacks on TLS, such as person-in-the-middle and 312 protocol downgrade. These are general attacks on TLS and not 313 specific to DNS-over-TLS; we refer to the TLS RFCs for discussion 314 of these security issues. 316 2. Any protocol interactions prior to the TLS handshake are 317 performed in the clear and can be modified by a man-in-the-middle 318 attacker. For this reason, clients MAY discard cached 319 information about server capabilities advertised prior to the 320 start of the TLS handshake. 322 3. As with other uses of STARTTLS-upgrade to TLS, the mechanism 323 specified here is susceptible to downgrade attacks, where a 324 person-in-the-middle prevents a successful TLS upgrade. Keeping 325 track of servers known to support TLS (i.e., "pinning") enables 326 clients to detect downgrade attacks. For servers with no 327 connection history, clients may choose to refuse non-TLS DNS, or 328 they may continue without TLS, depending on their privacy 329 requirements. 331 4. This document does not propose new ideas for certificate 332 authentication for TLS in the context of DNS. Several external 333 methods are possible, although each has weaknesses. The current 334 Certificate Authority infrastructure [RFC5280] is used by HTTP/ 335 TLS [RFC2818]. With many trusted CAs, this approach has 336 recognized weaknesses [CA_Compromise]. Some work is underway to 337 partially address these concerns (for example, with certificate 338 pinning [certificate_pinning], but more work is needed. DANE 339 [RFC6698] provides mechanisms to root certificate trust with 340 DNSSEC. That use here must be carefully evaluated to address 341 potential issues in trust recursion. For stub-to-recursive 342 resolver use, certificate authentication is sometimes either easy 343 or nearly impossible. If the recursive resolver is manually 344 configured, its certificate can be authenticated when it is 345 configured. If the recursive resolver is automatically 346 configured (such as with DHCP [RFC2131]), it could use DHCP 347 authentication mechanisms [RFC3118]). 349 Ongoing discussion of opportunistic TLS (connections without CA 350 validation, [draft-hoffman-uta-opportunistic-tls]) may be relevant to 351 DNS-over-TLS. 353 6. Acknowledgements 355 We would like to thank Stephane Bortzmeyer, Brian Haberman, Paul 356 Hoffman, Kim-Minh Kaplan, Bill Manning, George Michaelson, Eric 357 Osterweil and Glen Wiley for reviewing this Internet-draft. 359 7. References 361 7.1. Normative References 363 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 364 STD 13, RFC 1034, November 1987. 366 [RFC1035] Mockapetris, P., "Domain names - implementation and 367 specification", STD 13, RFC 1035, November 1987. 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 373 "Transport Layer Security (TLS) Session Resumption without 374 Server-Side State", RFC 5077, January 2008. 376 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 377 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 379 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 380 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 382 7.2. Informative References 384 [CA_Compromise] 385 Infosec Island Admin, "CA Compromise", January 2012, . 390 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 391 STD 53, RFC 1939, May 1996. 393 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 394 RFC 2131, March 1997. 396 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 397 RFC 2595, June 1999. 399 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 401 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 402 Messages", RFC 3118, June 2001. 404 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 405 Transport Layer Security", RFC 3207, February 2002. 407 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 408 Issues", RFC 3234, February 2002. 410 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 411 4rev1", RFC 3501, March 2003. 413 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 414 Rose, "DNS Security Introduction and Requirements", 415 RFC 4033, March 2005. 417 [RFC4892] Woolf, S. and D. Conrad, "Requirements for a Mechanism 418 Identifying a Name Server Instance", RFC 4892, June 2007. 420 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 421 Housley, R., and W. Polk, "Internet X.509 Public Key 422 Infrastructure Certificate and Certificate Revocation List 423 (CRL) Profile", RFC 5280, May 2008. 425 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 426 of Named Entities (DANE) Transport Layer Security (TLS) 427 Protocol: TLSA", RFC 6698, August 2012. 429 [certificate_pinning] 430 OWASP, "Certificate and Public Key Pinning", . 434 [draft-bortzmeyer-dnsop-dns-privacy] 435 Bortzmeyer, S., "DNS Privacy issues", 436 draft-bortzmeyer-dnsop-dns-privacy-01 (work in progress), 437 November 2013, . 440 [draft-bortzmeyer-dnsop-privacy-sol] 441 Bortzmeyer, S., "Solutions to DNS privacy issues", 442 draft-bortzmeyer-dnsop-privacy-sol-00 (work in progress), 443 December 2013, . 446 [draft-dempsky-dnscurve] 447 Dempsky, M., "DNSCurve", draft-dempsky-dnscurve-01 (work 448 in progress), August 2010, 449 . 451 [draft-hoffman-uta-opportunistic-tls] 452 Hoffman, P., "Opportunistic Encryption Using TLS", 453 draft-hoffman-uta-opportunistic-tls-00 (work in progress), 454 February 2014, . 457 [draft-osterweil-dane-ipsec] 458 Osterweil, E., Wiley, G., Mitchell, D., and A. Newton, 459 "Opportunistic Encryption with DANE Semantics and IPsec: 460 IPSECA", draft-osterweil-dane-ipsec-00 (work in progress), 461 February 2014, 462 . 465 [draft-wijngaards-confidentialdns] 466 Wijngaards, W., "Confidential DNS", 467 draft-wijngaards-dnsop-confidentialdns-00 (work in 468 progress), November 2013, . 471 [draft-wouters-edns-tcp-keepalive] 472 Wouters, P. and J. Abley, "The edns-tcp-keepalive EDNS0 473 Option", draft-wouters-edns-tcp-keepalive-00 (work in 474 progress), October 2013, . 477 [tdns] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A., 478 and N. Somaiya, "T-DNS: Connection-Oriented DNS to Improve 479 Privacy and Security", Technical report ISI-TR-688, 480 Feburary 2014, . 483 [unbound] NLnet Labs, Verisign labs, "Unbound", December 2013, 484 . 486 Authors' Addresses 488 Zi Hu 489 USC/Information Sciences Institute 490 4676 Admiralty Way, Suite 1133 491 Marina del Rey, CA 90292 492 USA 494 Phone: +1 213 587-1057 495 Email: zihu@usc.edu 497 Liang Zhu 498 USC/Information Sciences Institute 499 4676 Admiralty Way, Suite 1133 500 Marina del Rey, CA 90292 501 USA 503 Phone: +1 310 448-8323 504 Email: liangzhu@usc.edu 506 John Heidemann 507 USC/Information Sciences Institute 508 4676 Admiralty Way, Suite 1001 509 Marina del Rey, CA 90292 510 USA 512 Phone: +1 310 822-1511 513 Email: johnh@isi.edu 514 Allison Mankin 515 Verisign Labs 516 12061 Bluemont Way 517 Reston, VA 20190 519 Phone: +1 703 948-3200 520 Email: amankin@verisign.com 522 Duane Wessels 523 Verisign Labs 524 12061 Bluemont Way 525 Reston, VA 20190 527 Phone: +1 703 948-3200 528 Email: dwessels@verisign.com