idnits 2.17.1 draft-ietf-dprive-dns-over-tls-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 11, 2015) is 3114 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) == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-5966bis-02 ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-edns-tcp-keepalive-02 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5966 (Obsoleted by RFC 7766) -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 4 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: April 13, 2016 USC/Information Sciences 6 Institute 7 A. Mankin 8 D. Wessels 9 Verisign Labs 10 P. Hoffman 11 ICANN 12 October 11, 2015 14 DNS over TLS: Initiation and Performance Considerations 15 draft-ietf-dprive-dns-over-tls-01 17 Abstract 19 This document describes the use of TLS to provide privacy for DNS. 20 Encryption provided by TLS eliminates opportunities for eavesdropping 21 and on-path tampering with DNS queries in the network, such as 22 discussed in RFC 7258. In addition, this document specifies two 23 usage profiles for DNS-over-TLS and provides advice on performance 24 considerations to minimize overhead from using TCP and TLS with DNS. 26 Note: this document was formerly named 27 draft-ietf-dprive-start-tls-for-dns. Its name has been changed to 28 better describe the mechanism now used. Please refer to working 29 group archives under the former name for history and previous 30 discussion. [RFC Editor: please remove this paragraph prior to 31 publication] 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 13, 2016. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Establishing and Managing DNS-over-TLS Sessions . . . . . . . 4 70 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 4 71 3.2. TLS Handshake and Authentication . . . . . . . . . . . . . 4 72 3.3. Transmitting and Receiving Messages . . . . . . . . . . . 5 73 3.4. Connection Reuse, Close and Reestablishment . . . . . . . 5 74 4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . . 6 75 4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 7 76 4.2. Pre-Deployed Profile . . . . . . . . . . . . . . . . . . . 7 77 5. Performance Considerations . . . . . . . . . . . . . . . . . . 8 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 79 7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . . 9 80 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 81 8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 86 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 12 87 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 90 12.2. Informative References . . . . . . . . . . . . . . . . . . 14 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 Today, nearly all DNS queries [RFC1034], [RFC1035] are sent 96 unencrypted, which makes them vulnerable to eavesdropping by an 97 attacker that has access to the network channel, reducing the privacy 98 of the querier. Recent news reports have elevated these concerns, 99 and recent IETF work has specified privacy considerations for DNS 100 [RFC7626]. 102 Prior work has addressed some aspects of DNS security, but until 103 recently there has been little work on privacy between a DNS client 104 and server. DNS Security Extensions (DNSSEC), [RFC4033] provide 105 _response integrity_ by defining mechanisms to cryptographically sign 106 zones, allowing end-users (or their first-hop resolver) to verify 107 replies are correct. By intention, DNSSEC does not protect request 108 and response privacy. Traditionally, either privacy was not 109 considered a requirement for DNS traffic, or it was assumed that 110 network traffic was sufficiently private, however these perceptions 111 are evolving due to recent events [RFC7258]. 113 Other work that has offered the potential to encrypt between DNS 114 clients and servers includes DNSCurve [dempsky-dnscurve], 115 ConfidentialDNS [I-D.confidentialdns] and IPSECA [I-D.ipseca]. In 116 addition to the present draft, the DPRIVE working group has recently 117 adopted a DNS-over-DTLS [draft-ietf-dprive-dnsodtls] proposal. 119 This document describes using DNS-over-TLS on a well-known port and 120 also offers advice on performance considerations to minimize 121 overheads from using TCP and TLS with DNS. 123 Initiation of DNS-over-TLS is very straightforward. By establishing 124 a connection over a well-known port, clients and servers expect and 125 agree to negotiate a TLS session to secure the channel. Deployment 126 will be gradual. Not all servers will support DNS-over-TLS and the 127 well-known port might be blocked by some firewalls. Clients will be 128 expected to keep track of servers that support TLS and those that 129 don't. Clients and servers will adhere to the TLS implementation 130 recommendations and security considerations of [RFC7525]. 132 The protocol described here works for any DNS client to server 133 communication using DNS-over-TCP. That is, it may be used for 134 queries and responses between stub clients and recursive servers as 135 well as between recursive clients and authoritative servers. 137 This document describes two profiles in Section 4 providing different 138 levels of assurance of privacy: an opportunistic privacy profile and 139 a pre-deployed profile. 141 An earlier version of this document described a technique for 142 upgrading a DNS-over-TCP connection to a DNS-over-TLS session with, 143 essentially, "STARTTLS for DNS". To simplify the protocol, this 144 document now only uses a well-known port to specify TLS use, omitting 145 the upgrade approach. The upgrade approach no longer appears in this 146 document, which now focuses exclusively on the use of a well-known 147 port for DNS-over-TLS. 149 2. Reserved Words 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 3. Establishing and Managing DNS-over-TLS Sessions 157 3.1. Session Initiation 159 A DNS server that supports DNS-over-TLS SHOULD listen for and accept 160 TCP connections on port 853. 162 DNS clients desiring privacy from DNS-over-TLS from a particular 163 server SHOULD establish a TCP connection to port 853 on the server. 164 Upon successful establishment of the TCP connection, client and 165 server SHOULD immediately initiate a TLS handshake using the 166 procedure described in [RFC5246]. 168 DNS clients SHOULD remember server IP addresses that don't support 169 DNS-over-TLS, including timeouts, connection refusals, and TLS 170 handshake failures, and not request DNS-over-TLS from them for a 171 reasonable period (such as one hour per server). DNS clients 172 following a pre-deployed privacy profile MAY be more aggressive about 173 retrying DNS-over-TLS connection failures. 175 3.2. TLS Handshake and Authentication 177 Once the DNS client succeeds in connecting via TCP on the well-known 178 port for DNS-over-TLS, it proceeds with the TLS handshake [RFC5246], 179 following the best practices specified in [RFC7525]). 181 The client will then authenticate the certificate, if required. DNS- 182 over-TLS does not propose new ideas for certificate authentication. 183 Depending on the privacy profile in use Section 4, the DNS client may 184 choose not to require authentication of the certificate, or it may 185 make use of a certificate that is part of the Certificate Authority 186 infrastructure [RFC5280] authenticated in the manner of HTTP/TLS 188 [RFC2818]. DANE [RFC6698] provides mechanisms to root certificate 189 trust with DNSSEC. The DNS queries in DANE authentication of the 190 certificate for DNS-over-TLS MAY be in the clear to avoid trust 191 recursion. 193 After TLS negotiation completes, the connection will be encrypted and 194 is now protected from eavesdropping. At this point, normal DNS 195 queries SHOULD take place. 197 3.3. Transmitting and Receiving Messages 199 All messages (requests and responses) in the established TLS session 200 MUST use the two-octet length field described in Section 4.2.2 of 201 [RFC1035]. For reasons of efficiency, DNS clients and servers SHOULD 202 transmit the two-octet length field, and the message described by 203 that length field, to the TCP layer at the same time (e.g., in a 204 single "write" system call) to make it more likely that all the data 205 will be transmitted in a single TCP segment 206 ([I-D.ietf-dnsop-5966bis], Section 8). 208 In order to minimize latency, clients SHOULD pipeline multiple 209 queries over a TLS session. When a DNS client sends multiple queries 210 to a server, it should not wait for an outstanding reply before 211 sending the next query ([I-D.ietf-dnsop-5966bis], Section 6.2.1.1). 213 Since pipelined responses can arrive out-of-order, clients MUST match 214 responses to outstanding queries using the ID field, query name, 215 type, and class. Failure by clients to properly match responses to 216 outstanding queries can have serious consequences for 217 interoperability ([I-D.ietf-dnsop-5966bis], Section 7). 219 3.4. Connection Reuse, Close and Reestablishment 221 For DNS clients that use library functions such as "getaddrinfo()" 222 and "gethostbyname()", current implementations are known to open and 223 close TCP connections each DNS call. To avoid excess TCP 224 connections, each with a single query, clients SHOULD reuse a single 225 TCP connection to the recursive resolver. Alternatively they may 226 prefer to use UDP to a DNS-over-TLS enabled caching resolver on the 227 same machine that then uses a system-wide TCP connection to the 228 recursive resolver. 230 In order to amortize TCP and TLS connection setup costs, clients and 231 servers SHOULD NOT immediately close a connection after each 232 response. Instead, clients and servers SHOULD reuse existing 233 connections for subsequent queries as long as they have sufficient 234 resources. In some cases, this means that clients and servers may 235 need to keep idle connections open for some amount of time. 237 Proper management of established and idle connections is important to 238 the healthy operation of a DNS server. An implementor of DNS-over- 239 TLS SHOULD follow best practices for DNS-over-TCP, as described in 240 [I-D.ietf-dnsop-5966bis]. Failure to do so may lead to resource 241 exhaustion and denial-of-service. 243 Whereas client and server implementations from the [RFC1035] era are 244 known to have poor TCP connection management, this document 245 stipulates that successful negotiation of TLS indicates the 246 willingness of both parties to keep idle DNS connections open, 247 independent of timeouts or other recommendations for DNS-over-TCP 248 without TLS. In other words, software implementing this protocol is 249 assumed to support idle, persistent connections and be prepared to 250 manage multiple, potentially long-lived TCP connections. 252 This document does not make specific recommendations for timeout 253 values on idle connections. Clients and servers should reuse and/or 254 close connections depending on the level of available resources. 255 Timeouts may be longer during periods of low activity and shorter 256 during periods of high activity. Current work in this area may also 257 assist DNS-over-TLS clients and servers select useful timeout values 258 [I-D.edns-tcp-keepalive] [tdns]. 260 Clients and servers that keep idle connections open MUST be robust to 261 termination of idle connection by either party. As with current DNS- 262 over-TCP, DNS servers MAY close the connection at any time (perhaps 263 due to resource constraints). As with current DNS-over-TCP, clients 264 MUST handle abrupt closes and be prepared to reestablish connections 265 and/or retry queries. 267 When reestablishing a DNS-over-TCP connection that was terminated, as 268 discussed in [I-D.ietf-dnsop-5966bis], TCP Fast Open [RFC7413] is of 269 benefit. DNS servers SHOULD enable fast TLS session resumption 270 [RFC5077] and this SHOULD be used when reestablishing connections. 272 When closing a connection, DNS servers SHOULD use the TLS close- 273 notify request to shift TCP TIME-WAIT state to the clients. 274 Additional requirements and guidance for optimizing DNS-over-TCP are 275 provided by [RFC5966], [I-D.ietf-dnsop-5966bis]. 277 4. Usage Profiles 279 This protocol provides flexibility to accommodate several different 280 use cases. Two usage profiles are defined here to identify specific 281 design points in performance and privacy. Other profiles are 282 possible but are outside the scope of this document. 284 4.1. Opportunistic Privacy Profile 286 For opportunistic privacy, analogous to SMTP opportunistic encryption 287 [RFC7435] one does not require privacy, but one desires privacy when 288 possible. 290 With opportunistic privacy, a client might learn of a TLS-enabled 291 recursive DNS resolver from an untrusted source (such as DHCP while 292 roaming), it might or might not validate the TLS certificate. These 293 choices maximize availability and performance, but they leave the 294 client vulnerable to on-path attacks that remove privacy. 296 Opportunistic privacy can be used by any current client, but it only 297 provides guaranteed privacy when there are no on-path active 298 attackers. 300 4.2. Pre-Deployed Profile 302 For pre-deployed privacy, the DNS client has one or more trusted 303 recursive DNS providers. This profile provides strong privacy 304 guarantees to the user. 306 With pre-deployed privacy, a client retains a copy of the TLS 307 certificate (and/or other authentication credentials as appropriate) 308 and IP address of each provider. The client will only use DNS 309 servers for which this information has been pre-configured. The 310 possession of a trusted, pre-deployed TLS certificate allows the 311 client to detect person-in-the-middle and downgrade attacks. 313 With pre-deployed privacy, the DNS client MUST signal to the user 314 when none of the designated DNS servers are available, and MUST NOT 315 provide DNS service until at least one of the designated DNS servers 316 becomes available. 318 The designated DNS provider may be temporarily unavailable when 319 configuring a network. For example, for clients on networks that 320 require authentication through web-based login, such authentication 321 may rely on DNS interception and spoofing. Techniques such as those 322 used by DNSSEC-trigger [dnssec-trigger] MAY be used during network 323 configuration, with the intent to transition to the designated DNS 324 provider after authentication. The user MUST be alerted that the DNS 325 is not private during such bootstrap. 327 Methods for pre-deployment of the designated DNS provider are outside 328 the scope of this document. In corporate settings, such information 329 may be provided at system installation. 331 5. Performance Considerations 333 DNS-over-TLS incurs additional latency at session startup. It also 334 requires additional state (memory) and increased processing (CPU). 336 1. Latency: Compared to UDP, DNS-over-TCP requires an additional 337 round-trip-time (RTT) of latency to establish a TCP connection. 338 TCP Fast Open [RFC7413] can eliminate that RTT when information 339 exists from prior connections. The TLS handshake adds another 340 two RTTs of latency. Clients and servers should support 341 connection keepalive (reuse) and out-of-order processing to 342 amortize connection setup costs. Fast TLS connection resumption 343 [RFC5077] further reduces the setup delay and avoids the DNS 344 server keeping per-client session state. TLS False Start 345 [draft-ietf-tls-falsestart] can also lead to a latency reduction 346 in certain situations. 348 2. State: The use of connection-oriented TCP requires keeping 349 additional state at the server in both the kernel and 350 application. The state requirements are of particular concern on 351 servers with many clients, although memory-optimized TLS can add 352 only modest state over TCP. Smaller timeout values will reduce 353 the number of concurrent connections, and servers can 354 preemptively close connections when resource limits are exceeded. 356 3. Processing: Use of TLS encryption algorithms results in slightly 357 higher CPU usage. Servers can choose to refuse new DNS-over-TLS 358 clients if processing limits are exceeded. 360 4. Number of connections: To minimize state on DNS servers and 361 connection startup time, clients SHOULD minimize creation of new 362 TCP connections. Use of a local DNS request aggregator (a 363 particular type of forwarder) allows a single active DNS-over-TLS 364 connection from any given client computer to its server. 365 Additional guidance can be found in [I-D.ietf-dnsop-5966bis]. 367 A full performance evaluation is outside the scope of this 368 specification. A more detailed analysis of the performance 369 implications of DNS-over-TLS (and DNS-over-TCP) is discussed in 370 [tdns] and [I-D.ietf-dnsop-5966bis]. 372 6. IANA Considerations 374 IANA is requested to add the following value to the "Service Name and 375 Transport Protocol Port Number Registry" registry in the System 376 Range. The registry for that range requires IETF Review or IESG 377 Approval [RFC6335] and such a review was requested using the Early 378 Allocation process [RFC7120] for the well-known TCP port in this 379 document. 381 We further recommend that IANA reserve the same port number over UDP 382 for the proposed DNS-over-DTLS protocol [draft-ietf-dprive-dnsodtls]. 384 IANA responded to the early allocation request with the following 385 TEMPORARY assignment: 387 Service Name domain-s 388 Port Number 853 389 Transport Protocol(s) TCP/UDP 390 Assignee IETF DPRIVE Chairs 391 Contact Paul Hoffman 392 Description DNS query-response protocol run over TLS/DTLS 393 Reference This document 395 The TEMPORARY assignment expires 2016-10-08. IANA is requested to 396 make the assigmnent permanent upon publication of this document as an 397 RFC. 399 7. Design Evolution 401 [Note to RFC Editor: please do not remove this section prior to 402 publication as it may be useful to future Foo-over-TLS efforts] 404 Earlier versions of this document proposed an upgrade-based approach 405 to establishing a TLS session. The client would signal its interest 406 in TLS by setting a "TLS OK" bit in the EDNS0 flags field. A server 407 would signal its acceptance by responding with the TLS OK bit set. 409 Since we assume the client doesn't want to reveal (leak) any 410 information prior to securing the channel, we proposed the use of a 411 "dummy query" that clients could send for this purpose. The proposed 412 query name was STARTTLS, query type TXT, and query class CH. 414 The TLS OK signaling approach has both advantages and disadvantages. 415 One important advantage is that clients and servers could negotiate 416 TLS. If the server is too busy, or doesn't want to provide TLS 417 service to a particular client, it can respond negatively to the TLS 418 probe. An ancillary benefit is that servers could collect 419 information on adoption of DNS-over-TLS (via the TLS OK bit in 420 queries) before implementation and deployment. Another anticipated 421 advantage is the expectation that DNS-over-TLS would work over port 422 53. That is, no need to "waste" another port and deploy new firewall 423 rules on middleboxes. 425 However, at the same time, there was uncertainty whether or not 426 middleboxes would pass the TLS OK bit, given that the EDNS0 flags 427 field has been unchanged for many years. Another disadvantage is 428 that the TLS OK bit may make downgrade attacks easy and 429 indistinguishable from broken middleboxes. From a performance 430 standpoint, the upgrade-based approach had the disadvantage of 431 requiring 1xRTT additional latency for the dummy query. 433 Following this proposal, DNS-over-DTLS was proposed separately. DNS- 434 over-DTLS claimed it could work over port 53, but only because a non- 435 DTLS server interprets a DNS-over-DTLS query as a response. That is, 436 the non-DTLS server observes the QR flag set to 1. While this 437 technically works, it seems unfortunate and perhaps even undesirable. 439 DNS over both TLS and DTLS can benefit from a single well-known port 440 and avoid extra latency and mis-interpreted queries as responses. 442 8. Implementation Status 444 [Note to RFC Editor: please remove this section and reference to RFC 445 6982 prior to publication.] 447 This section records the status of known implementations of the 448 protocol defined by this specification at the time of posting of this 449 Internet-Draft, and is based on a proposal described in RFC 6982. 450 The description of implementations in this section is intended to 451 assist the IETF in its decision processes in progressing drafts to 452 RFCs. Please note that the listing of any individual implementation 453 here does not imply endorsement by the IETF. Furthermore, no effort 454 has been spent to verify the information presented here that was 455 supplied by IETF contributors. This is not intended as, and must not 456 be construed to be, a catalog of available implementations or their 457 features. Readers are advised to note that other implementations may 458 exist. 460 According to RFC 6982, "this will allow reviewers and working groups 461 to assign due consideration to documents that have the benefit of 462 running code, which may serve as evidence of valuable experimentation 463 and feedback that have made the implemented protocols more mature. 464 It is up to the individual working groups to use this information as 465 they see fit". 467 8.1. Unbound 469 The Unbound recursive name server software added support for DNS- 470 over-TLS in version 1.4.14. The unbound.conf configuration file has 471 the following configuration directives: ssl-port, ssl-service-key, 472 ssl-service-pem, ssl-upstream. See 473 https://unbound.net/documentation/unbound.conf.html. 475 8.2. ldns 477 Sinodun Internet Technologies has implemented DNS-over-TLS in the 478 ldns library from NLnetLabs. This also gives DNS-over-TLS support to 479 the drill DNS client program. Patches available at https:// 480 portal.sinodun.com/stash/projects/TDNS/repos/dns-over-tls_patches/ 481 browse. 483 8.3. digit 485 The digit DNS client from USC/ISI supports DNS-over-TLS. Source code 486 available at http://www.isi.edu/ant/software/tdns/index.html. 488 8.4. getdns 490 The getdns API implementation supports DNS-over-TLS. Source code 491 available at https://getdnsapi.net. 493 9. Security Considerations 495 Use of DNS-over-TLS is designed to address the privacy risks that 496 arise out of the ability to eavesdrop on DNS messages. It does not 497 address other security issues in DNS, and there are a number of 498 residual risks that may affect its success at protecting privacy: 500 1. There are known attacks on TLS, such as person-in-the-middle and 501 protocol downgrade. These are general attacks on TLS and not 502 specific to DNS-over-TLS; please refer to the TLS RFCs for 503 discussion of these security issues. Clients and servers MUST 504 adhere to the TLS implementation recommendations and security 505 considerations of [RFC7525]. DNS clients keeping track of 506 servers known to support TLS enables clients to detect downgrade 507 attacks. For servers with no connection history and no apparent 508 support for TLS, clients depending on their Privacy Profile and 509 privacy requirements may choose to (a) try another server when 510 available, (b) continue without TLS, or (c) refuse to forward the 511 query. 513 2. Middleboxes [RFC3234] are present in some networks and have been 514 known to interfere with normal DNS resolution. Use of a 515 designated port for DNS-over-TLS should avoid such interference. 516 In general, clients that attempt TLS and fail can either fall 517 back on unencrypted DNS, or wait and retry later, depending on 518 their Privacy Profile and privacy requirements. 520 3. Any DNS protocol interactions prior to the TLS handshake that are 521 performed in the clear can be modified by a person-in-the-middle 522 attacker. For example, unencrypted queries and responses might 523 take place over port 53 between a client and server prior to TLS. 524 For this reason, clients MAY discard cached information about 525 server capabilities advertised prior to the start of the TLS 526 handshake. 528 4. This document does not itself specify ideas to resist known 529 traffic analysis or side channel leaks. Even with encrypted 530 messages, a well-positioned party may be able to glean certain 531 details from an analysis of message timings and sizes. Clients 532 and servers may consider the use of a padding method to address 533 privacy leakage due to message sizes [I-D.edns0-padding] 535 10. Contributing Authors 537 The below individuals contributed significantly to the draft. The 538 RFC Editor prefers a maximum of 5 names on the front page, and so we 539 have listed additional authors in this section. 541 Sara Dickinson 542 Sinodun Internet Technologies 543 Magdalen Centre 544 Oxford Science Park 545 Oxford OX4 4GA 546 UK 547 Email: sara@sinodun.com 548 URI: http://sinodun.com 550 11. Acknowledgments 552 The authors would like to thank Stephane Bortzmeyer, John Dickinson, 553 Daniel Kahn Gillmor, Brian Haberman, Kim-Minh Kaplan, Bill Manning, 554 George Michaelson, Eric Osterweil, and Glen Wiley for reviewing this 555 Internet-draft. They also thank Nikita Somaiya for early work on 556 this idea. 558 Work by Zi Hu, Liang Zhu, and John Heidemann on this document is 559 partially sponsored by the U.S. Dept. of Homeland Security (DHS) 560 Science and Technology Directorate, HSARPA, Cyber Security Division, 561 BAA 11-01-RIKA and Air Force Research Laboratory, Information 562 Directorate under agreement number FA8750-12-2-0344, and contract 563 number D08PC75599. 565 12. References 567 12.1. Normative References 569 [I-D.ietf-dnsop-5966bis] 570 Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 571 D. Wessels, "DNS Transport over TCP - Implementation 572 Requirements", draft-ietf-dnsop-5966bis-02 (work in 573 progress), July 2015. 575 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 576 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 577 . 579 [RFC1035] Mockapetris, P., "Domain names - implementation and 580 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 581 November 1987, . 583 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 584 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 585 RFC2119, March 1997, 586 . 588 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 589 "Transport Layer Security (TLS) Session Resumption without 590 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 591 January 2008, . 593 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 594 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 595 RFC5246, August 2008, 596 . 598 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 599 Cheshire, "Internet Assigned Numbers Authority (IANA) 600 Procedures for the Management of the Service Name and 601 Transport Protocol Port Number Registry", BCP 165, 602 RFC 6335, DOI 10.17487/RFC6335, August 2011, 603 . 605 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 606 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, 607 January 2014, . 609 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 610 "Recommendations for Secure Use of Transport Layer 611 Security (TLS) and Datagram Transport Layer Security 612 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, 613 May 2015, . 615 12.2. Informative References 617 [I-D.confidentialdns] 618 Wijngaards, W., "Confidential DNS", 619 draft-wijngaards-dnsop-confidentialdns-03 (work in 620 progress), March 2015, . 623 [I-D.edns-tcp-keepalive] 624 Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 625 edns-tcp-keepalive EDNS0 Option", 626 draft-ietf-dnsop-edns-tcp-keepalive-02 (work in progress), 627 July 2015, . 630 [I-D.edns0-padding] 631 Mayrhofer, A., "The EDNS(0) Padding Option", 632 draft-mayrhofer-edns0-padding-01 (work in progress), 633 August 2015, . 636 [I-D.ipseca] 637 Osterweil, E., Wiley, G., Okubo, T., Lavu, R., and A. 638 Mohaisen, "Opportunistic Encryption with DANE Semantics 639 and IPsec: IPSECA", draft-osterweil-dane-ipsec-03 (work in 640 progress), July 2015, 641 . 644 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 645 RFC2818, May 2000, 646 . 648 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 649 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 650 . 652 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 653 Rose, "DNS Security Introduction and Requirements", 654 RFC 4033, DOI 10.17487/RFC4033, March 2005, 655 . 657 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 658 Housley, R., and W. Polk, "Internet X.509 Public Key 659 Infrastructure Certificate and Certificate Revocation List 660 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 661 . 663 [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation 664 Requirements", RFC 5966, DOI 10.17487/RFC5966, 665 August 2010, . 667 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 668 of Named Entities (DANE) Transport Layer Security (TLS) 669 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, 670 August 2012, . 672 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 673 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, 674 May 2014, . 676 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 677 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 678 . 680 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 681 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 682 December 2014, . 684 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 685 DOI 10.17487/RFC7626, August 2015, 686 . 688 [dempsky-dnscurve] 689 Dempsky, M., "DNSCurve", draft-dempsky-dnscurve-01 (work 690 in progress), August 2010, 691 . 693 [dnssec-trigger] 694 NLnet Labs, "Dnssec-Trigger", May 2014, 695 . 697 [draft-ietf-dprive-dnsodtls] 698 Reddy, T., Wing, D., and P. Patil, "DNS over DTLS 699 (DNSoD)", draft-ietf-dprive-dnsodtls-01 (work in 700 progress), June 2015, . 703 [draft-ietf-tls-falsestart] 704 Moeller, B. and A. Langley, "Transport Layer Security 705 (TLS) False Start", draft-ietf-tls-falsestart-00 (work in 706 progress), November 2014, 707 . 709 [tdns] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A., 710 and N. Somaiya, "T-DNS: Connection-Oriented DNS to Improve 711 Privacy and Security", Technical report ISI-TR-688, 712 February 2014, . 715 Authors' Addresses 717 Zi Hu 718 USC/Information Sciences Institute 719 4676 Admiralty Way, Suite 1133 720 Marina del Rey, CA 90292 721 USA 723 Phone: +1 213 587-1057 724 Email: zihu@usc.edu 726 Liang Zhu 727 USC/Information Sciences Institute 728 4676 Admiralty Way, Suite 1133 729 Marina del Rey, CA 90292 730 USA 732 Phone: +1 310 448-8323 733 Email: liangzhu@usc.edu 735 John Heidemann 736 USC/Information Sciences Institute 737 4676 Admiralty Way, Suite 1001 738 Marina del Rey, CA 90292 739 USA 741 Phone: +1 310 822-1511 742 Email: johnh@isi.edu 744 Allison Mankin 745 Verisign Labs 746 12061 Bluemont Way 747 Reston, VA 20190 749 Phone: +1 703 948-3200 750 Email: amankin@verisign.com 751 Duane Wessels 752 Verisign Labs 753 12061 Bluemont Way 754 Reston, VA 20190 756 Phone: +1 703 948-3200 757 Email: dwessels@verisign.com 759 Paul Hoffman 760 ICANN 762 Email: paul.hoffman@icann.org