idnits 2.17.1 draft-ietf-dprive-dns-over-tls-09.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 : ---------------------------------------------------------------------------- -- 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 17, 2016) is 2962 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 766, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 784, but no explicit reference was found in the text == Unused Reference: 'RFC6698' is defined on line 790, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7525 (ref. 'BCP195') (Obsoleted by RFC 9325) ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 6234 == 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 7626 (Obsoleted by RFC 9076) Summary: 4 errors (**), 0 flaws (~~), 5 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 18, 2016 USC/Information Sciences Institute 6 A. Mankin 8 D. Wessels 9 Verisign Labs 10 P. Hoffman 11 ICANN 12 March 17, 2016 14 Specification for DNS over TLS 15 draft-ietf-dprive-dns-over-tls-09 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 7626. 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 This document focuses on securing stub-to-recursive traffic, as per 27 the charter of the DPRIVE working group. It does not prevent future 28 applications of the protocol to recursive-to-authoritative traffic. 30 Note: this document was formerly named draft-ietf-dprive-start-tls- 31 for-dns. Its name has been changed to better describe the mechanism 32 now used. Please refer to working group archives under the former 33 name for history and previous discussion. [RFC Editor: please remove 34 this paragraph prior to publication] 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on September 18, 2016. 53 Copyright Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Establishing and Managing DNS-over-TLS Sessions . . . . . . . 4 73 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 4 74 3.2. TLS Handshake and Authentication . . . . . . . . . . . . 5 75 3.3. Transmitting and Receiving Messages . . . . . . . . . . . 5 76 3.4. Connection Reuse, Close and Reestablishment . . . . . . . 6 77 4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . 7 78 4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 7 79 4.2. Out-of-band Key-pinned Privacy Profile . . . . . . . . . 7 80 5. Performance Considerations . . . . . . . . . . . . . . . . . 9 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . 10 83 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 84 8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 89 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 13 90 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 93 12.2. Informative References . . . . . . . . . . . . . . . . . 16 94 Appendix A. Out-of-band Key-pinned Privacy Profile Example . . . 18 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 97 1. Introduction 99 Today, nearly all DNS queries [RFC1034], [RFC1035] are sent 100 unencrypted, which makes them vulnerable to eavesdropping by an 101 attacker that has access to the network channel, reducing the privacy 102 of the querier. Recent news reports have elevated these concerns, 103 and recent IETF work has specified privacy considerations for DNS 104 [RFC7626]. 106 Prior work has addressed some aspects of DNS security, but until 107 recently there has been little work on privacy between a DNS client 108 and server. DNS Security Extensions (DNSSEC), [RFC4033] provide 109 _response integrity_ by defining mechanisms to cryptographically sign 110 zones, allowing end-users (or their first-hop resolver) to verify 111 replies are correct. By intention, DNSSEC does not protect request 112 and response privacy. Traditionally, either privacy was not 113 considered a requirement for DNS traffic, or it was assumed that 114 network traffic was sufficiently private, however these perceptions 115 are evolving due to recent events [RFC7258]. 117 Other work that has offered the potential to encrypt between DNS 118 clients and servers includes DNSCurve [dempsky-dnscurve], DNSCrypt 119 [dnscrypt-website], ConfidentialDNS [I-D.confidentialdns] and IPSECA 120 [I-D.ipseca]. In addition to the present draft, the DPRIVE working 121 group has also adopted a DNS-over-DTLS [draft-ietf-dprive-dnsodtls] 122 proposal. 124 This document describes using DNS-over-TLS on a well-known port and 125 also offers advice on performance considerations to minimize 126 overheads from using TCP and TLS with DNS. 128 Initiation of DNS-over-TLS is very straightforward. By establishing 129 a connection over a well-known port, clients and servers expect and 130 agree to negotiate a TLS session to secure the channel. Deployment 131 will be gradual. Not all servers will support DNS-over-TLS and the 132 well-known port might be blocked by some firewalls. Clients will be 133 expected to keep track of servers that support TLS and those that 134 don't. Clients and servers will adhere to the TLS implementation 135 recommendations and security considerations of [BCP195]. 137 The protocol described here works for queries and responses between 138 stub clients and recursive servers. It might work equally between 139 recursive clients and authoritative servers, but this application of 140 the protocol is out of scope for the DNS PRIVate Exchange (DPRIVE) 141 Working Group per its current charter. 143 This document describes two profiles in Section 4 providing different 144 levels of assurance of privacy: an opportunistic privacy profile and 145 an out-of-band key-pinned privacy profile. It is expected that a 146 future document based on [dgr-dprive-dtls-and-tls-profiles] will 147 further describe additional privacy profiles for DNS over both TLS 148 and DTLS. 150 An earlier version of this document described a technique for 151 upgrading a DNS-over-TCP connection to a DNS-over-TLS session with, 152 essentially, "STARTTLS for DNS". To simplify the protocol, this 153 document now only uses a well-known port to specify TLS use, omitting 154 the upgrade approach. The upgrade approach no longer appears in this 155 document, which now focuses exclusively on the use of a well-known 156 port for DNS-over-TLS. 158 2. Reserved Words 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in RFC 2119 [RFC2119]. 164 3. Establishing and Managing DNS-over-TLS Sessions 166 3.1. Session Initiation 168 A DNS server that supports DNS-over-TLS MUST by default listen for 169 and accept TCP connections on port 853, unless it has mutual 170 agreement with its clients to use a port other than 853 for DNS-over- 171 TLS. In order to use a port other than 853, both clients and servers 172 would need a configuration option in their software. 174 DNS clients desiring privacy from DNS-over-TLS from a particular 175 server MUST by default establish a TCP connection to port 853 on the 176 server, unless it has mutual agreement with its server to use a port 177 other than port 853 for DNS-over-TLS. Such an other port MUST NOT be 178 port 53, but MAY be from the "first-come, first-served" port range. 179 This recommendation against use of port 53 for DNS-over-TLS is to 180 avoid complication in selecting use or non-use of TLS, and to reduce 181 risk of downgrade attacks. The first data exchange on this TCP 182 connection MUST be the client and server initiating a TLS handshake 183 using the procedure described in [RFC5246]. 185 DNS clients and servers MUST NOT use port 853 to transport clear text 186 DNS messages. DNS clients MUST NOT send and DNS servers MUST NOT 187 respond to clear text DNS messages on any port used for DNS-over-TLS 188 (including, for example, after a failed TLS handshake). There are 189 significant security issues in mixing protected and unprotected data 190 and for this reason TCP connections on a port designated by a given 191 server for DNS-over-TLS are reserved purely for encrypted 192 communications. 194 DNS clients SHOULD remember server IP addresses that don't support 195 DNS-over-TLS, including timeouts, connection refusals, and TLS 196 handshake failures, and not request DNS-over-TLS from them for a 197 reasonable period (such as one hour per server). DNS clients 198 following an out-of-band key-pinned privacy profile (Section 4.2) MAY 199 be more aggressive about retrying DNS-over-TLS connection failures. 201 3.2. TLS Handshake and Authentication 203 Once the DNS client succeeds in connecting via TCP on the well-known 204 port for DNS-over-TLS, it proceeds with the TLS handshake [RFC5246], 205 following the best practices specified in [BCP195]. 207 The client will then authenticate the server, if required. This 208 document does not propose new ideas for authentication. Depending on 209 the privacy profile in use (Section 4), the DNS client may choose not 210 to require authentication of the server, or it may make use of a 211 trusted Subject Public Key Info (SPKI) Fingerprint pinset. 213 After TLS negotiation completes, the connection will be encrypted and 214 is now protected from eavesdropping. 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 ([RFC7766], Section 8). 226 In order to minimize latency, clients SHOULD pipeline multiple 227 queries over a TLS session. When a DNS client sends multiple queries 228 to a server, it should not wait for an outstanding reply before 229 sending the next query ([RFC7766], Section 6.2.1.1). 231 Since pipelined responses can arrive out of order, clients MUST match 232 responses to outstanding queries on the same TLS connection using the 233 Message ID. If the response contains a question section, the client 234 MUST match the QNAME, QCLASS, and QTYPE fields. Failure by clients 235 to properly match responses to outstanding queries can have serious 236 consequences for interoperability ([RFC7766], 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 for each DNS query. 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 [RFC7766]. Failure to do so may lead to resource exhaustion and 260 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 [RFC7766], TCP Fast Open [RFC7413] is of benefit. 288 Underlining the requirement for sending only encrypted DNS data on a 289 DNS-over-TLS port (Section 3.2), when using TCP Fast Open the client 290 and server MUST immediately initiate or resume a TLS handshake (clear 291 text DNS MUST NOT be exchanged). DNS servers SHOULD enable fast TLS 292 session resumption [RFC5077] and this SHOULD be used when 293 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 [RFC7766]. 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 security 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's DNS 318 server option [RFC3646] to discover the IP address followed by 319 attemting the DNS-over-TLS on port 853, or with a future DHCP option 320 that specifies DNS port). With such a discovered DNS server, the 321 client might or might not validate the resolver. These choices 322 maximize availability and performance, but they leave the client 323 vulnerable to on-path attacks that remove privacy. 325 Opportunistic privacy can be used by any current client, but it only 326 provides privacy when there are no on-path active attackers. 328 4.2. Out-of-band Key-pinned Privacy Profile 330 The out-of-band key-pinned privacy profile can be used in 331 environments where an established trust relationship already exists 332 between DNS clients and servers (e.g., stub-to-recursive in 333 enterprise networks, actively-maintained contractual service 334 relationships, or a client using a public DNS resolver). The result 335 of this profile is that the client has strong guarantees about the 336 privacy of its DNS data by connecting only to servers it can 337 authenticate. Operators of a DNS-over-TLS service in this profile 338 are expected to provide pins that are specific to the service being 339 pinned (i.e., public keys belonging directly to the end-entity or to 340 a service-specific private CA) and not to public key(s) of a generic 341 public CA. 343 In this profile, clients authenticate servers by matching a set of 344 Subject Public Key Info (SPKI) Fingerprints in an analogous manner to 345 that described in [RFC7469]. With this out-of-band key-pinned 346 privacy profile, client administrators SHOULD deploy a backup pin 347 along with the primary pin, for the reasons explained in [RFC7469]. 348 A backup pin is especially helpful in the event of a key rollover, so 349 that a server operator does not have to coordinate key transitions 350 with all its clients simultaneously. After a change of keys on the 351 server, an updated pinset SHOULD be distributed to all clients in 352 some secure way in preparation for future key rollover. The 353 mechanism for out-of-band pinset update is out of scope for this 354 document. 356 Such a client will only use DNS servers for which an SPKI Fingerprint 357 pinset has been provided. The possession of trusted pre-deployed 358 pinset allows the client to detect and prevent person-in-the-middle 359 and downgrade attacks. 361 However, a configured DNS server may be temporarily unavailable when 362 configuring a network. For example, for clients on networks that 363 require authentication through web-based login, such authentication 364 may rely on DNS interception and spoofing. Techniques such as those 365 used by DNSSEC-trigger [dnssec-trigger] MAY be used during network 366 configuration, with the intent to transition to the designated DNS 367 provider after authentication. The user MUST be alerted whenever 368 possible that the DNS is not private during such bootstrap. 370 Upon successful TLS connection and handshake, the client computes the 371 SPKI Fingerprints for the public keys found in the validated server's 372 certificate chain (or in the raw public key, if the server provides 373 that instead). If a computed fingerprint exactly matches one of the 374 configured pins the client continues with the connection as normal. 375 Otherwise, the client MUST treat the SPKI validation failure as a 376 non-recoverable error. Appendix A provides a detailed example of how 377 this authentication could be performed in practice. 379 Implementations of this privacy profile MUST support the calculation 380 of a fingerprint as the SHA-256 [RFC6234] hash of the DER-encoded 381 ASN.1 representation of the Subject Public Key Info (SPKI) of an 382 X.509 certificate. Implementations MUST support the representation 383 of a SHA-256 fingerprint as a base 64 encoded character string 384 [RFC4648]. Additional fingerprint types MAY also be supported. 386 5. Performance Considerations 388 DNS-over-TLS incurs additional latency at session startup. It also 389 requires additional state (memory) and increased processing (CPU). 391 Latency: Compared to UDP, DNS-over-TCP requires an additional round- 392 trip-time (RTT) of latency to establish a TCP connection. TCP 393 Fast Open [RFC7413] can eliminate that RTT when information exists 394 from prior connections. The TLS handshake adds another two RTTs 395 of latency. Clients and servers should support connection 396 keepalive (reuse) and out of order processing to amortize 397 connection setup costs. Fast TLS connection resumption [RFC5077] 398 further reduces the setup delay and avoids the DNS server keeping 399 per-client session state. 401 TLS False Start [draft-ietf-tls-falsestart] can also lead to a 402 latency reduction in certain situations. Implementations 403 supporting TLS false start need to be aware that it imposes 404 additional constraints on how one uses TLS, over and above those 405 stated in [BCP195]. It is unsafe to use false start if your 406 implementation and deployment does not adhere to these specific 407 requirements. See [draft-ietf-tls-falsestart] for the details of 408 these additional constraints. 410 State: The use of connection-oriented TCP requires keeping 411 additional state at the server in both the kernel and application. 412 The state requirements are of particular concern on servers with 413 many clients, although memory-optimized TLS can add only modest 414 state over TCP. Smaller timeout values will reduce the number of 415 concurrent connections, and servers can preemptively close 416 connections when resource limits are exceeded. 418 Processing: Use of TLS encryption algorithms results in slightly 419 higher CPU usage. Servers can choose to refuse new DNS-over-TLS 420 clients if processing limits are exceeded. 422 Number of connections: To minimize state on DNS servers and 423 connection startup time, clients SHOULD minimize creation of new 424 TCP connections. Use of a local DNS request aggregator (a 425 particular type of forwarder) allows a single active DNS-over-TLS 426 connection from any given client computer to its server. 427 Additional guidance can be found in [RFC7766]. 429 A full performance evaluation is outside the scope of this 430 specification. A more detailed analysis of the performance 431 implications of DNS-over-TLS (and DNS-over-TCP) is discussed in 432 [tdns] and [RFC7766]. 434 6. IANA Considerations 436 IANA is requested to add the following value to the "Service Name and 437 Transport Protocol Port Number Registry" registry in the System 438 Range. The registry for that range requires IETF Review or IESG 439 Approval [RFC6335] and such a review was requested using the Early 440 Allocation process [RFC7120] for the well-known TCP port in this 441 document. 443 We further recommend that IANA reserve the same port number over UDP 444 for the proposed DNS-over-DTLS protocol [draft-ietf-dprive-dnsodtls]. 446 IANA responded to the early allocation request with the following 447 TEMPORARY assignment: 449 Service Name domain-s 450 Port Number 853 451 Transport Protocol(s) TCP/UDP 452 Assignee IETF DPRIVE Chairs 453 Contact Paul Hoffman 454 Description DNS query-response protocol run over TLS/DTLS 455 Reference This document 457 The TEMPORARY assignment expires 2016-10-08. IANA is requested to 458 make the assigmnent permanent upon publication of this document as an 459 RFC. 461 7. Design Evolution 463 [Note to RFC Editor: please do not remove this section as it may be 464 useful to future Foo-over-TLS efforts] 466 Earlier versions of this document proposed an upgrade-based approach 467 to establish a TLS session. The client would signal its interest in 468 TLS by setting a "TLS OK" bit in the EDNS0 flags field. A server 469 would signal its acceptance by responding with the TLS OK bit set. 471 Since we assume the client doesn't want to reveal (leak) any 472 information prior to securing the channel, we proposed the use of a 473 "dummy query" that clients could send for this purpose. The proposed 474 query name was STARTTLS, query type TXT, and query class CH. 476 The TLS OK signaling approach has both advantages and disadvantages. 477 One important advantage is that clients and servers could negotiate 478 TLS. If the server is too busy, or doesn't want to provide TLS 479 service to a particular client, it can respond negatively to the TLS 480 probe. An ancillary benefit is that servers could collect 481 information on adoption of DNS-over-TLS (via the TLS OK bit in 482 queries) before implementation and deployment. Another anticipated 483 advantage is the expectation that DNS-over-TLS would work over port 484 53. That is, no need to "waste" another port and deploy new firewall 485 rules on middleboxes. 487 However, at the same time, there was uncertainty whether or not 488 middleboxes would pass the TLS OK bit, given that the EDNS0 flags 489 field has been unchanged for many years. Another disadvantage is 490 that the TLS OK bit may make downgrade attacks easy and 491 indistinguishable from broken middleboxes. From a performance 492 standpoint, the upgrade-based approach had the disadvantage of 493 requiring 1xRTT additional latency for the dummy query. 495 Following this proposal, DNS-over-DTLS was proposed separately. DNS- 496 over-DTLS claimed it could work over port 53, but only because a non- 497 DTLS server interprets a DNS-over-DTLS query as a response. That is, 498 the non-DTLS server observes the QR flag set to 1. While this 499 technically works, it seems unfortunate and perhaps even undesirable. 501 DNS over both TLS and DTLS can benefit from a single well-known port 502 and avoid extra latency and mis-interpreted queries as responses. 504 8. Implementation Status 506 [Note to RFC Editor: please remove this section and reference to RFC 507 6982 prior to publication.] 509 This section records the status of known implementations of the 510 protocol defined by this specification at the time of posting of this 511 Internet-Draft, and is based on a proposal described in RFC 6982. 512 The description of implementations in this section is intended to 513 assist the IETF in its decision processes in progressing drafts to 514 RFCs. Please note that the listing of any individual implementation 515 here does not imply endorsement by the IETF. Furthermore, no effort 516 has been spent to verify the information presented here that was 517 supplied by IETF contributors. This is not intended as, and must not 518 be construed to be, a catalog of available implementations or their 519 features. Readers are advised to note that other implementations may 520 exist. 522 According to RFC 6982, "this will allow reviewers and working groups 523 to assign due consideration to documents that have the benefit of 524 running code, which may serve as evidence of valuable experimentation 525 and feedback that have made the implemented protocols more mature. 526 It is up to the individual working groups to use this information as 527 they see fit". 529 8.1. Unbound 531 The Unbound recursive name server software added support for DNS- 532 over-TLS in version 1.4.14. The unbound.conf configuration file has 533 the following configuration directives: ssl-port, ssl-service-key, 534 ssl-service-pem, ssl-upstream. See 535 https://unbound.net/documentation/unbound.conf.html. 537 8.2. ldns 539 Sinodun Internet Technologies has implemented DNS-over-TLS in the 540 ldns library from NLnetLabs. This also gives DNS-over-TLS support to 541 the drill DNS client program. Patches available at 542 https://portal.sinodun.com/stash/projects/TDNS/repos/dns-over- 543 tls_patches/browse. 545 8.3. digit 547 The digit DNS client from USC/ISI supports DNS-over-TLS. Source code 548 available at http://www.isi.edu/ant/software/tdns/index.html. 550 8.4. getdns 552 The getdns API implementation supports DNS-over-TLS. Source code 553 available at https://getdnsapi.net. 555 9. Security Considerations 557 Use of DNS-over-TLS is designed to address the privacy risks that 558 arise out of the ability to eavesdrop on DNS messages. It does not 559 address other security issues in DNS, and there are a number of 560 residual risks that may affect its success at protecting privacy: 562 1. There are known attacks on TLS, such as person-in-the-middle and 563 protocol downgrade. These are general attacks on TLS and not 564 specific to DNS-over-TLS; please refer to the TLS RFCs for 565 discussion of these security issues. Clients and servers MUST 566 adhere to the TLS implementation recommendations and security 567 considerations of [BCP195]. DNS clients keeping track of servers 568 known to support TLS enables clients to detect downgrade attacks. 569 For servers with no connection history and no apparent support 570 for TLS, depending on their Privacy Profile and privacy 571 requirements, clients may choose to (a) try another server when 572 available, (b) continue without TLS, or (c) refuse to forward the 573 query. 575 2. Middleboxes [RFC3234] are present in some networks and have been 576 known to interfere with normal DNS resolution. Use of a 577 designated port for DNS-over-TLS should avoid such interference. 578 In general, clients that attempt TLS and fail can either fall 579 back on unencrypted DNS, or wait and retry later, depending on 580 their Privacy Profile and privacy requirements. 582 3. Any DNS protocol interactions performed in the clear can be 583 modified by a person-in-the-middle attacker. For example, 584 unencrypted queries and responses might take place over port 53 585 between a client and server. For this reason, clients MAY 586 discard cached information about server capabilities advertised 587 in clear text. 589 4. This document does not itself specify ideas to resist known 590 traffic analysis or side channel leaks. Even with encrypted 591 messages, a well-positioned party may be able to glean certain 592 details from an analysis of message timings and sizes. Clients 593 and servers may consider the use of a padding method to address 594 privacy leakage due to message sizes [I-D.edns0-padding]. Since 595 traffic analysis can be based on many kinds of patterns and many 596 kinds of classifiers, simple padding schemes alone might not be 597 sufficient to mitigate such an attack. Padding will, however, 598 form a part of more complex mitigations for traffic analysis 599 attacks that are likely to be developed over time. Implementers 600 who can offer flexibility in terms of how padding can be used may 601 be in a better position to enable such mitigations to be deployed 602 in future. 604 As noted earlier, DNSSEC and DNS-over-TLS are independent and fully 605 compatible protocols, each solving different problems. The use of 606 one does not diminish the need nor the usefulness of the other. 608 10. Contributing Authors 610 The below individuals contributed significantly to the draft, and so 611 we have listed additional authors in this section. 613 Sara Dickinson 614 Sinodun Internet Technologies 615 Magdalen Centre 616 Oxford Science Park 617 Oxford OX4 4GA 618 United Kingdom 619 Email: sara@sinodun.com 620 URI: http://sinodun.com 622 Daniel Kahn Gillmor 623 ACLU 624 125 Broad Street, 18th Floor 625 New York, NY 10004 626 United States 628 11. Acknowledgments 630 The authors would like to thank Stephane Bortzmeyer, John Dickinson, 631 Brian Haberman, Christian Huitema, Shumon Huque, Kim-Minh Kaplan, 632 Simon Joseffson, Simon Kelley, Warren Kumari, John Levine, Ilari 633 Liusvaara, Bill Manning, George Michaelson, Eric Osterweil, Jinmei 634 Tatuya, Tim Wicinski, and Glen Wiley for reviewing this Internet- 635 draft. They also thank Nikita Somaiya for early work on this idea. 637 Work by Zi Hu, Liang Zhu, and John Heidemann on this document is 638 partially sponsored by the U.S. Dept. of Homeland Security (DHS) 639 Science and Technology Directorate, HSARPA, Cyber Security Division, 640 BAA 11-01-RIKA and Air Force Research Laboratory, Information 641 Directorate under agreement number FA8750-12-2-0344, and contract 642 number D08PC75599. 644 12. References 646 12.1. Normative References 648 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 649 "Recommendations for Secure Use of Transport Layer 650 Security (TLS) and Datagram Transport Layer Security 651 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 652 2015. 654 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 655 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 656 . 658 [RFC1035] Mockapetris, P., "Domain names - implementation and 659 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 660 November 1987, . 662 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 663 Requirement Levels", BCP 14, RFC 2119, 664 DOI 10.17487/RFC2119, March 1997, 665 . 667 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 668 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 669 . 671 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 672 "Transport Layer Security (TLS) Session Resumption without 673 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 674 January 2008, . 676 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 677 (TLS) Protocol Version 1.2", RFC 5246, 678 DOI 10.17487/RFC5246, August 2008, 679 . 681 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 682 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 683 DOI 10.17487/RFC6234, May 2011, 684 . 686 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 687 Cheshire, "Internet Assigned Numbers Authority (IANA) 688 Procedures for the Management of the Service Name and 689 Transport Protocol Port Number Registry", BCP 165, 690 RFC 6335, DOI 10.17487/RFC6335, August 2011, 691 . 693 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 694 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 695 2014, . 697 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 698 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 699 2015, . 701 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 702 D. Wessels, "DNS Transport over TCP - Implementation 703 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 704 . 706 12.2. Informative References 708 [dempsky-dnscurve] 709 Dempsky, M., "DNSCurve", draft-dempsky-dnscurve-01 (work 710 in progress), August 2010, 711 . 713 [dgr-dprive-dtls-and-tls-profiles] 714 Dickinson, S., Gillmor, D., and T. Reddy, "Authentication 715 and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS", 716 draft-dgr-dprive-dtls-and-tls-profiles-00 (work in 717 progress), December 2015, . 720 [dnscrypt-website] 721 Denis, F., "DNSCrypt", December 2015, 722 . 724 [dnssec-trigger] 725 NLnet Labs, "Dnssec-Trigger", May 2014, 726 . 728 [draft-ietf-dprive-dnsodtls] 729 Reddy, T., Wing, D., and P. Patil, "DNS over DTLS 730 (DNSoD)", draft-ietf-dprive-dnsodtls-01 (work in 731 progress), June 2015, . 734 [draft-ietf-tls-falsestart] 735 Moeller, B., Langley, A., and N. Modadugu, "Transport 736 Layer Security (TLS) False Start", draft-ietf-tls- 737 falsestart-01 (work in progress), November 2015, 738 . 740 [I-D.confidentialdns] 741 Wijngaards, W., "Confidential DNS", draft-wijngaards- 742 dnsop-confidentialdns-03 (work in progress), March 2015, 743 . 746 [I-D.edns-tcp-keepalive] 747 Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 748 edns-tcp-keepalive EDNS0 Option", draft-ietf-dnsop-edns- 749 tcp-keepalive-02 (work in progress), July 2015, 750 . 753 [I-D.edns0-padding] 754 Mayrhofer, A., "The EDNS(0) Padding Option", draft- 755 mayrhofer-edns0-padding-01 (work in progress), August 756 2015, . 759 [I-D.ipseca] 760 Osterweil, E., Wiley, G., Okubo, T., Lavu, R., and A. 761 Mohaisen, "Opportunistic Encryption with DANE Semantics 762 and IPsec: IPSECA", draft-osterweil-dane-ipsec-03 (work in 763 progress), July 2015, . 766 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 767 DOI 10.17487/RFC2818, May 2000, 768 . 770 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 771 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 772 . 774 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 775 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 776 DOI 10.17487/RFC3646, December 2003, 777 . 779 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 780 Rose, "DNS Security Introduction and Requirements", 781 RFC 4033, DOI 10.17487/RFC4033, March 2005, 782 . 784 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 785 Housley, R., and W. Polk, "Internet X.509 Public Key 786 Infrastructure Certificate and Certificate Revocation List 787 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 788 . 790 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 791 of Named Entities (DANE) Transport Layer Security (TLS) 792 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 793 2012, . 795 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 796 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 797 2014, . 799 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 800 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 801 . 803 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 804 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 805 December 2014, . 807 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 808 DOI 10.17487/RFC7626, August 2015, 809 . 811 [tdns] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A., 812 and N. Somaiya, "T-DNS: Connection-Oriented DNS to Improve 813 Privacy and Security", Technical report ISI-TR-688, 814 February 2014, . 817 Appendix A. Out-of-band Key-pinned Privacy Profile Example 819 This section presents an example of how the out-of-band key-pinned 820 privacy profile could work in practice based on a minimal pinset (two 821 pins). 823 A DNS client system is configured with an out-of-band key-pinned 824 privacy profile from a network service, using a pinset containing two 825 pins. Represented in HPKP [RFC7469] style, the pins are: 827 o pin-sha256="FHkyLhvI0n70E47cJlRTamTrnYVcsYdjUGbr79CfAVI=" 829 o pin-sha256="dFSY3wdPU8L0u/8qECuz5wtlSgnorYV2f66L6GNQg6w=" 831 The client also configures the IP addresses of its expected DNS 832 server, 192.0.2.3 and 192.0.2.4. 834 The client connects to 192.0.2.3 on TCP port 853 and begins the TLS 835 handshake, negotiation TLS 1.2 with a diffie-hellman key exchange. 836 The server sends a Certificate message with a list of three 837 certificates (A, B, and C), and signs the ServerKeyExchange message 838 correctly with the public key found certificate A. 840 The client now takes the SHA-256 digest of the SPKI in cert A, and 841 compares it against both pins in the pinset. If either pin matches, 842 the verification is successful; the client continues with the TLS 843 connection and can make its first DNS query. 845 If neither pin matches the SPKI of cert A, the client verifies that 846 cert A is actually issued by cert B. If it is, it takes the SHA-256 847 digest of the SPKI in cert B and compares it against both pins in the 848 pinset. If either pin matches, the verification is successful. 849 Otherwise, it verifes that B was issued by C, and then compares the 850 pins against the digest of C's SPKI. 852 If none of the SPKIs in the cryptographically-valid chain of certs 853 match any pin in the pinset, the client closes the connection with an 854 error, and marks the IP address as failed. 856 Authors' Addresses 858 Zi Hu 859 USC/Information Sciences Institute 860 4676 Admiralty Way, Suite 1133 861 Marina del Rey, CA 90292 862 United States 864 Phone: +1 213 587 1057 865 Email: zihu@outlook.com 867 Liang Zhu 868 USC/Information Sciences Institute 869 4676 Admiralty Way, Suite 1133 870 Marina del Rey, CA 90292 871 United States 873 Phone: +1 310 448 8323 874 Email: liangzhu@usc.edu 876 John Heidemann 877 USC/Information Sciences Institute 878 4676 Admiralty Way, Suite 1001 879 Marina del Rey, CA 90292 880 United States 882 Phone: +1 310 822 1511 883 Email: johnh@isi.edu 885 Allison Mankin 887 Phone: +1 301 728 7198 888 Email: Allison.mankin@gmail.com 889 Duane Wessels 890 Verisign Labs 891 12061 Bluemont Way 892 Reston, VA 20190 893 United States 895 Phone: +1 703 948 3200 896 Email: dwessels@verisign.com 898 Paul Hoffman 899 ICANN 901 Email: paul.hoffman@icann.org