idnits 2.17.1 draft-ietf-dprive-dns-over-tls-04.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 lines with control characters in the document. == There is 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 21, 2016) is 3016 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) == Unused Reference: 'RFC2818' is defined on line 687, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 700, but no explicit reference was found in the text == Unused Reference: 'RFC6698' is defined on line 710, but no explicit reference was found in the text == 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 (~~), 7 warnings (==), 5 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: July 24, 2016 USC/Information Sciences 6 Institute 7 A. Mankin 8 D. Wessels 9 Verisign Labs 10 P. Hoffman 11 ICANN 12 January 21, 2016 14 DNS over TLS: Initiation and Performance Considerations 15 draft-ietf-dprive-dns-over-tls-04 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 July 24, 2016. 50 Copyright Notice 52 Copyright (c) 2016 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 . . . . . . . . . . . . . 5 72 3.3. Transmitting and Receiving Messages . . . . . . . . . . . 5 73 3.4. Connection Reuse, Close and Reestablishment . . . . . . . 5 74 4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 7 76 4.2. Out-of-band Key-pinned Privacy Profile . . . . . . . . . . 7 77 5. Performance Considerations . . . . . . . . . . . . . . . . . . 8 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . . 10 80 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 81 8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 13 87 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 90 12.2. Informative References . . . . . . . . . . . . . . . . . . 15 91 Appendix A. Out-of-band Key-pinned Privacy Profile Example . . . 17 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 94 1. Introduction 96 Today, nearly all DNS queries [RFC1034], [RFC1035] are sent 97 unencrypted, which makes them vulnerable to eavesdropping by an 98 attacker that has access to the network channel, reducing the privacy 99 of the querier. Recent news reports have elevated these concerns, 100 and recent IETF work has specified privacy considerations for DNS 101 [RFC7626]. 103 Prior work has addressed some aspects of DNS security, but until 104 recently there has been little work on privacy between a DNS client 105 and server. DNS Security Extensions (DNSSEC), [RFC4033] provide 106 _response integrity_ by defining mechanisms to cryptographically sign 107 zones, allowing end-users (or their first-hop resolver) to verify 108 replies are correct. By intention, DNSSEC does not protect request 109 and response privacy. Traditionally, either privacy was not 110 considered a requirement for DNS traffic, or it was assumed that 111 network traffic was sufficiently private, however these perceptions 112 are evolving due to recent events [RFC7258]. 114 Other work that has offered the potential to encrypt between DNS 115 clients and servers includes DNSCurve [dempsky-dnscurve], 116 ConfidentialDNS [I-D.confidentialdns] and IPSECA [I-D.ipseca]. In 117 addition to the present draft, the DPRIVE working group has recently 118 adopted a DNS-over-DTLS [draft-ietf-dprive-dnsodtls] proposal. 120 This document describes using DNS-over-TLS on a well-known port and 121 also offers advice on performance considerations to minimize 122 overheads from using TCP and TLS with DNS. 124 Initiation of DNS-over-TLS is very straightforward. By establishing 125 a connection over a well-known port, clients and servers expect and 126 agree to negotiate a TLS session to secure the channel. Deployment 127 will be gradual. Not all servers will support DNS-over-TLS and the 128 well-known port might be blocked by some firewalls. Clients will be 129 expected to keep track of servers that support TLS and those that 130 don't. Clients and servers will adhere to the TLS implementation 131 recommendations and security considerations of [RFC7525] or its 132 successor. 134 The protocol described here works for any DNS client to server 135 communication using DNS-over-TCP. That is, it may be used for 136 queries and responses between stub clients and recursive servers as 137 well as between recursive clients and authoritative servers. 139 This document describes two profiles in Section 4 providing different 140 levels of assurance of privacy: an opportunistic privacy profile and 141 an out-of-band key-pinned privacy profile. It is expected that a 142 future document based on [dgr-dprive-dtls-and-tls-profiles] will 143 further describe additional privacy profiles for DNS over both TLS 144 and DTLS. 146 An earlier version of this document described a technique for 147 upgrading a DNS-over-TCP connection to a DNS-over-TLS session with, 148 essentially, "STARTTLS for DNS". To simplify the protocol, this 149 document now only uses a well-known port to specify TLS use, omitting 150 the upgrade approach. The upgrade approach no longer appears in this 151 document, which now focuses exclusively on the use of a well-known 152 port for DNS-over-TLS. 154 2. Reserved Words 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 [RFC2119]. 160 3. Establishing and Managing DNS-over-TLS Sessions 162 3.1. Session Initiation 164 A DNS server that supports DNS-over-TLS MUST listen for and accept 165 TCP connections on port 853. 167 DNS clients desiring privacy from DNS-over-TLS from a particular 168 server MUST establish a TCP connection which SHOULD be to port 853 on 169 the server. This is a SHOULD rather than a MUST because a server MAY 170 also offer DNS-over-TLS service on another port by agreement with its 171 client. Such an additional port MUST NOT be port 53, but MAY be from 172 the FCFS port range. The first data exchange on this TCP connection 173 MUST be the client and server initiating a TLS handshake using the 174 procedure described in [RFC5246]. 176 DNS clients and servers MUST NOT use port 853 to transport clear text 177 DNS messages. DNS clients MUST NOT send and DNS servers MUST NOT 178 respond to clear text DNS messages on any port used for DNS-over-TLS 179 (including, for example, after a failed TLS handshake). There are 180 significant security issues in mixing protected and unprotected data 181 and for this reason TCP connections on a port designated by a given 182 server for DNS-over-TLS are reserved purely for encrypted 183 communications. 185 DNS clients SHOULD remember server IP addresses that don't support 186 DNS-over-TLS, including timeouts, connection refusals, and TLS 187 handshake failures, and not request DNS-over-TLS from them for a 188 reasonable period (such as one hour per server). DNS clients 189 following an out-of-band key-pinned privacy profile MAY be more 190 aggressive about retrying DNS-over-TLS connection failures. 192 3.2. TLS Handshake and Authentication 194 Once the DNS client succeeds in connecting via TCP on the well-known 195 port for DNS-over-TLS, it proceeds with the TLS handshake [RFC5246], 196 following the best practices specified in [RFC7525] or its successor. 198 The client will then authenticate the server, if required. This 199 document does not propose new ideas for authentication. Depending on 200 the privacy profile in use Section 4, the DNS client may choose not 201 to require authentication of the server, or it may make use of 202 trusted a SPKI Fingerprint pinset. 204 After TLS negotiation completes, the connection will be encrypted and 205 is now protected from eavesdropping. At this point, normal DNS 206 queries SHOULD take place. 208 3.3. Transmitting and Receiving Messages 210 All messages (requests and responses) in the established TLS session 211 MUST use the two-octet length field described in Section 4.2.2 of 212 [RFC1035]. For reasons of efficiency, DNS clients and servers SHOULD 213 pass the two-octet length field, and the message described by that 214 length field, to the TCP layer at the same time (e.g., in a single 215 "write" system call) to make it more likely that all the data will be 216 transmitted in a single TCP segment ([I-D.ietf-dnsop-5966bis], 217 Section 8). 219 In order to minimize latency, clients SHOULD pipeline multiple 220 queries over a TLS session. When a DNS client sends multiple queries 221 to a server, it should not wait for an outstanding reply before 222 sending the next query ([I-D.ietf-dnsop-5966bis], Section 6.2.1.1). 224 Since pipelined responses can arrive out-of-order, clients MUST match 225 responses to outstanding queries using the ID field, query name, 226 type, and class. Failure by clients to properly match responses to 227 outstanding queries can have serious consequences for 228 interoperability ([I-D.ietf-dnsop-5966bis], Section 7). 230 3.4. Connection Reuse, Close and Reestablishment 232 For DNS clients that use library functions such as "getaddrinfo()" 233 and "gethostbyname()", current implementations are known to open and 234 close TCP connections each DNS call. To avoid excess TCP 235 connections, each with a single query, clients SHOULD reuse a single 236 TCP connection to the recursive resolver. Alternatively they may 237 prefer to use UDP to a DNS-over-TLS enabled caching resolver on the 238 same machine that then uses a system-wide TCP connection to the 239 recursive resolver. 241 In order to amortize TCP and TLS connection setup costs, clients and 242 servers SHOULD NOT immediately close a connection after each 243 response. Instead, clients and servers SHOULD reuse existing 244 connections for subsequent queries as long as they have sufficient 245 resources. In some cases, this means that clients and servers may 246 need to keep idle connections open for some amount of time. 248 Proper management of established and idle connections is important to 249 the healthy operation of a DNS server. An implementor of DNS-over- 250 TLS SHOULD follow best practices for DNS-over-TCP, as described in 251 [I-D.ietf-dnsop-5966bis]. Failure to do so may lead to resource 252 exhaustion and denial-of-service. 254 Whereas client and server implementations from the [RFC1035] era are 255 known to have poor TCP connection management, this document 256 stipulates that successful negotiation of TLS indicates the 257 willingness of both parties to keep idle DNS connections open, 258 independent of timeouts or other recommendations for DNS-over-TCP 259 without TLS. In other words, software implementing this protocol is 260 assumed to support idle, persistent connections and be prepared to 261 manage multiple, potentially long-lived TCP connections. 263 This document does not make specific recommendations for timeout 264 values on idle connections. Clients and servers should reuse and/or 265 close connections depending on the level of available resources. 266 Timeouts may be longer during periods of low activity and shorter 267 during periods of high activity. Current work in this area may also 268 assist DNS-over-TLS clients and servers select useful timeout values 269 [I-D.edns-tcp-keepalive] [tdns]. 271 Clients and servers that keep idle connections open MUST be robust to 272 termination of idle connection by either party. As with current DNS- 273 over-TCP, DNS servers MAY close the connection at any time (perhaps 274 due to resource constraints). As with current DNS-over-TCP, clients 275 MUST handle abrupt closes and be prepared to reestablish connections 276 and/or retry queries. 278 When reestablishing a DNS-over-TCP connection that was terminated, as 279 discussed in [I-D.ietf-dnsop-5966bis], TCP Fast Open [RFC7413] is of 280 benefit. Underlining the requirement for sending only encrypted DNS 281 data on a DNS-over-TLS port (Section 3.2), when using TCP Fast Open 282 the client and server MUST immediately initiate or resume a TLS 283 handshake (clear text DNS MUST NOT be exchanged). DNS servers SHOULD 284 enable fast TLS session resumption [RFC5077] and this SHOULD be used 285 when reestablishing connections. 287 When closing a connection, DNS servers SHOULD use the TLS close- 288 notify request to shift TCP TIME-WAIT state to the clients. 289 Additional requirements and guidance for optimizing DNS-over-TCP are 290 provided by [RFC5966], [I-D.ietf-dnsop-5966bis]. 292 4. Usage Profiles 294 This protocol provides flexibility to accommodate several different 295 use cases. This document defines two usage profiles: (1) 296 opportunistic privacy, and (2) out-of-band key-pinned authentication 297 that can be used to obtain stronger privacy guarantees if the client 298 has a trusted relationship with a DNS server supporting TLS. 299 Additional methods of authentication will be defined in a forthcoming 300 draft [dgr-dprive-dtls-and-tls-profiles]. 302 4.1. Opportunistic Privacy Profile 304 For opportunistic privacy, analogous to SMTP opportunistic encryption 305 [RFC7435] one does not require privacy, but one desires privacy when 306 possible. 308 With opportunistic privacy, a client might learn of a TLS-enabled 309 recursive DNS resolver from an untrusted source (such as DHCP while 310 roaming), it might or might not validate the resolver. These choices 311 maximize availability and performance, but they leave the client 312 vulnerable to on-path attacks that remove privacy. 314 Opportunistic privacy can be used by any current client, but it only 315 provides guaranteed privacy when there are no on-path active 316 attackers. 318 4.2. Out-of-band Key-pinned Privacy Profile 320 The out-of-band key-pinned privacy profile can be used in 321 environments where an established trust relationship already exists 322 between DNS clients and servers (e.g., stub-to-recursive in 323 enterprise networks, actively-maintained contractual service 324 relationships, or a client using a public DNS resolver). The result 325 of this profile is that the client has strong guarantees about the 326 privacy of its DNS data by connecting only to servers it can 327 authenticate. 329 In this profile, clients authenticate servers by matching a set of 330 Subject Public Key Info (SPKI) Fingerprints in an analogous manner to 331 that described in [RFC7469]. With this out-of-band key-pinned 332 privacy profile, client administrators SHOULD deploy a backup pin 333 along with the primary pin, for the reasons explained in [RFC7469]. 334 A backup pin is especially helpful in the event of a key rollover, so 335 that a server operator does not have to coordinate key transitions 336 with all its clients simultaneously. After a change of keys on the 337 server, an updated pinset SHOULD be distributed to all clients in 338 some secure way in preparation for future key rollover. The 339 mechanism for out-of-band pinset update is out of scope for this 340 document. 342 Such a client will only use DNS servers for which an SPKI Fingerprint 343 pinset has been provided. The possession of trusted pre-deployed 344 pinset allows the client to detect and prevent person-in-the-middle 345 and downgrade attacks. 347 However, a configured DNS server may be temporarily unavailable when 348 configuring a network. For example, for clients on networks that 349 require authentication through web-based login, such authentication 350 may rely on DNS interception and spoofing. Techniques such as those 351 used by DNSSEC-trigger [dnssec-trigger] MAY be used during network 352 configuration, with the intent to transition to the designated DNS 353 provider after authentication. The user MUST be alerted that the DNS 354 is not private during such bootstrap. 356 Upon successful TLS connection and handshake, the client computes the 357 SPKI Fingerprints for the public keys found in the validated server's 358 certificate chain (or in the raw public key, if the server provides 359 that instead). If a computed fingerprint exactly matches one of the 360 configured pins the client continues with the connection as normal. 361 Otherwise, the client MUST treat the SPKI validation failure as a 362 non-recoverable error. Appendix A provides a detailed example of how 363 this authentication could be performed in practice. 365 5. Performance Considerations 367 DNS-over-TLS incurs additional latency at session startup. It also 368 requires additional state (memory) and increased processing (CPU). 370 1. Latency: Compared to UDP, DNS-over-TCP requires an additional 371 round-trip-time (RTT) of latency to establish a TCP connection. 372 TCP Fast Open [RFC7413] can eliminate that RTT when information 373 exists from prior connections. The TLS handshake adds another 374 two RTTs of latency. Clients and servers should support 375 connection keepalive (reuse) and out-of-order processing to 376 amortize connection setup costs. Fast TLS connection resumption 377 [RFC5077] further reduces the setup delay and avoids the DNS 378 server keeping per-client session state. TLS False Start 379 [draft-ietf-tls-falsestart] can also lead to a latency reduction 380 in certain situations. 382 2. State: The use of connection-oriented TCP requires keeping 383 additional state at the server in both the kernel and 384 application. The state requirements are of particular concern on 385 servers with many clients, although memory-optimized TLS can add 386 only modest state over TCP. Smaller timeout values will reduce 387 the number of concurrent connections, and servers can 388 preemptively close connections when resource limits are exceeded. 390 3. Processing: Use of TLS encryption algorithms results in slightly 391 higher CPU usage. Servers can choose to refuse new DNS-over-TLS 392 clients if processing limits are exceeded. 394 4. Number of connections: To minimize state on DNS servers and 395 connection startup time, clients SHOULD minimize creation of new 396 TCP connections. Use of a local DNS request aggregator (a 397 particular type of forwarder) allows a single active DNS-over-TLS 398 connection from any given client computer to its server. 399 Additional guidance can be found in [I-D.ietf-dnsop-5966bis]. 401 A full performance evaluation is outside the scope of this 402 specification. A more detailed analysis of the performance 403 implications of DNS-over-TLS (and DNS-over-TCP) is discussed in 404 [tdns] and [I-D.ietf-dnsop-5966bis]. 406 6. IANA Considerations 408 IANA is requested to add the following value to the "Service Name and 409 Transport Protocol Port Number Registry" registry in the System 410 Range. The registry for that range requires IETF Review or IESG 411 Approval [RFC6335] and such a review was requested using the Early 412 Allocation process [RFC7120] for the well-known TCP port in this 413 document. 415 We further recommend that IANA reserve the same port number over UDP 416 for the proposed DNS-over-DTLS protocol [draft-ietf-dprive-dnsodtls]. 418 IANA responded to the early allocation request with the following 419 TEMPORARY assignment: 421 Service Name domain-s 422 Port Number 853 423 Transport Protocol(s) TCP/UDP 424 Assignee IETF DPRIVE Chairs 425 Contact Paul Hoffman 426 Description DNS query-response protocol run over TLS/DTLS 427 Reference This document 429 The TEMPORARY assignment expires 2016-10-08. IANA is requested to 430 make the assigmnent permanent upon publication of this document as an 431 RFC. 433 7. Design Evolution 435 [Note to RFC Editor: please do not remove this section prior to 436 publication as it may be useful to future Foo-over-TLS efforts] 438 Earlier versions of this document proposed an upgrade-based approach 439 to establishing a TLS session. The client would signal its interest 440 in TLS by setting a "TLS OK" bit in the EDNS0 flags field. A server 441 would signal its acceptance by responding with the TLS OK bit set. 443 Since we assume the client doesn't want to reveal (leak) any 444 information prior to securing the channel, we proposed the use of a 445 "dummy query" that clients could send for this purpose. The proposed 446 query name was STARTTLS, query type TXT, and query class CH. 448 The TLS OK signaling approach has both advantages and disadvantages. 449 One important advantage is that clients and servers could negotiate 450 TLS. If the server is too busy, or doesn't want to provide TLS 451 service to a particular client, it can respond negatively to the TLS 452 probe. An ancillary benefit is that servers could collect 453 information on adoption of DNS-over-TLS (via the TLS OK bit in 454 queries) before implementation and deployment. Another anticipated 455 advantage is the expectation that DNS-over-TLS would work over port 456 53. That is, no need to "waste" another port and deploy new firewall 457 rules on middleboxes. 459 However, at the same time, there was uncertainty whether or not 460 middleboxes would pass the TLS OK bit, given that the EDNS0 flags 461 field has been unchanged for many years. Another disadvantage is 462 that the TLS OK bit may make downgrade attacks easy and 463 indistinguishable from broken middleboxes. From a performance 464 standpoint, the upgrade-based approach had the disadvantage of 465 requiring 1xRTT additional latency for the dummy query. 467 Following this proposal, DNS-over-DTLS was proposed separately. DNS- 468 over-DTLS claimed it could work over port 53, but only because a non- 469 DTLS server interprets a DNS-over-DTLS query as a response. That is, 470 the non-DTLS server observes the QR flag set to 1. While this 471 technically works, it seems unfortunate and perhaps even undesirable. 473 DNS over both TLS and DTLS can benefit from a single well-known port 474 and avoid extra latency and mis-interpreted queries as responses. 476 8. Implementation Status 478 [Note to RFC Editor: please remove this section and reference to RFC 479 6982 prior to publication.] 481 This section records the status of known implementations of the 482 protocol defined by this specification at the time of posting of this 483 Internet-Draft, and is based on a proposal described in RFC 6982. 484 The description of implementations in this section is intended to 485 assist the IETF in its decision processes in progressing drafts to 486 RFCs. Please note that the listing of any individual implementation 487 here does not imply endorsement by the IETF. Furthermore, no effort 488 has been spent to verify the information presented here that was 489 supplied by IETF contributors. This is not intended as, and must not 490 be construed to be, a catalog of available implementations or their 491 features. Readers are advised to note that other implementations may 492 exist. 494 According to RFC 6982, "this will allow reviewers and working groups 495 to assign due consideration to documents that have the benefit of 496 running code, which may serve as evidence of valuable experimentation 497 and feedback that have made the implemented protocols more mature. 498 It is up to the individual working groups to use this information as 499 they see fit". 501 8.1. Unbound 503 The Unbound recursive name server software added support for DNS- 504 over-TLS in version 1.4.14. The unbound.conf configuration file has 505 the following configuration directives: ssl-port, ssl-service-key, 506 ssl-service-pem, ssl-upstream. See 507 https://unbound.net/documentation/unbound.conf.html. 509 8.2. ldns 511 Sinodun Internet Technologies has implemented DNS-over-TLS in the 512 ldns library from NLnetLabs. This also gives DNS-over-TLS support to 513 the drill DNS client program. Patches available at https:// 514 portal.sinodun.com/stash/projects/TDNS/repos/dns-over-tls_patches/ 515 browse. 517 8.3. digit 519 The digit DNS client from USC/ISI supports DNS-over-TLS. Source code 520 available at http://www.isi.edu/ant/software/tdns/index.html. 522 8.4. getdns 524 The getdns API implementation supports DNS-over-TLS. Source code 525 available at https://getdnsapi.net. 527 9. Security Considerations 529 Use of DNS-over-TLS is designed to address the privacy risks that 530 arise out of the ability to eavesdrop on DNS messages. It does not 531 address other security issues in DNS, and there are a number of 532 residual risks that may affect its success at protecting privacy: 534 1. There are known attacks on TLS, such as person-in-the-middle and 535 protocol downgrade. These are general attacks on TLS and not 536 specific to DNS-over-TLS; please refer to the TLS RFCs for 537 discussion of these security issues. Clients and servers MUST 538 adhere to the TLS implementation recommendations and security 539 considerations of [RFC7525] or its successor. DNS clients 540 keeping track of servers known to support TLS enables clients to 541 detect downgrade attacks. For servers with no connection history 542 and no apparent support for TLS, depending on their Privacy 543 Profile and privacy requirements, clients may choose to (a) try 544 another server when available, (b) continue without TLS, or (c) 545 refuse to forward the query. 547 2. Middleboxes [RFC3234] are present in some networks and have been 548 known to interfere with normal DNS resolution. Use of a 549 designated port for DNS-over-TLS should avoid such interference. 550 In general, clients that attempt TLS and fail can either fall 551 back on unencrypted DNS, or wait and retry later, depending on 552 their Privacy Profile and privacy requirements. 554 3. Any DNS protocol interactions performed in the clear can be 555 modified by a person-in-the-middle attacker. For example, 556 unencrypted queries and responses might take place over port 53 557 between a client and server. For this reason, clients MAY 558 discard cached information about server capabilities advertised 559 in clear text. 561 4. This document does not itself specify ideas to resist known 562 traffic analysis or side channel leaks. Even with encrypted 563 messages, a well-positioned party may be able to glean certain 564 details from an analysis of message timings and sizes. Clients 565 and servers may consider the use of a padding method to address 566 privacy leakage due to message sizes [I-D.edns0-padding] 568 10. Contributing Authors 570 The below individuals contributed significantly to the draft. The 571 RFC Editor prefers a maximum of 5 names on the front page, and so we 572 have listed additional authors in this section. 574 Sara Dickinson 575 Sinodun Internet Technologies 576 Magdalen Centre 577 Oxford Science Park 578 Oxford OX4 4GA 579 UK 580 Email: sara@sinodun.com 581 URI: http://sinodun.com 583 Daniel Kahn Gillmor 584 ACLU 585 125 Broad Street, 18th Floor 586 New York, NY 10004 587 USA 589 11. Acknowledgments 591 The authors would like to thank Stephane Bortzmeyer, John Dickinson, 592 Brian Haberman, Christian Huitema, Shumon Huque, Kim-Minh Kaplan, 593 Simon Joseffson, Simon Kelley, Warren Kumari, John Levine, Ilari 594 Liusvaara, Bill Manning, George Michaelson, Eric Osterweil, Jinmei 595 Tatuya, Tim Wicinski, and Glen Wiley for reviewing this Internet- 596 draft. They also thank Nikita Somaiya for early work on this idea. 598 Work by Zi Hu, Liang Zhu, and John Heidemann on this document is 599 partially sponsored by the U.S. Dept. of Homeland Security (DHS) 600 Science and Technology Directorate, HSARPA, Cyber Security Division, 601 BAA 11-01-RIKA and Air Force Research Laboratory, Information 602 Directorate under agreement number FA8750-12-2-0344, and contract 603 number D08PC75599. 605 12. References 606 12.1. Normative References 608 [I-D.ietf-dnsop-5966bis] 609 Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 610 D. Wessels, "DNS Transport over TCP - Implementation 611 Requirements", draft-ietf-dnsop-5966bis-02 (work in 612 progress), July 2015. 614 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 615 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 616 . 618 [RFC1035] Mockapetris, P., "Domain names - implementation and 619 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 620 November 1987, . 622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 624 RFC2119, March 1997, 625 . 627 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 628 "Transport Layer Security (TLS) Session Resumption without 629 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 630 January 2008, . 632 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 633 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 634 RFC5246, August 2008, 635 . 637 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 638 Cheshire, "Internet Assigned Numbers Authority (IANA) 639 Procedures for the Management of the Service Name and 640 Transport Protocol Port Number Registry", BCP 165, 641 RFC 6335, DOI 10.17487/RFC6335, August 2011, 642 . 644 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 645 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, 646 January 2014, . 648 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 649 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, 650 April 2015, . 652 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 653 "Recommendations for Secure Use of Transport Layer 654 Security (TLS) and Datagram Transport Layer Security 655 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, 656 May 2015, . 658 12.2. Informative References 660 [I-D.confidentialdns] 661 Wijngaards, W., "Confidential DNS", 662 draft-wijngaards-dnsop-confidentialdns-03 (work in 663 progress), March 2015, . 666 [I-D.edns-tcp-keepalive] 667 Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 668 edns-tcp-keepalive EDNS0 Option", 669 draft-ietf-dnsop-edns-tcp-keepalive-02 (work in progress), 670 July 2015, . 673 [I-D.edns0-padding] 674 Mayrhofer, A., "The EDNS(0) Padding Option", 675 draft-mayrhofer-edns0-padding-01 (work in progress), 676 August 2015, . 679 [I-D.ipseca] 680 Osterweil, E., Wiley, G., Okubo, T., Lavu, R., and A. 681 Mohaisen, "Opportunistic Encryption with DANE Semantics 682 and IPsec: IPSECA", draft-osterweil-dane-ipsec-03 (work in 683 progress), July 2015, 684 . 687 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 688 RFC2818, May 2000, 689 . 691 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 692 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 693 . 695 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 696 Rose, "DNS Security Introduction and Requirements", 697 RFC 4033, DOI 10.17487/RFC4033, March 2005, 698 . 700 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 701 Housley, R., and W. Polk, "Internet X.509 Public Key 702 Infrastructure Certificate and Certificate Revocation List 703 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 704 . 706 [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation 707 Requirements", RFC 5966, DOI 10.17487/RFC5966, 708 August 2010, . 710 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 711 of Named Entities (DANE) Transport Layer Security (TLS) 712 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, 713 August 2012, . 715 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 716 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, 717 May 2014, . 719 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 720 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 721 . 723 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 724 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 725 December 2014, . 727 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 728 DOI 10.17487/RFC7626, August 2015, 729 . 731 [dempsky-dnscurve] 732 Dempsky, M., "DNSCurve", draft-dempsky-dnscurve-01 (work 733 in progress), August 2010, 734 . 736 [dgr-dprive-dtls-and-tls-profiles] 737 Dickinson, S., Gillmor, D., and T. Reddy, 738 "Authentication and (D)TLS Profile for DNS-over-TLS and 739 DNS-over-DTLS", draft-dgr-dprive-dtls-and-tls-profiles-00 740 (work in progress), December 2015, . 744 [dnssec-trigger] 745 NLnet Labs, "Dnssec-Trigger", May 2014, 746 . 748 [draft-ietf-dprive-dnsodtls] 749 Reddy, T., Wing, D., and P. Patil, "DNS over DTLS 750 (DNSoD)", draft-ietf-dprive-dnsodtls-01 (work in 751 progress), June 2015, . 754 [draft-ietf-tls-falsestart] 755 Moeller, B. and A. Langley, "Transport Layer Security 756 (TLS) False Start", draft-ietf-tls-falsestart-00 (work in 757 progress), November 2014, 758 . 760 [tdns] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A., 761 and N. Somaiya, "T-DNS: Connection-Oriented DNS to Improve 762 Privacy and Security", Technical report ISI-TR-688, 763 February 2014, . 766 Appendix A. Out-of-band Key-pinned Privacy Profile Example 768 This section presents an example of how the out-of-band key-pinned 769 privacy profile could work in practice based on a minimal pinset (two 770 pins). Operators of a DNS-over-TLS service in this profile are 771 expected to provide pins that are specific to the service being 772 pinned (i.e., public keys belonging directly to the end-entity or to 773 a service-specific private CA) and not to public key(s) of a generic 774 public CA. 776 A DNS client system is configured with an out-of-band key-pinned 777 privacy profile from a network service, using a pinset containing two 778 pins. Represented in HPKP [RFC7469] style, the pins are: 780 o pin-sha256="FHkyLhvI0n70E47cJlRTamTrnYVcsYdjUGbr79CfAVI=" 782 o pin-sha256="dFSY3wdPU8L0u/8qECuz5wtlSgnorYV2f66L6GNQg6w=" 784 The client also configures the IP addresses of its expected DNS 785 server, 192.0.2.3 and 192.0.2.4. 787 The client connects to 192.0.2.3 on TCP port 853 and begins the TLS 788 handshake, negotiation TLS 1.2 with a diffie-hellman key exchange. 789 The server sends a Certificate message with a list of three 790 certificates (A, B, and C), and signs the ServerKeyExchange message 791 correctly with the public key found certificate A. 793 The client now takes the SHA-256 digest of the SPKI in cert A, and 794 compares it against both pins in the pinset. If either pin matches, 795 the verification is successful; the client continues with the TLS 796 connection and can make its first DNS query. 798 If neither pin matches the SPKI of cert A, the client verifies that 799 cert A is actually issued by cert B. If it is, it takes the SHA-256 800 digest of the SPKI in cert B and compares it against both pins in the 801 pinset. If either pin matches, the verification is successful. 802 Otherwise, it verifes that B was issued by C, and then compares the 803 pins against the digest of C's SPKI. 805 If none of the SPKIs in the cryptographically-valid chain of certs 806 match any pin in the pinset, the client closes the connection with an 807 error, and marks the IP address as failed. 809 Authors' Addresses 811 Zi Hu 812 USC/Information Sciences Institute 813 4676 Admiralty Way, Suite 1133 814 Marina del Rey, CA 90292 815 USA 817 Phone: +1 213 587-1057 818 Email: zihu@usc.edu 820 Liang Zhu 821 USC/Information Sciences Institute 822 4676 Admiralty Way, Suite 1133 823 Marina del Rey, CA 90292 824 USA 826 Phone: +1 310 448-8323 827 Email: liangzhu@usc.edu 829 John Heidemann 830 USC/Information Sciences Institute 831 4676 Admiralty Way, Suite 1001 832 Marina del Rey, CA 90292 833 USA 835 Phone: +1 310 822-1511 836 Email: johnh@isi.edu 837 Allison Mankin 838 Verisign Labs 839 12061 Bluemont Way 840 Reston, VA 20190 842 Phone: +1 703 948-3200 843 Email: amankin@verisign.com 845 Duane Wessels 846 Verisign Labs 847 12061 Bluemont Way 848 Reston, VA 20190 850 Phone: +1 703 948-3200 851 Email: dwessels@verisign.com 853 Paul Hoffman 854 ICANN 856 Email: paul.hoffman@icann.org