idnits 2.17.1 draft-ietf-dprive-start-tls-for-dns-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2015) is 3211 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) ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5966 (Obsoleted by RFC 7766) == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-5966bis-01 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 3 errors (**), 0 flaws (~~), 2 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: January 6, 2016 USC/Information Sciences 6 Institute 7 A. Mankin 8 D. Wessels 9 Verisign Labs 10 P. Hoffman 11 ICANN 12 July 5, 2015 14 TLS for DNS: Initiation and Performance Considerations 15 draft-ietf-dprive-start-tls-for-dns-01 17 Abstract 19 This document offers an approach to initiating TLS for DNS: use of a 20 dedicated DNS-over-TLS port, and fallback to a mechanism for 21 upgrading a DNS-over-TCP connection over the standard port (TCP/53) 22 to a DNS-over-TLS connection. Encryption provided by TLS eliminates 23 opportunities for eavesdropping on DNS queries in the network, such 24 as discussed in RFC 7258. In addition it specifies two usage 25 profiles for DNS-over-TLS. Finally, it provides advice on 26 performance considerations to minimize overheads from using TCP and 27 TLS with DNS, pertaining to both approaches. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 6, 2016. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Protocol Changes . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Use by DNS Clients . . . . . . . . . . . . . . . . . . . . 5 67 2.1.1. Port-Based DNS-over-TLS for Clients . . . . . . . . . 5 68 2.1.2. Sending Queries for Upgrade-Based DNS-over-TLS . . . . 5 69 2.1.3. Receiving Responses for Upgrade-Based DNS-over-TLS . . 5 70 2.1.4. Use by DNS Servers . . . . . . . . . . . . . . . . . . 6 71 2.1.5. Established Sessions . . . . . . . . . . . . . . . . . 7 72 2.2. Downgrade Attacks and Middleboxes . . . . . . . . . . . . 8 73 3. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . . 9 74 3.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 9 75 3.2. Pre-Deployed Profile . . . . . . . . . . . . . . . . . . . 9 76 4. Performance Considerations . . . . . . . . . . . . . . . . . . 10 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 79 6.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 6.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 6.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 6.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 Today, nearly all DNS queries ([RFC1034] and [RFC1035]) are sent 93 unencrypted, which makes them vulnerable to eavesdropping by an 94 attacker that has access to the network channel, reducing the privacy 95 of the querier. Recent news reports have elevated these concerns, 96 and ongoing efforts are beginning to identify privacy concerns about 97 DNS ([I-D.ietf-dprive-problem-statement]). 99 Prior work has addressed some aspects of DNS security, but until 100 recently there has been little work on privacy between a DNS client 101 and server. DNS Security Extensions (DNSSEC, [RFC4033]) provide 102 _response integrity_ by defining mechanisms to cryptographically sign 103 zones, allowing end-users (or their first-hop resolver) to verify 104 replies are correct. By intention, DNSSEC does not protect request 105 and response privacy. Traditionally, either privacy was not 106 considered a requirement for DNS traffic, or it was assumed that 107 network traffic was sufficiently private, however these perceptions 108 are evolving due to recent events [RFC7258]. 110 DNSCurve [draft-dempsky-dnscurve] defines a method to add 111 confidentiality to the link between DNS clients and servers; however, 112 it does so with a new cryptographic protocol and does not take 113 advantage of an existing standard protocol such as TLS. 114 ConfidentialDNS [draft-wijngaards-confidentialdns] and IPSECA 115 [draft-osterweil-dane-ipsec] use opportunistic encryption to offer 116 privacy for DNS queries and responses. Finally, others have 117 suggested DNS-over-TLS. Unbound DNS software [unbound] includes a 118 DNS-over-TLS implementation. The present document goes beyond past 119 DNS-over-TLS discussions by providing two modes of initiation for 120 DNS-over-TLS: use of a well-known port, and use of a negotiation 121 mechanism in an established connection. 123 Protocol changes proposed here must consider potential interactions 124 with middle boxes. The port-based initiation of TLS is very 125 straightforward, but might be blocked by firewalls or be unwelcome to 126 some DNS client or server implementations. If port-based initiation 127 of TLS fails, the negotiation mechanism allows DNS clients and 128 servers to upgrade an existing DNS-over-TCP connection to a DNS-over- 129 TLS connection, analogous to upgrade mechanisms in other uses of TLS, 130 such as STARTTLS [RFC2595] used in SMTP [RFC3207], IMAP [RFC3501] and 131 POP [RFC1939], to name just a few of many. Adding TLS to DNS-over- 132 TCP avoids port blocking, but maybe interact poorly with middle boxes 133 that inspect DNS traffic. As is generally the case with TLS, both 134 approaches are subject to downgrade attacks, as discussed in 135 Section 2.2. 137 The protocol described here works for any DNS client to server 138 communication using DNS-over-TCP. There can be different profiles 139 providing different levels of privacy, as discussed in Section 3. 140 The protocol may be used for any DNS communication both from stub to 141 recursive, and from recursive to authoritative servers, but different 142 protocols may be preferable for different environments. 144 This document describes two profiles Section 3 providing different 145 levels of assurance of privacy: an opportunistic privacy profile and 146 a pre-deployed profile. 148 1.1. Reserved Words 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 2. Protocol Changes 156 The only changes required for port-based DNS-over-TLS are those 157 optimizing TCP and TLS performance discussed in the following. The 158 DNS protocol itself is unchanged. 160 DISCUSSION: Draft authors seek input from the working group regarding 161 the need for both port- and upgrade-based approaches. Removing the 162 upgrade-based technique would simplify this document and 163 implementations. However, there may perhaps be situations where the 164 upgrade-based technique works (over port 53) that a port-based 165 technique would not work (i.e., due to aggressive port blocking by 166 firewalls). 168 Clients and servers negotiate upgrade-based DNS-over-TLS by setting a 169 bit in the Flags field of the EDNS0 [RFC6891] OPT meta-RR. The "TLS 170 OK" (TO) bit is defined as the second bit of the third and fourth 171 bytes of the "extended RCODE and flags" portion of the EDNS0 OPT 172 meta-RR, immediately adjacent to the "DNSSEC OK" (DO) bit [RFC4033]: 174 +0 (MSB) +1 (LSB) 175 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 176 0: | EXTENDED-RCODE | VERSION | 177 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 178 2: |DO|TO| Z | 179 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 181 2.1. Use by DNS Clients 183 DNS clients first try port-based DNS-over-TLS. If that connection 184 fails, they try upgrade-based DNS-over-TLS. 186 2.1.1. Port-Based DNS-over-TLS for Clients 188 DNS clients SHOULD first try using port-based DNS-over-TLS by 189 establishing the TCP connection to the dedicated port TBD (number to 190 be defined in Section 5). Clients MAY try STARTTLS upgrade before 191 the dedicated port if there is information that this ordering is 192 preferred. It SHOULD be an implementation and/or local determination 193 as to whether to attempt TLS via the dedicated port first and then 194 fall back to STARTTLS use, or to choose some other order of attempts 195 and fallbacks. 197 2.1.2. Sending Queries for Upgrade-Based DNS-over-TLS 199 Setting the TO bit in queries sent using UDP transport has no 200 protocol meaning. However, the client MAY set the TO bit when using 201 UDP transport. The server MUST ignore the TO bit when receiving UDP 202 transport. 204 DNS clients set the TO bit in the initial query sent to a server 205 using TCP transport to signal their desire that the TCP connection be 206 upgraded to TLS. DNS clients SHOULD NOT set the TO bit on queries 207 when using TLS transport because doing so has no meaning in this 208 protocol. 210 Since the motivation for upgrade-based DNS-over-TLS is to preserve 211 privacy, DNS clients SHOULD use an initial (unprotected) query that 212 reveals no private information in the initial TO=1 query to a server. 213 To provide a standard "dummy" query, it is RECOMMENDED to send the 214 initial query with RD=0, QNAME="STARTTLS", QCLASS=CH, and QTYPE=TXT 215 ("STARTTLS/CH/TXT") analogous to administrative queries already in 216 widespread use [RFC4892]. (For some profiles, the client MUST use a 217 dummy query for the initial query.) 219 After sending the initial TO=1 query using TCP transport, DNS clients 220 MUST wait for the initial response before sending any subsequent 221 queries over the same TCP connection. 223 2.1.3. Receiving Responses for Upgrade-Based DNS-over-TLS 225 A DNS client that receives a response using UDP transport that has 226 the TO bit set handles that response as usual. It MAY record the 227 server's support for DNS-over-TLS and use that information as part of 228 its server selection algorithm in the case where multiple servers are 229 available to service a particular query. 231 A DNS client that receives a response to its initial query using TCP 232 transport that has the TO bit clear MUST NOT initiate a TLS handshake 233 and MAY utilize the existing TCP connection for subsequent 234 (unencrypted) queries. DNS clients SHOULD remember server IP 235 addresses that don't support upgrade-based DNS-over-TLS, including 236 TLS handshake failures, and not request DNS-over-TLS from them for a 237 reasonable period (such as one hour per server). 239 A DNS client that has sent the TO bit using TCP transport and 240 receives a response to its initial query that has the TO bit set MUST 241 immediately initiate a TLS handshake using the procedure described in 242 [RFC5246]. If the TLS handshake does not succeed, the client MUST 243 close the connection and treat the server as described above for 244 future queries. 246 2.1.4. Use by DNS Servers 248 A DNS server that supports DNS-over-TLS SHOULD support port-based 249 DNS-over-TLS, and SHOULD support upgrade-based DNS-over-TLS. 251 2.1.4.1. Receiving Queries for Upgrade-Based DNS-over-TLS 253 A DNS server receiving a query over UDP with the TO bit ignores that 254 bit. A DNS server receiving a query over an existing TLS connection 255 with the TO bit ignores that bit. 257 A DNS server receiving an initial query over TCP that has the TO bit 258 set MAY inform the client it is willing to establish a TLS session, 259 as described in the next section. 261 A DNS server receiving subsequent queries over TCP MUST ignore the TO 262 bit. (A client wishing to start TLS after the initial query MUST 263 open a new TCP connection to do so.) 265 2.1.4.2. Sending Responses 267 A DNS server sending a response over UDP to a query that had an OPT 268 meta-RR SHOULD set the TO bit to indicate its general support for 269 DNS-over-TLS, as long as it is willing and able to support a TLS 270 connection with the particular client. 272 A DNS server receiving an initial query over TCP that has the TO bit 273 set MAY set the TO bit in its response. The server MUST then proceed 274 with the TLS handshake protocol. 276 A DNS server receiving a "dummy" STARTTLS/CH/TXT query over TCP MUST 277 respond with RCODE=0 and a TXT RR in the Answer section. Contents of 278 the TXT RR are strictly informative (for humans) and MUST NOT be 279 interpreted by the client software. Recommended TXT RDATA values are 280 "STARTTLS" or "NO_TLS". 282 2.1.5. Established Sessions 284 After TLS negotiation completes, the connection will be encrypted and 285 is now protected from eavesdropping and normal DNS queries SHOULD 286 take place, following DNS-over-TCP framing ([RFC1035], section 287 4.2.2). For reasons of efficiency, DNS clients and servers SHOULD 288 transmit the two-octet length field, and the message described by 289 that length field, in a single TCP segment ([I-D.ietf-dnsop-5966bis], 290 section 8). 292 For DNS clients that use library functions such as "gethostbyname()", 293 current implementations are known to open and close UDP connections 294 each DNS call. To avoid many TCP connections, each with a single 295 query, clients SHOULD reuse a single TCP connection to the recursive 296 resolver. Alternatively they may prefer to use UDP to a DNS-over-TLS 297 enabled caching resolver on the same machine that then uses a system- 298 wide TCP connection to the recursive resolver. 300 In order to amortize TCP and TLS connetion setup costs, clients and 301 servers SHOULD NOT immediately close a connection after each 302 response. Instead, clients and servers SHOULD reuse existing 303 connections for subsequent queries as long as they have sufficient 304 resources. In some cases, this means that clients and servers may 305 need to keep idle connections open for some amount of time. 307 Proper management of established and idle connections is important to 308 the healthy operation of a DNS server. An implementor of DNS-over- 309 TLS SHOULD follow best practices for DNS-over-TCP, as described in 310 [I-D.ietf-dnsop-5966bis]. Failure to do so may lead to resource 311 exhaustion and denial-of-service. 313 Whereas client and server implementations from the [RFC1035] era are 314 known to have poor TCP connection management, this document 315 stipulates that successful negotation of TLS indicates the 316 willingness of both parties to keep idle DNS connections open, 317 independent of timeouts or other recommendations for DNS-over-TCP 318 without TLS. In other words, software implemeting this protocol is 319 assumed to support idle, persistent connections and to have good 320 connection management. 322 This document does not make specific recommendations for timeout 323 values on idle connections. Clients and servers should reuse and/or 324 close connections depending on the level of available resources. 326 Timeouts may be longer during periods of low activity and shorter 327 during periods of high activity. Current work in this area may also 328 assist DNS-over-TLS clients and servers select useful timeout values 329 [draft-wouters-edns-tcp-keepalive] [tdns]. 331 Clients and servers that keep idle connections open MUST be robust to 332 termination of idle connection by either party. As with current DNS- 333 over-TCP, DNS servers MAY close the connection at any time (e.g., due 334 to resource constraints). As with current DNS-over-TCP, clients MUST 335 handle abrupt closes and be prepared to reestablish connections 336 and/or retry queries. 338 When closing a connection, DNS servers SHOULD use the TLS close- 339 notify request to shift TCP TIME-WAIT state to the clients. 340 Additional requirements and guidance for optimizing DNS-over-TCP are 341 provided by [RFC5966], [I-D.ietf-dnsop-5966bis]. As discussed in 342 [I-D.ietf-dnsop-5966bis], TCP Fast Open [RFC7413] is of benefit. 344 2.2. Downgrade Attacks and Middleboxes 346 Middleboxes [RFC3234] may be present in some networks and have been 347 known to interfere with normal DNS resolution and create problems for 348 DNS-over-TLS. Remarkably, downgrade attacks can affect plaintext 349 protocols that utilize "STARTTLS" signaling in a similar way. A DNS 350 client attempting upgrade-based DNS-over-TLS through a middlebox, or 351 in the presence of a downgrade attack, could have one of the 352 following outcomes. (These outcomes are similar to those discussed 353 in prior RFCs, such as [RFC3207].) 355 o The DNS client sends a TO=1 query and receives a TO=0 response. 356 In this case there is no upgrade to TLS and DNS resolution occurs 357 normally, without encryption. 359 o The DNS client sends a TO=1 query and receives a TO=1 response, 360 but the middlebox does not understand the TLS negotiation and does 361 not allow the TLS handshake packets to pass. Clients SHOULD retry 362 DNS without TO set if negotiation fails, and then retry with TLS 363 after a reasonable period (see Section 2.1.3). 365 o The DNS client sends a TO=1 query but receives no response at all. 366 The middlebox might be silently dropping the query due to the 367 presence of the TO bit, when it should, in fact, ignore and pass 368 through unknown flag bits [RFC6891]. The client SHOULD fall back 369 to normal (unencrypted) DNS for a reasonable period (as discussed 370 in Section 2.1.3). 372 In general, clients that attempt TLS and fail can either fall back on 373 unencrypted DNS, or wait and retry later, depending on their privacy 374 requirements. 376 3. Usage Profiles 378 This protocol provides flexibility to accommodate several different 379 use cases. Two usage profiles are defined here to identify specific 380 design points in performance and privacy. Other profiles are 381 possible but are outside the scope of this document. 383 3.1. Opportunistic Privacy Profile 385 For opportunistic privacy, analogous to SMTP opportunistic encryption 386 [RFC7435] one desires privacy when possible, but does not require it. 388 With opportunistic privacy, a client might acquire a recursive DNS 389 resolver from an untrusted source (such as DHCP while roaming), it 390 might or might not validate the TLS certificate, and it might not use 391 a dummy value for the initial query. These choices maximize 392 availability and performance, but they are vulnerable to on-path 393 attacks. 395 Opportunistic privacy can be used by any current client, but it only 396 provides privacy when there are no on-path active attackers. 398 3.2. Pre-Deployed Profile 400 For pre-deployed privacy, the DNS client has one or more trusted 401 recursive DNS providers. This profile provides strong privacy 402 guarantees to the user. 404 With pre-deployed privacy, a client retains a copy of the TLS 405 certificate (and/or other authentication credentials as appropriate) 406 and IP address of each provider. The client will only use one of 407 those DNS providers. Because it has a pre-deployed TLS certificate, 408 it may detect person-in-the-middle and downgrade attacks. 410 With pre-deployed privacy, the DNS client MUST signal to the user 411 when none of the designated DNS servers are available, and MUST NOT 412 provide DNS service until one of the designated DNS servers becomes 413 available. 415 The designated DNS provider may be temporarily unavailable when 416 configuring a network. For example, for clients on networks that 417 require authentication through web-based login, such authentication 418 may require DNS interception and spoofing. Techniques such as those 419 used by DNSSEC-trigger [dnssec-trigger] MAY be used during network 420 configuration, with the intent to transition to the designated DNS 421 provider after authentication. The user MUST be alerted that the DNS 422 is not private during such bootstrap. 424 Methods for pre-deployment of the designated DNS provider are outside 425 the scope of this document. In corporate settings, such information 426 may be provided at system installation. Use of multiple public DNS 427 providers suggests that end users are able to configure DNS by hand. 429 4. Performance Considerations 431 DNS-over-TLS incurs additional latency at session startup. It also 432 requires additional state (memory) and increased processing (CPU). 434 1. Latency: Compared to UDP, DNS-over-TCP requires an additional 435 round-trip-time (RTT) of latency to establish the connection. 436 The TLS handshake adds another two RTTs of latency. Clients and 437 servers should support connection keepalive (reuse) and out-of- 438 order processing to amortize connection setup costs. Moreover, 439 TLS connection resumption can further reduce the setup delay. 440 DNS servers SHOULD enable fast TLS session resumption [RFC5077] 441 to avoid keeping per-client session state. TLS False Start 442 [draft-tls-falsestart] can also lead to a latency reduction in 443 certain situations. 445 2. State: The use of connection-oriented TCP requires keeping 446 additional state in both kernels and applications. TLS has 447 marginal increases in state over TCP alone. The state 448 requirements are of particular concerns on servers with many 449 clients. Smaller timeout values will reduce the number of 450 concurrent connections, and servers can preemptively close 451 connections when resources limits are exceeded. 453 3. Processing: Use of TLS encryption algorithms results in slightly 454 higher CPU usage. Servers can choose to refuse new DNS-over-TCP 455 clients if processing limits are exceeded. 457 4. Number of connections: To minimize state on DNS servers and 458 connection startup time, clients SHOULD minimize creation of new 459 TCP connections. Use of a local DNS request aggregator (a 460 particular type of forwarder) allows a single active DNS-over-TLS 461 connection from any given client computer to its server. 462 Additional guidance can be found in [I-D.ietf-dnsop-5966bis]. 464 A full performance evaluation is outside the scope of this 465 specification. A more detailed analysis of the performance 466 implications of DNS-over-TLS (and DNS-over-TCP) is discussed in a 467 technical report [tdns] and [I-D.ietf-dnsop-5966bis]. 469 5. IANA Considerations 471 This document defines a new bit ("TO") in the Flags field of the 472 EDNS0 OPT meta-RR. At the time of approval of this draft in the 473 standards track, as per the IANA Considerations of RFC 6891, IANA is 474 requested to reserve the second leftmost bit of the flags as the TO 475 bit, immediately adjacent to the DNSSEC DO bit, as shown in 476 Section 2. 478 IANA is requested add the following value to the "Service Name and 479 Transport Protocol Port Number Registry" registry. That registry is 480 populated by expert review [RFC6335], and such a review will be 481 requested if this document progresses. 483 Service Name DNS-over-TLS 484 Transport Protocol(s) TCP 485 Assignee IESG 486 Contact TBD 487 Description DNS query-response protocol run over TLS 488 Reference This document 490 6. Implementation Status 492 [Note to RFC Editor: please remove this section and reference to RFC 493 6982 prior to publication.] 495 This section records the status of known implementations of the 496 protocol defined by this specification at the time of posting of this 497 Internet-Draft, and is based on a proposal described in RFC 6982. 498 The description of implementations in this section is intended to 499 assist the IETF in its decision processes in progressing drafts to 500 RFCs. Please note that the listing of any individual implementation 501 here does not imply endorsement by the IETF. Furthermore, no effort 502 has been spent to verify the information presented here that was 503 supplied by IETF contributors. This is not intended as, and must not 504 be construed to be, a catalog of available implementations or their 505 features. Readers are advised to note that other implementations may 506 exist. 508 According to RFC 6982, "this will allow reviewers and working groups 509 to assign due consideration to documents that have the benefit of 510 running code, which may serve as evidence of valuable experimentation 511 and feedback that have made the implemented protocols more mature. 512 It is up to the individual working groups to use this information as 513 they see fit". 515 6.1. Unbound 517 The Unbound recursive name server software added support for port- 518 based DNS-over-TLS in version 1.4.14. The unbound.conf configuration 519 file has the following configuration directives: ssl-port, ssl- 520 service-key, ssl-service-pem, ssl-upstream. See 521 https://unbound.net/documentation/unbound.conf.html. 523 Sinodun Internet Technologies has implemented upgrade-based DNS-over- 524 TLS in Unbound-1.5.1 (patch available at https://portal.sinodun.com/ 525 stash/projects/TDNS/repos/dns-over-tls_patches/browse) for both stub- 526 to-recursive and recursive-to-authoritative. 528 6.2. ldns 530 Sinodun Internet Technologies has implemented both upgrade-based and 531 port-based DNS-over-TLS in the ldns library from NLnetLabs. This 532 also gives DNS-over-TLS support to the drill DNS client program. 533 Patches available at https://portal.sinodun.com/stash/projects/TDNS/ 534 repos/dns-over-tls_patches/browse. 536 6.3. digit 538 The digit DNS client from USC/ISI supports both port- and upgrade- 539 based DNS-over-TLS. Source code available at 540 http://www.isi.edu/ant/software/tdns/index.html. 542 6.4. getdns 544 The getdns API implementation supports both port- and upgrade-based 545 DNS-over-TLS. Upgrade-based operation requires linking getdns with a 546 patched version of libunbound. Source code available at 547 https://getdnsapi.net. 549 7. Security Considerations 551 Use of TLS for DNS addresses is designed to address the privacy risks 552 arise because DNS queries may be eavesdropped upon. It does not 553 address other security issues in DNS, and there are a number of 554 residual risks that may affect its success at protecting privacy: 556 1. There are known attacks on TLS, such as person-in-the-middle and 557 protocol downgrade. These are general attacks on TLS and not 558 specific to DNS-over-TLS; please refer to the TLS RFCs for 559 discussion of these security issues. 561 2. Any protocol interactions prior to the TLS handshake are 562 performed in the clear and can be modified by a man-in-the-middle 563 attacker. For this reason, clients MAY discard cached 564 information about server capabilities advertised prior to the 565 start of the TLS handshake. 567 3. As with other uses of STARTTLS-upgrade to TLS, the mechanism 568 specified here is susceptible to downgrade attacks, where a 569 person-in-the-middle prevents a successful TLS upgrade. Keeping 570 track of servers known to support TLS (i.e., "pinning") enables 571 clients to detect downgrade attacks. For servers with no 572 connection history, clients may choose to refuse non-TLS DNS, or 573 they may continue without TLS, depending on their privacy 574 requirements. 576 4. This document does not propose new ideas to provide resistance to 577 known traffic analysis techniques. Even with encrypted messages, 578 a well-positioned party may be able to glean certain details from 579 an analysis of message timings and sizes. 581 5. This document does not propose new ideas for certificate 582 authentication for TLS in the context of DNS. Several external 583 methods are possible, although each has weaknesses. The current 584 Certificate Authority infrastructure [RFC5280] is used by HTTP/ 585 TLS [RFC2818]. With many trusted CAs, this approach has 586 recognized weaknesses [CA_Compromise]. Some work is underway to 587 partially address these concerns (for example, with certificate 588 pinning [certificate_pinning], but more work is needed. DANE 589 [RFC6698] provides mechanisms to root certificate trust with 590 DNSSEC. That use here must be carefully evaluated to address 591 potential issues in trust recursion. For stub-to-recursive 592 resolver use, certificate authentication is sometimes either easy 593 or nearly impossible. If the recursive resolver is manually 594 configured, its certificate can be authenticated when it is 595 configured. If the recursive resolver is automatically 596 configured (such as with DHCP [RFC2131]), it could use DHCP 597 authentication mechanisms [RFC3118]). 599 Ongoing discussion and development of opportunistic TLS (connections 600 without CA validation, [RFC7435]) may be relevant to DNS-over-TLS. 602 8. Acknowledgments 604 The authors would like to thank Stephane Bortzmeyer, Brian Haberman, 605 Kim-Minh Kaplan, Bill Manning, George Michaelson, Eric Osterweil, 606 Glen Wiley, John Dickinson, Sara Dickinson, and Daniel Kahn Gillmor 607 for reviewing this Internet-draft, and Nikita Somaiya for early work 608 on this idea. 610 Work by Zi Hu, Liang Zhu, and John Heidemann in this paper is 611 partially sponsored by the U.S. Dept. of Homeland Security (DHS) 612 Science and Technology Directorate, HSARPA, Cyber Security Division, 613 BAA 11-01-RIKA and Air Force Research Laboratory, Information 614 Directorate under agreement number FA8750-12-2-0344, and contract 615 number D08PC75599. 617 9. References 619 9.1. Normative References 621 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 622 STD 13, RFC 1034, November 1987. 624 [RFC1035] Mockapetris, P., "Domain names - implementation and 625 specification", STD 13, RFC 1035, November 1987. 627 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 628 Requirement Levels", BCP 14, RFC 2119, March 1997. 630 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 631 "Transport Layer Security (TLS) Session Resumption without 632 Server-Side State", RFC 5077, January 2008. 634 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 635 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 637 [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation 638 Requirements", RFC 5966, August 2010. 640 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 641 Cheshire, "Internet Assigned Numbers Authority (IANA) 642 Procedures for the Management of the Service Name and 643 Transport Protocol Port Number Registry", BCP 165, 644 RFC 6335, August 2011. 646 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 647 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 649 9.2. Informative References 651 [CA_Compromise] 652 Infosec Island Admin, "CA Compromise", January 2012, . 657 [I-D.ietf-dnsop-5966bis] 658 Dickinson, J., Bellis, R., Mankin, A., and D. Wessels, 659 "DNS Transport over TCP - Implementation Requirements", 660 draft-ietf-dnsop-5966bis-01 (work in progress), 661 December 2014. 663 [I-D.ietf-dprive-problem-statement] 664 Bortzmeyer, S., "DNS privacy considerations", 665 draft-ietf-dprive-problem-statement-06 (work in progress), 666 October 2014. 668 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 669 STD 53, RFC 1939, May 1996. 671 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 672 RFC 2131, March 1997. 674 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 675 RFC 2595, June 1999. 677 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 679 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 680 Messages", RFC 3118, June 2001. 682 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 683 Transport Layer Security", RFC 3207, February 2002. 685 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 686 Issues", RFC 3234, February 2002. 688 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 689 4rev1", RFC 3501, March 2003. 691 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 692 Rose, "DNS Security Introduction and Requirements", 693 RFC 4033, March 2005. 695 [RFC4892] Woolf, S. and D. Conrad, "Requirements for a Mechanism 696 Identifying a Name Server Instance", RFC 4892, June 2007. 698 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 699 Housley, R., and W. Polk, "Internet X.509 Public Key 700 Infrastructure Certificate and Certificate Revocation List 701 (CRL) Profile", RFC 5280, May 2008. 703 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 704 of Named Entities (DANE) Transport Layer Security (TLS) 705 Protocol: TLSA", RFC 6698, August 2012. 707 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 708 Attack", BCP 188, RFC 7258, May 2014. 710 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 711 Fast Open", RFC 7413, December 2014. 713 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 714 Most of the Time", RFC 7435, December 2014. 716 [certificate_pinning] 717 OWASP, "Certificate and Public Key Pinning", 2014, . 721 [dnssec-trigger] 722 NLnet Labs, "Dnssec-Trigger", May 2014, 723 . 725 [draft-dempsky-dnscurve] 726 Dempsky, M., "DNSCurve", draft-dempsky-dnscurve-01 (work 727 in progress), August 2010, 728 . 730 [draft-osterweil-dane-ipsec] 731 Osterweil, E., Wiley, G., Mitchell, D., and A. Newton, 732 "Opportunistic Encryption with DANE Semantics and IPsec: 733 IPSECA", draft-osterweil-dane-ipsec-00 (work in progress), 734 February 2014, 735 . 738 [draft-tls-falsestart] 739 Moeller, B. and A. Langley, "Transport Layer Security 740 (TLS) False Start", draft-bmoeller-tls-falsestart-01 (work 741 in progress), November 2014, . 744 [draft-wijngaards-confidentialdns] 745 Wijngaards, W., "Confidential DNS", 746 draft-wijngaards-dnsop-confidentialdns-03 (work in 747 progress), November 2013, . 750 [draft-wouters-edns-tcp-keepalive] 751 Wouters, P. and J. Abley, "The edns-tcp-keepalive EDNS0 752 Option", draft-wouters-edns-tcp-keepalive-00 (work in 753 progress), October 2013, . 756 [tdns] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A., 757 and N. Somaiya, "T-DNS: Connection-Oriented DNS to Improve 758 Privacy and Security", Technical report ISI-TR-688, 759 February 2014, . 762 [unbound] NLnet Labs, Verisign labs, "Unbound", December 2013, 763 . 765 Authors' Addresses 767 Zi Hu 768 USC/Information Sciences Institute 769 4676 Admiralty Way, Suite 1133 770 Marina del Rey, CA 90292 771 USA 773 Phone: +1 213 587-1057 774 Email: zihu@usc.edu 776 Liang Zhu 777 USC/Information Sciences Institute 778 4676 Admiralty Way, Suite 1133 779 Marina del Rey, CA 90292 780 USA 782 Phone: +1 310 448-8323 783 Email: liangzhu@usc.edu 785 John Heidemann 786 USC/Information Sciences Institute 787 4676 Admiralty Way, Suite 1001 788 Marina del Rey, CA 90292 789 USA 791 Phone: +1 310 822-1511 792 Email: johnh@isi.edu 793 Allison Mankin 794 Verisign Labs 795 12061 Bluemont Way 796 Reston, VA 20190 798 Phone: +1 703 948-3200 799 Email: amankin@verisign.com 801 Duane Wessels 802 Verisign Labs 803 12061 Bluemont Way 804 Reston, VA 20190 806 Phone: +1 703 948-3200 807 Email: dwessels@verisign.com 809 Paul Hoffman 810 ICANN 812 Email: paul.hoffman@icann.org