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