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