idnits 2.17.00 (12 Aug 2021) /tmp/idnits49907/draft-ietf-dprive-dns-over-tls-08.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 (March 15, 2016) is 2257 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 738, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 756, but no explicit reference was found in the text == Unused Reference: 'RFC6698' is defined on line 762, but no explicit reference was found in the text ** 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: draft-ietf-dnsop-edns-tcp-keepalive has been published as RFC 7828 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 3 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 16, 2016 USC/Information Sciences 6 Institute 7 A. Mankin 9 D. Wessels 10 Verisign Labs 11 P. Hoffman 12 ICANN 13 March 15, 2016 15 Specification for DNS over TLS 16 draft-ietf-dprive-dns-over-tls-08 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 RFC 7626. 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 16, 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 . . . . . . . . . . . . . . . . . . 10 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . . 11 85 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 86 8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 91 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 14 92 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 93 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 95 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 96 Appendix A. Out-of-band Key-pinned Privacy Profile Example . . . 19 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 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 also adopted a DNS-over-DTLS [draft-ietf-dprive-dnsodtls] 124 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 [BCP195]. 139 The protocol described here works for queries and responses between 140 stub clients and recursive servers. It might work equally between 141 recursive clients and authoritative servers, but this application of 142 the protocol is out of scope for the DNS PRIVate Exchange (DPRIVE) 143 Working Group per its current charter. 145 This document describes two profiles in Section 4 providing different 146 levels of assurance of privacy: an opportunistic privacy profile and 147 an out-of-band key-pinned privacy profile. It is expected that a 148 future document based on [dgr-dprive-dtls-and-tls-profiles] will 149 further describe additional privacy profiles for DNS over both TLS 150 and DTLS. 152 An earlier version of this document described a technique for 153 upgrading a DNS-over-TCP connection to a DNS-over-TLS session with, 154 essentially, "STARTTLS for DNS". To simplify the protocol, this 155 document now only uses a well-known port to specify TLS use, omitting 156 the upgrade approach. The upgrade approach no longer appears in this 157 document, which now focuses exclusively on the use of a well-known 158 port for DNS-over-TLS. 160 2. Reserved Words 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [RFC2119]. 166 3. Establishing and Managing DNS-over-TLS Sessions 168 3.1. Session Initiation 170 A DNS server that supports DNS-over-TLS MUST by default listen for 171 and accept TCP connections on port 853. By mutual agreement with its 172 clients, the server MAY, instead, use a port other than 853 for DNS- 173 over-TLS. In order to use a port other than 853, both clients and 174 servers would need a configuration option in their software. 176 DNS clients desiring privacy from DNS-over-TLS from a particular 177 server MUST by default establish a TCP connection to port 853 on the 178 server. By mutual agreement with its server, the client MAY, 179 instead, use a port other than port 853 for DNS-over-TLS. Such an 180 other port MUST NOT be port 53, but MAY be from the "first-come, 181 first-served" port range. This recommendation against use of port 53 182 for DNS-over-TLS is to avoid complication in selecting use or non-use 183 of TLS, and to reduce risk of downgrade attacks. The first data 184 exchange on this TCP connection MUST be the client and server 185 initiating a TLS handshake using the procedure described in 186 [RFC5246]. 188 DNS clients and servers MUST NOT use port 853 to transport clear text 189 DNS messages. DNS clients MUST NOT send and DNS servers MUST NOT 190 respond to clear text DNS messages on any port used for DNS-over-TLS 191 (including, for example, after a failed TLS handshake). There are 192 significant security issues in mixing protected and unprotected data 193 and for this reason TCP connections on a port designated by a given 194 server for DNS-over-TLS are reserved purely for encrypted 195 communications. 197 DNS clients SHOULD remember server IP addresses that don't support 198 DNS-over-TLS, including timeouts, connection refusals, and TLS 199 handshake failures, and not request DNS-over-TLS from them for a 200 reasonable period (such as one hour per server). DNS clients 201 following an out-of-band key-pinned privacy profile (Section 4.2) MAY 202 be more aggressive about retrying DNS-over-TLS connection failures. 204 3.2. TLS Handshake and Authentication 206 Once the DNS client succeeds in connecting via TCP on the well-known 207 port for DNS-over-TLS, it proceeds with the TLS handshake [RFC5246], 208 following the best practices specified in [BCP195]. 210 The client will then authenticate the server, if required. This 211 document does not propose new ideas for authentication. Depending on 212 the privacy profile in use Section 4, the DNS client may choose not 213 to require authentication of the server, or it may make use of a 214 trusted Subject Public Key Info (SPKI) Fingerprint pinset. 216 After TLS negotiation completes, the connection will be encrypted and 217 is now protected from eavesdropping. 219 3.3. Transmitting and Receiving Messages 221 All messages (requests and responses) in the established TLS session 222 MUST use the two-octet length field described in Section 4.2.2 of 223 [RFC1035]. For reasons of efficiency, DNS clients and servers SHOULD 224 pass the two-octet length field, and the message described by that 225 length field, to the TCP layer at the same time (e.g., in a single 226 "write" system call) to make it more likely that all the data will be 227 transmitted in a single TCP segment ([RFC7766], Section 8). 229 In order to minimize latency, clients SHOULD pipeline multiple 230 queries over a TLS session. When a DNS client sends multiple queries 231 to a server, it should not wait for an outstanding reply before 232 sending the next query ([RFC7766], Section 6.2.1.1). 234 Since pipelined responses can arrive out of order, clients MUST match 235 responses to outstanding queries on the same TLS connection using the 236 Message ID. If the response contains a question section, the client 237 MUST match the QNAME, QCLASS, and QTYPE fields. Failure by clients 238 to properly match responses to outstanding queries can have serious 239 consequences for interoperability ([RFC7766], Section 7). 241 3.4. Connection Reuse, Close and Reestablishment 243 For DNS clients that use library functions such as "getaddrinfo()" 244 and "gethostbyname()", current implementations are known to open and 245 close TCP connections each DNS call. To avoid excess TCP 246 connections, each with a single query, clients SHOULD reuse a single 247 TCP connection to the recursive resolver. Alternatively they may 248 prefer to use UDP to a DNS-over-TLS enabled caching resolver on the 249 same machine that then uses a system-wide TCP connection to the 250 recursive resolver. 252 In order to amortize TCP and TLS connection setup costs, clients and 253 servers SHOULD NOT immediately close a connection after each 254 response. Instead, clients and servers SHOULD reuse existing 255 connections for subsequent queries as long as they have sufficient 256 resources. In some cases, this means that clients and servers may 257 need to keep idle connections open for some amount of time. 259 Proper management of established and idle connections is important to 260 the healthy operation of a DNS server. An implementor of DNS-over- 261 TLS SHOULD follow best practices for DNS-over-TCP, as described in 262 [RFC7766]. Failure to do so may lead to resource exhaustion and 263 denial-of-service. 265 Whereas client and server implementations from the [RFC1035] era are 266 known to have poor TCP connection management, this document 267 stipulates that successful negotiation of TLS indicates the 268 willingness of both parties to keep idle DNS connections open, 269 independent of timeouts or other recommendations for DNS-over-TCP 270 without TLS. In other words, software implementing this protocol is 271 assumed to support idle, persistent connections and be prepared to 272 manage multiple, potentially long-lived TCP connections. 274 This document does not make specific recommendations for timeout 275 values on idle connections. Clients and servers should reuse and/or 276 close connections depending on the level of available resources. 277 Timeouts may be longer during periods of low activity and shorter 278 during periods of high activity. Current work in this area may also 279 assist DNS-over-TLS clients and servers in selecting useful timeout 280 values [I-D.edns-tcp-keepalive] [tdns]. 282 Clients and servers that keep idle connections open MUST be robust to 283 termination of idle connection by either party. As with current DNS- 284 over-TCP, DNS servers MAY close the connection at any time (perhaps 285 due to resource constraints). As with current DNS-over-TCP, clients 286 MUST handle abrupt closes and be prepared to reestablish connections 287 and/or retry queries. 289 When reestablishing a DNS-over-TCP connection that was terminated, as 290 discussed in [RFC7766], TCP Fast Open [RFC7413] is of benefit. 291 Underlining the requirement for sending only encrypted DNS data on a 292 DNS-over-TLS port (Section 3.2), when using TCP Fast Open the client 293 and server MUST immediately initiate or resume a TLS handshake (clear 294 text DNS MUST NOT be exchanged). DNS servers SHOULD enable fast TLS 295 session resumption [RFC5077] and this SHOULD be used when 296 reestablishing connections. 298 When closing a connection, DNS servers SHOULD use the TLS close- 299 notify request to shift TCP TIME-WAIT state to the clients. 300 Additional requirements and guidance for optimizing DNS-over-TCP are 301 provided by [RFC7766]. 303 4. Usage Profiles 305 This protocol provides flexibility to accommodate several different 306 use cases. This document defines two usage profiles: (1) 307 opportunistic privacy, and (2) out-of-band key-pinned authentication 308 that can be used to obtain stronger privacy guarantees if the client 309 has a trusted relationship with a DNS server supporting TLS. 310 Additional methods of authentication will be defined in a forthcoming 311 draft [dgr-dprive-dtls-and-tls-profiles]. 313 4.1. Opportunistic Privacy Profile 315 For opportunistic privacy, analogous to SMTP opportunistic security 316 [RFC7435], one does not require privacy, but one desires privacy when 317 possible. 319 With opportunistic privacy, a client might learn of a TLS-enabled 320 recursive DNS resolver from an untrusted source (such as DHCP's DNS 321 server option [RFC3646] to discover the IP address followed by 322 attemting the DNS-over-TLS on port 853, or with a future DHCP option 323 that specifics DNS port). With such an discovered DNS server, the 324 client might or might not validate the resolver. These choices 325 maximize availability and performance, but they leave the client 326 vulnerable to on-path attacks that remove privacy. 328 Opportunistic privacy can be used by any current client, but it only 329 provides privacy when there are no on-path active attackers. 331 4.2. Out-of-band Key-pinned Privacy Profile 333 The out-of-band key-pinned privacy profile can be used in 334 environments where an established trust relationship already exists 335 between DNS clients and servers (e.g., stub-to-recursive in 336 enterprise networks, actively-maintained contractual service 337 relationships, or a client using a public DNS resolver). The result 338 of this profile is that the client has strong guarantees about the 339 privacy of its DNS data by connecting only to servers it can 340 authenticate. Operators of a DNS-over-TLS service in this profile 341 are expected to provide pins that are specific to the service being 342 pinned (i.e., public keys belonging directly to the end-entity or to 343 a service-specific private CA) and not to public key(s) of a generic 344 public CA. 346 In this profile, clients authenticate servers by matching a set of 347 Subject Public Key Info (SPKI) Fingerprints in an analogous manner to 348 that described in [RFC7469]. With this out-of-band key-pinned 349 privacy profile, client administrators SHOULD deploy a backup pin 350 along with the primary pin, for the reasons explained in [RFC7469]. 351 A backup pin is especially helpful in the event of a key rollover, so 352 that a server operator does not have to coordinate key transitions 353 with all its clients simultaneously. After a change of keys on the 354 server, an updated pinset SHOULD be distributed to all clients in 355 some secure way in preparation for future key rollover. The 356 mechanism for out-of-band pinset update is out of scope for this 357 document. 359 Such a client will only use DNS servers for which an SPKI Fingerprint 360 pinset has been provided. The possession of trusted pre-deployed 361 pinset allows the client to detect and prevent person-in-the-middle 362 and downgrade attacks. 364 However, a configured DNS server may be temporarily unavailable when 365 configuring a network. For example, for clients on networks that 366 require authentication through web-based login, such authentication 367 may rely on DNS interception and spoofing. Techniques such as those 368 used by DNSSEC-trigger [dnssec-trigger] MAY be used during network 369 configuration, with the intent to transition to the designated DNS 370 provider after authentication. The user MUST be alerted whenever 371 possible that the DNS is not private during such bootstrap. 373 Upon successful TLS connection and handshake, the client computes the 374 SPKI Fingerprints for the public keys found in the validated server's 375 certificate chain (or in the raw public key, if the server provides 376 that instead). If a computed fingerprint exactly matches one of the 377 configured pins the client continues with the connection as normal. 378 Otherwise, the client MUST treat the SPKI validation failure as a 379 non-recoverable error. Appendix A provides a detailed example of how 380 this authentication could be performed in practice. 382 Implementations of this privacy profile MUST support the calculation 383 of a fingerprint as the SHA-256 [RFC6234] hash of the DER-encoded 384 ASN.1 representation of the Subject Public Key Info (SPKI) of an 385 X.509 certificate. Implementations MUST support the representation 386 of a SHA-256 fingerprint as a base 64 encoded character string 387 [RFC4648]. Additional fingerprint types MAY also be supported. 389 5. Performance Considerations 391 DNS-over-TLS incurs additional latency at session startup. It also 392 requires additional state (memory) and increased processing (CPU). 394 Latency: Compared to UDP, DNS-over-TCP requires an additional round- 395 trip-time (RTT) of latency to establish a TCP connection. TCP 396 Fast Open [RFC7413] can eliminate that RTT when information exists 397 from prior connections. The TLS handshake adds another two RTTs 398 of latency. Clients and servers should support connection 399 keepalive (reuse) and out of order processing to amortize 400 connection setup costs. Fast TLS connection resumption [RFC5077] 401 further reduces the setup delay and avoids the DNS server keeping 402 per-client session state. 404 TLS False Start [draft-ietf-tls-falsestart] can also lead to a 405 latency reduction in certain situations. Implementations 406 supporting TLS false start need to be aware that it imposes 407 additional constraints on how one uses TLS, over and above those 408 stated in [BCP195]. It is unsafe to use false start if your 409 implementation and deployment does not adhere to these specific 410 requirements. See [draft-ietf-tls-falsestart] for the details of 411 these additional constraints. 413 State: The use of connection-oriented TCP requires keeping 414 additional state at the server in both the kernel and application. 415 The state requirements are of particular concern on servers with 416 many clients, although memory-optimized TLS can add only modest 417 state over TCP. Smaller timeout values will reduce the number of 418 concurrent connections, and servers can preemptively close 419 connections when resource limits are exceeded. 421 Processing: Use of TLS encryption algorithms results in slightly 422 higher CPU usage. Servers can choose to refuse new DNS-over-TLS 423 clients if processing limits are exceeded. 425 Number of connections: To minimize state on DNS servers and 426 connection startup time, clients SHOULD minimize creation of new 427 TCP connections. Use of a local DNS request aggregator (a 428 particular type of forwarder) allows a single active DNS-over-TLS 429 connection from any given client computer to its server. 430 Additional guidance can be found in [RFC7766]. 432 A full performance evaluation is outside the scope of this 433 specification. A more detailed analysis of the performance 434 implications of DNS-over-TLS (and DNS-over-TCP) is discussed in 435 [tdns] and [RFC7766]. 437 6. IANA Considerations 439 IANA is requested to add the following value to the "Service Name and 440 Transport Protocol Port Number Registry" registry in the System 441 Range. The registry for that range requires IETF Review or IESG 442 Approval [RFC6335] and such a review was requested using the Early 443 Allocation process [RFC7120] for the well-known TCP port in this 444 document. 446 We further recommend that IANA reserve the same port number over UDP 447 for the proposed DNS-over-DTLS protocol [draft-ietf-dprive-dnsodtls]. 449 IANA responded to the early allocation request with the following 450 TEMPORARY assignment: 452 Service Name domain-s 453 Port Number 853 454 Transport Protocol(s) TCP/UDP 455 Assignee IETF DPRIVE Chairs 456 Contact Paul Hoffman 457 Description DNS query-response protocol run over TLS/DTLS 458 Reference This document 460 The TEMPORARY assignment expires 2016-10-08. IANA is requested to 461 make the assigmnent permanent upon publication of this document as an 462 RFC. 464 7. Design Evolution 466 [Note to RFC Editor: please do not remove this section as it may be 467 useful to future Foo-over-TLS efforts] 469 Earlier versions of this document proposed an upgrade-based approach 470 to establishing a TLS session. The client would signal its interest 471 in TLS by setting a "TLS OK" bit in the EDNS0 flags field. A server 472 would signal its acceptance by responding with the TLS OK bit set. 474 Since we assume the client doesn't want to reveal (leak) any 475 information prior to securing the channel, we proposed the use of a 476 "dummy query" that clients could send for this purpose. The proposed 477 query name was STARTTLS, query type TXT, and query class CH. 479 The TLS OK signaling approach has both advantages and disadvantages. 480 One important advantage is that clients and servers could negotiate 481 TLS. If the server is too busy, or doesn't want to provide TLS 482 service to a particular client, it can respond negatively to the TLS 483 probe. An ancillary benefit is that servers could collect 484 information on adoption of DNS-over-TLS (via the TLS OK bit in 485 queries) before implementation and deployment. Another anticipated 486 advantage is the expectation that DNS-over-TLS would work over port 487 53. That is, no need to "waste" another port and deploy new firewall 488 rules on middleboxes. 490 However, at the same time, there was uncertainty whether or not 491 middleboxes would pass the TLS OK bit, given that the EDNS0 flags 492 field has been unchanged for many years. Another disadvantage is 493 that the TLS OK bit may make downgrade attacks easy and 494 indistinguishable from broken middleboxes. From a performance 495 standpoint, the upgrade-based approach had the disadvantage of 496 requiring 1xRTT additional latency for the dummy query. 498 Following this proposal, DNS-over-DTLS was proposed separately. DNS- 499 over-DTLS claimed it could work over port 53, but only because a non- 500 DTLS server interprets a DNS-over-DTLS query as a response. That is, 501 the non-DTLS server observes the QR flag set to 1. While this 502 technically works, it seems unfortunate and perhaps even undesirable. 504 DNS over both TLS and DTLS can benefit from a single well-known port 505 and avoid extra latency and mis-interpreted queries as responses. 507 8. Implementation Status 509 [Note to RFC Editor: please remove this section and reference to RFC 510 6982 prior to publication.] 512 This section records the status of known implementations of the 513 protocol defined by this specification at the time of posting of this 514 Internet-Draft, and is based on a proposal described in RFC 6982. 515 The description of implementations in this section is intended to 516 assist the IETF in its decision processes in progressing drafts to 517 RFCs. Please note that the listing of any individual implementation 518 here does not imply endorsement by the IETF. Furthermore, no effort 519 has been spent to verify the information presented here that was 520 supplied by IETF contributors. This is not intended as, and must not 521 be construed to be, a catalog of available implementations or their 522 features. Readers are advised to note that other implementations may 523 exist. 525 According to RFC 6982, "this will allow reviewers and working groups 526 to assign due consideration to documents that have the benefit of 527 running code, which may serve as evidence of valuable experimentation 528 and feedback that have made the implemented protocols more mature. 529 It is up to the individual working groups to use this information as 530 they see fit". 532 8.1. Unbound 534 The Unbound recursive name server software added support for DNS- 535 over-TLS in version 1.4.14. The unbound.conf configuration file has 536 the following configuration directives: ssl-port, ssl-service-key, 537 ssl-service-pem, ssl-upstream. See 538 https://unbound.net/documentation/unbound.conf.html. 540 8.2. ldns 542 Sinodun Internet Technologies has implemented DNS-over-TLS in the 543 ldns library from NLnetLabs. This also gives DNS-over-TLS support to 544 the drill DNS client program. Patches available at https:// 545 portal.sinodun.com/stash/projects/TDNS/repos/dns-over-tls_patches/ 546 browse. 548 8.3. digit 550 The digit DNS client from USC/ISI supports DNS-over-TLS. Source code 551 available at http://www.isi.edu/ant/software/tdns/index.html. 553 8.4. getdns 555 The getdns API implementation supports DNS-over-TLS. Source code 556 available at https://getdnsapi.net. 558 9. Security Considerations 560 Use of DNS-over-TLS is designed to address the privacy risks that 561 arise out of the ability to eavesdrop on DNS messages. It does not 562 address other security issues in DNS, and there are a number of 563 residual risks that may affect its success at protecting privacy: 565 1. There are known attacks on TLS, such as person-in-the-middle and 566 protocol downgrade. These are general attacks on TLS and not 567 specific to DNS-over-TLS; please refer to the TLS RFCs for 568 discussion of these security issues. Clients and servers MUST 569 adhere to the TLS implementation recommendations and security 570 considerations of [BCP195]. DNS clients keeping track of servers 571 known to support TLS enables clients to detect downgrade attacks. 572 For servers with no connection history and no apparent support 573 for TLS, depending on their Privacy Profile and privacy 574 requirements, clients may choose to (a) try another server when 575 available, (b) continue without TLS, or (c) refuse to forward the 576 query. 578 2. Middleboxes [RFC3234] are present in some networks and have been 579 known to interfere with normal DNS resolution. Use of a 580 designated port for DNS-over-TLS should avoid such interference. 581 In general, clients that attempt TLS and fail can either fall 582 back on unencrypted DNS, or wait and retry later, depending on 583 their Privacy Profile and privacy requirements. 585 3. Any DNS protocol interactions performed in the clear can be 586 modified by a person-in-the-middle attacker. For example, 587 unencrypted queries and responses might take place over port 53 588 between a client and server. For this reason, clients MAY 589 discard cached information about server capabilities advertised 590 in clear text. 592 4. This document does not itself specify ideas to resist known 593 traffic analysis or side channel leaks. Even with encrypted 594 messages, a well-positioned party may be able to glean certain 595 details from an analysis of message timings and sizes. Clients 596 and servers may consider the use of a padding method to address 597 privacy leakage due to message sizes [I-D.edns0-padding]. Since 598 traffic analysis can be based on many kinds of patterns and many 599 kinds of classifiers, simple padding schemes alone might not be 600 sufficient to mitigate such an attack. Padding will, however, 601 form a part of more complex mitigations for traffic analysis 602 attacks that are likely to be developed over time. Implementers 603 who can offer flexibility in terms of how padding can be used may 604 be in a better position to enable such mitigations to be deployed 605 in future. 607 As noted earlier, DNSSEC and DNS-over-TLS are independent and fully 608 compatible protocols, each solving different problems. The use of 609 one does not diminish the need nor the usefulness of the other. 611 10. Contributing Authors 613 The below individuals contributed significantly to the draft, and so 614 we have listed additional authors in this section. 616 Sara Dickinson 617 Sinodun Internet Technologies 618 Magdalen Centre 619 Oxford Science Park 620 Oxford OX4 4GA 621 United Kingdom 622 Email: sara@sinodun.com 623 URI: http://sinodun.com 625 Daniel Kahn Gillmor 626 ACLU 627 125 Broad Street, 18th Floor 628 New York, NY 10004 629 United States 631 11. Acknowledgments 633 The authors would like to thank Stephane Bortzmeyer, John Dickinson, 634 Brian Haberman, Christian Huitema, Shumon Huque, Kim-Minh Kaplan, 635 Simon Joseffson, Simon Kelley, Warren Kumari, John Levine, Ilari 636 Liusvaara, Bill Manning, George Michaelson, Eric Osterweil, Jinmei 637 Tatuya, Tim Wicinski, and Glen Wiley for reviewing this Internet- 638 draft. They also thank Nikita Somaiya for early work on this idea. 640 Work by Zi Hu, Liang Zhu, and John Heidemann on this document is 641 partially sponsored by the U.S. Dept. of Homeland Security (DHS) 642 Science and Technology Directorate, HSARPA, Cyber Security Division, 643 BAA 11-01-RIKA and Air Force Research Laboratory, Information 644 Directorate under agreement number FA8750-12-2-0344, and contract 645 number D08PC75599. 647 12. References 649 12.1. Normative References 651 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 652 "Recommendations for Secure Use of Transport Layer 653 Security (TLS) and Datagram Transport Layer Security 654 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, 655 May 2015. 657 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 658 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 659 . 661 [RFC1035] Mockapetris, P., "Domain names - implementation and 662 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 663 November 1987, . 665 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 666 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 667 RFC2119, March 1997, 668 . 670 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 671 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 672 . 674 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 675 "Transport Layer Security (TLS) Session Resumption without 676 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 677 January 2008, . 679 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 680 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 681 RFC5246, August 2008, 682 . 684 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 685 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 686 DOI 10.17487/RFC6234, May 2011, 687 . 689 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 690 Cheshire, "Internet Assigned Numbers Authority (IANA) 691 Procedures for the Management of the Service Name and 692 Transport Protocol Port Number Registry", BCP 165, 693 RFC 6335, DOI 10.17487/RFC6335, August 2011, 694 . 696 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 697 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, 698 January 2014, . 700 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 701 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, 702 April 2015, . 704 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 705 D. Wessels, "DNS Transport over TCP - Implementation 706 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 707 . 709 12.2. Informative References 711 [I-D.confidentialdns] 712 Wijngaards, W., "Confidential DNS", 713 draft-wijngaards-dnsop-confidentialdns-03 (work in 714 progress), March 2015, . 717 [I-D.edns-tcp-keepalive] 718 Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 719 edns-tcp-keepalive EDNS0 Option", 720 draft-ietf-dnsop-edns-tcp-keepalive-02 (work in progress), 721 July 2015, . 724 [I-D.edns0-padding] 725 Mayrhofer, A., "The EDNS(0) Padding Option", 726 draft-mayrhofer-edns0-padding-01 (work in progress), 727 August 2015, . 730 [I-D.ipseca] 731 Osterweil, E., Wiley, G., Okubo, T., Lavu, R., and A. 732 Mohaisen, "Opportunistic Encryption with DANE Semantics 733 and IPsec: IPSECA", draft-osterweil-dane-ipsec-03 (work in 734 progress), July 2015, 735 . 738 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 739 RFC2818, May 2000, 740 . 742 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 743 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 744 . 746 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 747 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 748 DOI 10.17487/RFC3646, December 2003, 749 . 751 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 752 Rose, "DNS Security Introduction and Requirements", 753 RFC 4033, DOI 10.17487/RFC4033, March 2005, 754 . 756 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 757 Housley, R., and W. Polk, "Internet X.509 Public Key 758 Infrastructure Certificate and Certificate Revocation List 759 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 760 . 762 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 763 of Named Entities (DANE) Transport Layer Security (TLS) 764 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, 765 August 2012, . 767 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 768 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, 769 May 2014, . 771 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 772 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 773 . 775 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 776 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 777 December 2014, . 779 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 780 DOI 10.17487/RFC7626, August 2015, 781 . 783 [dempsky-dnscurve] 784 Dempsky, M., "DNSCurve", draft-dempsky-dnscurve-01 (work 785 in progress), August 2010, 786 . 788 [dgr-dprive-dtls-and-tls-profiles] 789 Dickinson, S., Gillmor, D., and T. Reddy, 790 "Authentication and (D)TLS Profile for DNS-over-TLS and 791 DNS-over-DTLS", draft-dgr-dprive-dtls-and-tls-profiles-00 792 (work in progress), December 2015, . 796 [dnscrypt-website] 797 Denis, F., "DNSCrypt", December 2015, 798 . 800 [dnssec-trigger] 801 NLnet Labs, "Dnssec-Trigger", May 2014, 802 . 804 [draft-ietf-dprive-dnsodtls] 805 Reddy, T., Wing, D., and P. Patil, "DNS over DTLS 806 (DNSoD)", draft-ietf-dprive-dnsodtls-01 (work in 807 progress), June 2015, . 810 [draft-ietf-tls-falsestart] 811 Moeller, B., Langley, A., and N. Modadugu, "Transport 812 Layer Security (TLS) False Start", 813 draft-ietf-tls-falsestart-01 (work in progress), 814 November 2015, 815 . 817 [tdns] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A., 818 and N. Somaiya, "T-DNS: Connection-Oriented DNS to Improve 819 Privacy and Security", Technical report ISI-TR-688, 820 February 2014, . 823 Appendix A. Out-of-band Key-pinned Privacy Profile Example 825 This section presents an example of how the out-of-band key-pinned 826 privacy profile could work in practice based on a minimal pinset (two 827 pins). 829 A DNS client system is configured with an out-of-band key-pinned 830 privacy profile from a network service, using a pinset containing two 831 pins. Represented in HPKP [RFC7469] style, the pins are: 833 o pin-sha256="FHkyLhvI0n70E47cJlRTamTrnYVcsYdjUGbr79CfAVI=" 835 o pin-sha256="dFSY3wdPU8L0u/8qECuz5wtlSgnorYV2f66L6GNQg6w=" 837 The client also configures the IP addresses of its expected DNS 838 server, 192.0.2.3 and 192.0.2.4. 840 The client connects to 192.0.2.3 on TCP port 853 and begins the TLS 841 handshake, negotiation TLS 1.2 with a diffie-hellman key exchange. 842 The server sends a Certificate message with a list of three 843 certificates (A, B, and C), and signs the ServerKeyExchange message 844 correctly with the public key found certificate A. 846 The client now takes the SHA-256 digest of the SPKI in cert A, and 847 compares it against both pins in the pinset. If either pin matches, 848 the verification is successful; the client continues with the TLS 849 connection and can make its first DNS query. 851 If neither pin matches the SPKI of cert A, the client verifies that 852 cert A is actually issued by cert B. If it is, it takes the SHA-256 853 digest of the SPKI in cert B and compares it against both pins in the 854 pinset. If either pin matches, the verification is successful. 855 Otherwise, it verifes that B was issued by C, and then compares the 856 pins against the digest of C's SPKI. 858 If none of the SPKIs in the cryptographically-valid chain of certs 859 match any pin in the pinset, the client closes the connection with an 860 error, and marks the IP address as failed. 862 Authors' Addresses 864 Zi Hu 865 USC/Information Sciences Institute 866 4676 Admiralty Way, Suite 1133 867 Marina del Rey, CA 90292 868 United States 870 Phone: +1 213 587 1057 871 Email: zihu@usc.edu 873 Liang Zhu 874 USC/Information Sciences Institute 875 4676 Admiralty Way, Suite 1133 876 Marina del Rey, CA 90292 877 United States 879 Phone: +1 310 448 8323 880 Email: liangzhu@usc.edu 882 John Heidemann 883 USC/Information Sciences Institute 884 4676 Admiralty Way, Suite 1001 885 Marina del Rey, CA 90292 886 United States 888 Phone: +1 310 822 1511 889 Email: johnh@isi.edu 891 Allison Mankin 893 Phone: +1 301 728 7198 894 Email: Allison.mankin@gmail.com 895 Duane Wessels 896 Verisign Labs 897 12061 Bluemont Way 898 Reston, VA 20190 899 United States 901 Phone: +1 703 948 3200 902 Email: dwessels@verisign.com 904 Paul Hoffman 905 ICANN 907 Email: paul.hoffman@icann.org