idnits 2.17.1 draft-ietf-dprive-start-tls-for-dns-00.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A DNS client that receives a response to its initial query using TCP transport that has the TO bit clear MUST not initiate a TLS handshake and SHOULD utilize the existing TCP connection for subsequent queries. DNS clients SHOULD remember server IP addresses that don't support upgrade-based DNS-over-TLS, including TLS handshake failures, and not request DNS-over-TLS from them for reasonable period (such as one hour per server). -- The document date (May 5, 2015) is 3272 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-00 == Outdated reference: A later version (-06) exists of draft-ietf-dprive-problem-statement-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 (~~), 4 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: November 6, 2015 USC/Information Sciences 6 Institute 7 A. Mankin 8 D. Wessels 9 Verisign Labs 10 P. Hoffman 11 VPN Consortium 12 May 5, 2015 14 TLS for DNS: Initiation and Performance Considerations 15 draft-ietf-dprive-start-tls-for-dns-00 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 November 6, 2015. 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 1. Introduction 63 Today, nearly all DNS queries ([RFC1034] and [RFC1035]) are sent 64 unencrypted, which makes them vulnerable to eavesdropping by an 65 attacker that has access to the network channel, reducing the privacy 66 of the querier. Recent news reports have elevated these concerns, 67 and ongoing efforts are beginning to identify privacy concerns about 68 DNS ([I-D.ietf-dprive-problem-statement]). 70 Prior work has addressed some aspects of DNS security, but until 71 recently there has been little work on privacy between a DNS client 72 and server. DNS Security Extensions (DNSSEC, [RFC4033]) provide 73 _response integrity_ by defining mechanisms to cryptographically sign 74 zones, allowing end-users (or their first-hop resolver) to verify 75 replies are correct. By intention, DNSSEC does not protect request 76 and response privacy. Traditionally, either privacy was not 77 considered a requirement for DNS traffic, or it was assumed that 78 network traffic was sufficiently private, however these perceptions 79 are evolving due to recent events [RFC7258]. 81 DNSCurve [draft-dempsky-dnscurve] defines a method to add 82 confidentiality to the link between DNS clients and servers; however, 83 it does so with a new cryptographic protocol and does not take 84 advantage of an existing standard protocol such as TLS. 85 ConfidentialDNS [draft-wijngaards-confidentialdns] and IPSECA 86 [draft-osterweil-dane-ipsec] use opportunistic encryption to offer 87 privacy for DNS queries and responses. Finally, others have 88 suggested DNS-over-TLS. Unbound DNS software [unbound] includes a 89 DNS-over-TLS implementation. The present document goes beyond past 90 DNS-over-TLS discussions by providing two modes of initiation for 91 DNS-over-TLS: use of a well-known port, and use of a negotiation 92 mechanism in an established connection. 94 Protocol changes proposed here must consider potential interactions 95 with middle boxes. The port-based initiation of TLS is very 96 straightforward, but might be blocked by firewalls or be unwelcome to 97 some DNS client or server implementations. If port-based initiation 98 of TLS fails, the negotiation mechanism allows DNS clients and 99 servers to upgrade an existing DNS-over-TCP connection to a DNS-over- 100 TLS connection, analogous to upgrade mechanisms in other uses of TLS, 101 such as STARTTLS [RFC2595] used in SMTP [RFC3207], IMAP [RFC3501] and 102 POP [RFC1939], to name just a few of many. Adding TLS to DNS-over- 103 TCP avoids port blocking, but maybe interact poorly with middle boxes 104 that inspect DNS traffic. As is generally the case with TLS, both 105 approaches are subject to downgrade attacks, as discussed in 106 Section 2.2. 108 The protocol described here works for any DNS client to server 109 communication using DNS-over-TCP. There can be different profiles 110 providing different levels of privacy, as discussed in Section 3. 111 The protocol may be used for any DNS communication both from stub to 112 recursive, and from recursive to authoritative servers, but different 113 protocols may be preferable for different environments. 115 This document describes two profiles Section 3 providing different 116 levels of assurance of privacy: an opportunistic privacy profile and 117 a pre-deployed profile. 119 1.1. Reserved Words 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 2. Protocol Changes 127 The only changes required for port-based DNS-over-TLS are those 128 optimizing TCP and TLS performance discussed in the following. The 129 DNS protocol itself is unchanged. 131 Clients and servers negotiate upgrade-based DNS-over-TLS by setting a 132 bit in the Flags field of the EDNS0 [RFC6891] OPT meta-RR. The "TLS 133 OK" (TO) bit is defined as the second bit of the third and fourth 134 bytes of the "extended RCODE and flags" portion of the EDNS0 OPT 135 meta-RR, immediately adjacent to the "DNSSEC OK" (DO) bit [RFC4033]: 137 +0 (MSB) +1 (LSB) 138 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 139 0: | EXTENDED-RCODE | VERSION | 140 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 141 2: |DO|TO| Z | 142 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 144 2.1. Use by DNS Clients 146 DNS clients first try port-based DNS-over-TLS. If that connection 147 fails, they try upgrade-based DNS-over-TLS. 149 2.1.1. Port-Based DNS-over-TLS for Clients 151 DNS clients SHOULD first try using port-based DNS-over-TLS by 152 establishing the TCP connection to the dedicated port TBD (number to 153 be defined in Section 5). Clients MAY try STARTTLS upgrade before 154 the dedicated port if there is information that this ordering is 155 preferred. It SHOULD be an implementation and/or local determination 156 as to whether to attempt TLS via the dedicated port first and then 157 fall back to STARTTLS use, or to choose some other order of attempts 158 and fallbacks. 160 2.1.2. Sending Queries for Upgrade-Based DNS-over-TLS 162 Setting the TO bit in queries sent using UDP transport has no 163 protocol meaning. However, the client MAY set the TO bit when using 164 UDP transport. The server MUST ignore the TO bit when receiving UDP 165 transport. 167 DISCUSSION: community advice is sought on this. The advantage of 168 allowing a client to send UDP on TO is that servers can collect 169 information on deployment (as happened with the DO bit). The 170 disadvantage is that a meaningless bit (TO over UDP) might cause 171 confusion, and some middleboxes might not pass a UDP query with the 172 TO bit set. 174 DNS clients set the TO bit in the initial query sent to a server 175 using TCP transport to signal their desire that the TCP connection be 176 upgraded to TLS. DNS clients SHOULD NOT set the TO bit on queries 177 when using TLS transport because doing so has no meaning in this 178 protocol. 180 Since the motivation for upgrade-based DNS-over-TLS is to preserve 181 privacy, DNS clients SHOULD use an initial (unprotected) query that 182 reveals no private information in the initial TO=1 query to a server. 183 To provide a standard "dummy" query, it is RECOMMENDED to send the 184 initial query with RD=0, QNAME="STARTTLS", QCLASS=CH, and QTYPE=TXT 185 ("STARTTLS/CH/TXT") analogous to administrative queries already in 186 widespread use [RFC4892]. (For some profiles, the client MUST use a 187 dummy query for the initial query.) 189 After sending the initial TO=1 query using TCP transport, DNS clients 190 MUST wait for the initial response before sending any subsequent 191 queries over the same TCP connection. 193 2.1.3. Receiving Responses for Upgrade-Based DNS-over-TLS 195 A DNS client that receives a response using UDP transport that has 196 the TO bit set handles that response as usual. It MAY record the 197 server's support for DNS-over-TLS and use that information as part of 198 its server selection algorithm in the case where multiple servers are 199 available to service a particular query. 201 A DNS client that has sent the TO bit using TCP transport and 202 receives a response to its initial query that has the TO bit set MUST 203 immediately initiate a TLS handshake using the procedure described in 204 [RFC5246]. (Note that this document does not yet deal with what 205 happens when the TLS handshake does not succeed.) 207 DISCUSSION: are there any cases in which a DNS client that sent TO on 208 DNS-over-TCP and receives TO in the initial response from the server 209 would not initiate the TLS handshake? Is there any reason for this 210 to be SHOULD rather than MUST? 212 A DNS client that receives a response to its initial query using TCP 213 transport that has the TO bit clear MUST not initiate a TLS handshake 214 and SHOULD utilize the existing TCP connection for subsequent 215 queries. DNS clients SHOULD remember server IP addresses that don't 216 support upgrade-based DNS-over-TLS, including TLS handshake failures, 217 and not request DNS-over-TLS from them for reasonable period (such as 218 one hour per server). 220 2.1.4. Use by DNS Servers 222 A DNS server that supports DNS-over-TLS SHOULD support port-based 223 DNS-over-TLS, and SHOULD support upgrade-based DNS-over-TLS. 225 2.1.4.1. Receiving Queries for Upgrade-Based DNS-over-TLS 227 A DNS server receiving a query over UDP with the TO bit ignores that 228 bit. A DNS server receiving a query over an existing TLS connection 229 with the TO bit ignores that bit. 231 A DNS server receiving an initial query over TCP that has the TO bit 232 set MAY inform the client it is willing to establish a TLS session, 233 as described in the next section. 235 A DNS server receiving subsequent queries over TCP MUST ignore the TO 236 bit. (A client wishing to start TLS after the initial query MUST 237 open a new TCP connection to do so.) 239 2.1.4.2. Sending Responses 241 A DNS server sending a response over UDP to a query that had an OPT 242 meta-RR SHOULD set the TO bit to indicate its general support for 243 DNS-over-TLS, as long as it is willing and able to support a TLS 244 connection with the particular client. 246 A DNS server receiving an initial query over TCP that has the TO bit 247 set MAY set the TO bit in its response. The server MUST then proceed 248 with the TLS handshake protocol. 250 A DNS server receiving a "dummy" STARTTLS/CH/TXT query over TCP MUST 251 respond with RCODE=0 and a TXT RR in the Answer section. Contents of 252 the TXT RR are strictly informative (for humans) and MUST NOT be 253 interpreted by the client software. Recommended TXT RDATA values are 254 "STARTTLS" or "NO_TLS". 256 2.1.5. Established Sessions 258 After TLS negotiation completes, the connection will be encrypted and 259 is now protected from eavesdropping and normal DNS queries SHOULD 260 take place, following DNS-over-TCP framing ([RFC1035], section 261 4.2.2). 263 It is expected that multiple DNS queries will be made over the same 264 TLS connection instead of tearing down the TLS connection after each 265 response. A user of DNS-over-TLS SHOULD follow best practices for 266 DNS-over-TCP, as described in [I-D.ietf-dnsop-5966bis]. (For DNS 267 clients that use library functions such as "gethostbyname()", current 268 clients may open and close UDP connections each DNS call. We 269 recommend they reuse a single TCP connection to the recursive 270 resolver or use UDP to a caching resolver that uses a system-wide TCP 271 connection to the recursive resolver.) 273 Both clients and servers SHOULD follow existing DNS-over-TCP timeout 274 rules, which are often implementation- and situation-dependent. In 275 the absence of any other advice, the RECOMMENDED timeout values are 276 30 seconds for recursive name servers, 60 seconds for clients of 277 recursive name servers, 10 seconds for authoritative name servers, 278 and 20 seconds for clients of authoritative name servers. Current 279 work in this area may assist DNS-over-TLS clients and servers select 280 useful timeout values [draft-wouters-edns-tcp-keepalive] [tdns]. 282 As with current DNS-over-TCP, DNS servers MAY close the connection at 283 any time (e.g., due to resource constraints). As with current DNS- 284 over-TCP, clients MUST handle abrupt closes and be prepared to 285 reestablish connections and/or retry queries. DNS servers SHOULD use 286 the TLS close-notify request to shift TCP TIME-WAIT state to the 287 clients. Additional requirements and guidance for optimizing DNS- 288 over-TCP are provided by [RFC5966], [I-D.ietf-dnsop-5966bis]. As 289 discussed in [I-D.ietf-dnsop-5966bis], TCP Fast Open [RFC7413] is of 290 benefit. 292 DNS servers SHOULD enable fast TLS session resumption [RFC5077] to 293 avoid keeping per-client session state. 295 2.2. Downgrade Attacks and Middleboxes 297 Middleboxes [RFC3234] may be present in some networks and have been 298 known to interfere with normal DNS resolution and create problems for 299 DNS-over-TLS. Remarkably, downgrade attacks can affect plaintext 300 protocols that utilize "STARTTLS" signaling in a similar way. A DNS 301 client attempting upgrade-based DNS-over-TLS through a middlebox, or 302 in the presence of a downgrade attack, could have one of the 303 following outcomes. (These outcomes are similar to those discussed 304 in prior RFCs, such as [RFC3207].) 306 o The DNS client sends a TO=1 query and receives a TO=0 response. 307 In this case there is no upgrade to TLS and DNS resolution occurs 308 normally, without encryption. 310 o The DNS client sends a TO=1 query and receives a TO=1 response, 311 but the middlebox does not understand the TLS negotiation and does 312 not allow those packets to pass through. Clients SHOULD retry DNS 313 without TO set if negotiation fails, and then retry with TLS after 314 a reasonable period (see Section 2.1.3). 316 o The DNS client sends a TO=1 query but receives no response at all. 317 The middlebox might be silently dropping the query due to the 318 presence of the TO bit, when it should, in fact, ignore and pass 319 through unknown flag bits [RFC6891]. The client SHOULD fall back 320 to normal (unencrypted) DNS for a reasonable period (as discussed 321 in Section 2.1.3). 323 In general, clients that attempt TLS and fail can either fall back on 324 unencrypted DNS, or wait and retry later, depending on their privacy 325 requirements. 327 3. Usage Profiles 329 This protocol provides flexibility to accommodate several different 330 use cases. Two usage profiles are defined here to identify specific 331 design points in performance and privacy. Other profiles are 332 possible but are outside the scope of this document. 334 3.1. Opportunistic Privacy Profile 336 For opportunistic privacy, analogous to SMTP opportunistic encryption 337 [RFC7435] one desires privacy when possible, but does not require it. 339 With opportunistic privacy, a client might acquire a recursive DNS 340 resolver from an untrusted source (such as DHCP while roaming), it 341 might or might not validate the TLS certificate, and it might not use 342 a dummy value for the initial query. These choices maximize 343 availability and performance, but they are vulnerable to on-path 344 attacks. 346 Opportunistic privacy can be used by any current client, but it only 347 provides privacy when there are no on-path attackers. 349 3.2. Pre-Deployed Profile 351 For pre-deployed privacy, the DNS client has one or more trusted 352 recursive DNS providers. This profile provides strong privacy 353 guarantees to the user. 355 With pre-deployed privacy, a client retains a copy of the TLS 356 certificate and IP address of each provider. The client will only 357 use one of those DNS providers. Because it has a pre-deployed TLS 358 certificate, it may detect person-in-the-middle and downgrade 359 attacks. 361 With pre-deployed privacy, the DNS client MUST signal to the user 362 when none of the designated DNS servers are available, and MUST NOT 363 provide DNS service until one of the designated DNS servers becomes 364 available. 366 The designated DNS provider may be temporarily unavailable when 367 configuring a network. For example, for clients on networks that 368 require authentication through web-based login, such authentication 369 may require DNS interception and spoofing. Techniques such as those 370 used by DNSSEC-trigger MAY be used during network configuration, with 371 the intent to transition to the designated DNS provider after 372 authentication. The user MUST be alerted that the DNS is not private 373 during such bootstrap. 375 Methods for pre-deployment of the designated DNS provider are outside 376 the scope of this document. In corporate settings, such information 377 may be provided at system installation. Use of multiple public DNS 378 providers suggests that end users are able to configure DNS by hand. 380 4. Performance Considerations 382 DNS-over-TLS incurs additional latency at session startup. It also 383 requires additional state (memory) and increased processing (CPU). 385 1. Latency: Compared to UDP, DNS-over-TCP requires an additional 386 round-trip-time (RTT) of latency to establish the connection. 387 The TLS handshake adds another two RTTs of latency. Clients and 388 servers should support connection keepalive (reuse) and out-of- 389 order processing to amortize connection setup costs. Moreover, 390 TLS connection resumption can further reduce the setup delay. 392 2. State: The use of connection-oriented TCP requires keeping 393 additional state in both kernels and applications. TLS has 394 marginal increases in state over TCP alone. The state 395 requirements are of particular concerns on servers with many 396 clients. Smaller timeout values will reduce the number of 397 concurrent connections, and servers can preemptively close 398 connections when resources limits are exceeded. 400 3. Processing: Use of TLS encryption algorithms results in slightly 401 higher CPU usage. Servers can choose to refuse new DNS-over-TCP 402 clients if processing limits are exceeded. 404 4. Number of connections: To minimize state on DNS servers and 405 connection startup time, clients SHOULD minimize creation of new 406 TCP connections. Use of a local DNS forwarder allows a single 407 active DNS-over-TLS connection allows a single active TCP 408 connection for DNS per client computer. Additional guidance can 409 be found in [I-D.ietf-dnsop-5966bis]. 411 A full performance evaluation is outside the scope of this 412 specification. A more detailed analysis of the performance 413 implications of DNS-over-TLS (and DNS-over-TCP) is discussed in a 414 technical report [tdns] and [I-D.ietf-dnsop-5966bis]. 416 5. IANA Considerations 418 This document defines a new bit ("TO") in the Flags field of the 419 EDNS0 OPT meta-RR. At the time of approval of this draft in the 420 standards track, as per the IANA Considerations of RFC 6891, IANA is 421 requested to reserve the second leftmost bit of the flags as the TO 422 bit, immediately adjacent to the DNSSEC DO bit, as shown in 423 Section 2. 425 IANA is requested add the following value to the "Service Name and 426 Transport Protocol Port Number Registry" registry. That registry is 427 populated by expert review [RFC6335], and such a review will be 428 requested if this document progresses. 430 Service Name DNS-over-TLS 431 Transport Protocol(s) TCP 432 Assignee IESG 433 Contact TBD 434 Description DNS query-response protocol run over TLS 435 Reference This document 437 6. Security Considerations 439 The goal of this proposal is to address the security risks that arise 440 because DNS queries may be eavesdropped upon, as described above. 441 There are a number of residual risks that may impact this goal. 443 1. There are known attacks on TLS, such as person-in-the-middle and 444 protocol downgrade. These are general attacks on TLS and not 445 specific to DNS-over-TLS; please refer to the TLS RFCs for 446 discussion of these security issues. 448 2. Any protocol interactions prior to the TLS handshake are 449 performed in the clear and can be modified by a man-in-the-middle 450 attacker. For this reason, clients MAY discard cached 451 information about server capabilities advertised prior to the 452 start of the TLS handshake. 454 3. As with other uses of STARTTLS-upgrade to TLS, the mechanism 455 specified here is susceptible to downgrade attacks, where a 456 person-in-the-middle prevents a successful TLS upgrade. Keeping 457 track of servers known to support TLS (i.e., "pinning") enables 458 clients to detect downgrade attacks. For servers with no 459 connection history, clients may choose to refuse non-TLS DNS, or 460 they may continue without TLS, depending on their privacy 461 requirements. 463 4. This document does not propose new ideas for certificate 464 authentication for TLS in the context of DNS. Several external 465 methods are possible, although each has weaknesses. The current 466 Certificate Authority infrastructure [RFC5280] is used by HTTP/ 467 TLS [RFC2818]. With many trusted CAs, this approach has 468 recognized weaknesses [CA_Compromise]. Some work is underway to 469 partially address these concerns (for example, with certificate 470 pinning [certificate_pinning], but more work is needed. DANE 471 [RFC6698] provides mechanisms to root certificate trust with 472 DNSSEC. That use here must be carefully evaluated to address 473 potential issues in trust recursion. For stub-to-recursive 474 resolver use, certificate authentication is sometimes either easy 475 or nearly impossible. If the recursive resolver is manually 476 configured, its certificate can be authenticated when it is 477 configured. If the recursive resolver is automatically 478 configured (such as with DHCP [RFC2131]), it could use DHCP 479 authentication mechanisms [RFC3118]). 481 Ongoing discussion and development of opportunistic TLS (connections 482 without CA validation, [RFC7435]) may be relevant to DNS-over-TLS. 484 7. Acknowledgments 486 The authors would like to thank Stephane Bortzmeyer, Brian Haberman, 487 Kim-Minh Kaplan, Bill Manning, George Michaelson, Eric Osterweil, 488 Glen Wiley, John Dickinson, and Sara Dickinson for reviewing this 489 Internet-draft, and Nikita Somaiya for early work on this idea. 491 Work by Zi Hu, Liang Zhu, and John Heidemann in this paper is 492 partially sponsored by the U.S. Dept. of Homeland Security (DHS) 493 Science and Technology Directorate, HSARPA, Cyber Security Division, 494 BAA 11-01-RIKA and Air Force Research Laboratory, Information 495 Directorate under agreement number FA8750-12-2-0344, and contract 496 number D08PC75599. 498 8. References 500 8.1. Normative References 502 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 503 STD 13, RFC 1034, November 1987. 505 [RFC1035] Mockapetris, P., "Domain names - implementation and 506 specification", STD 13, RFC 1035, November 1987. 508 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 509 Requirement Levels", BCP 14, RFC 2119, March 1997. 511 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 512 "Transport Layer Security (TLS) Session Resumption without 513 Server-Side State", RFC 5077, January 2008. 515 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 516 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 518 [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation 519 Requirements", RFC 5966, August 2010. 521 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 522 Cheshire, "Internet Assigned Numbers Authority (IANA) 523 Procedures for the Management of the Service Name and 524 Transport Protocol Port Number Registry", BCP 165, 525 RFC 6335, August 2011. 527 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 528 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 530 8.2. Informative References 532 [CA_Compromise] 533 Infosec Island Admin, "CA Compromise", January 2012, . 538 [I-D.ietf-dnsop-5966bis] 539 Dickinson, J., Bellis, R., Mankin, A., and D. Wessels, 540 "DNS Transport over TCP - Implementation Requirements", 541 draft-ietf-dnsop-5966bis-00 (work in progress), 542 December 2014. 544 [I-D.ietf-dprive-problem-statement] 545 Bortzmeyer, S., "DNS privacy considerations", 546 draft-ietf-dprive-problem-statement-01 (work in progress), 547 October 2014. 549 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 550 STD 53, RFC 1939, May 1996. 552 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 553 RFC 2131, March 1997. 555 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 556 RFC 2595, June 1999. 558 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 560 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 561 Messages", RFC 3118, June 2001. 563 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 564 Transport Layer Security", RFC 3207, February 2002. 566 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 567 Issues", RFC 3234, February 2002. 569 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 570 4rev1", RFC 3501, March 2003. 572 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 573 Rose, "DNS Security Introduction and Requirements", 574 RFC 4033, March 2005. 576 [RFC4892] Woolf, S. and D. Conrad, "Requirements for a Mechanism 577 Identifying a Name Server Instance", RFC 4892, June 2007. 579 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 580 Housley, R., and W. Polk, "Internet X.509 Public Key 581 Infrastructure Certificate and Certificate Revocation List 582 (CRL) Profile", RFC 5280, May 2008. 584 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 585 of Named Entities (DANE) Transport Layer Security (TLS) 586 Protocol: TLSA", RFC 6698, August 2012. 588 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 589 Attack", BCP 188, RFC 7258, May 2014. 591 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 592 Fast Open", RFC 7413, December 2014. 594 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 595 Most of the Time", RFC 7435, December 2014. 597 [certificate_pinning] 598 OWASP, "Certificate and Public Key Pinning", 2014, . 602 [draft-dempsky-dnscurve] 603 Dempsky, M., "DNSCurve", draft-dempsky-dnscurve-01 (work 604 in progress), August 2010, 605 . 607 [draft-osterweil-dane-ipsec] 608 Osterweil, E., Wiley, G., Mitchell, D., and A. Newton, 609 "Opportunistic Encryption with DANE Semantics and IPsec: 610 IPSECA", draft-osterweil-dane-ipsec-00 (work in progress), 611 February 2014, 612 . 615 [draft-wijngaards-confidentialdns] 616 Wijngaards, W., "Confidential DNS", 617 draft-wijngaards-dnsop-confidentialdns-03 (work in 618 progress), November 2013, . 621 [draft-wouters-edns-tcp-keepalive] 622 Wouters, P. and J. Abley, "The edns-tcp-keepalive EDNS0 623 Option", draft-wouters-edns-tcp-keepalive-00 (work in 624 progress), October 2013, . 627 [tdns] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A., 628 and N. Somaiya, "T-DNS: Connection-Oriented DNS to Improve 629 Privacy and Security", Technical report ISI-TR-688, 630 February 2014, . 633 [unbound] NLnet Labs, Verisign labs, "Unbound", December 2013, 634 . 636 Authors' Addresses 638 Zi Hu 639 USC/Information Sciences Institute 640 4676 Admiralty Way, Suite 1133 641 Marina del Rey, CA 90292 642 USA 644 Phone: +1 213 587-1057 645 Email: zihu@usc.edu 647 Liang Zhu 648 USC/Information Sciences Institute 649 4676 Admiralty Way, Suite 1133 650 Marina del Rey, CA 90292 651 USA 653 Phone: +1 310 448-8323 654 Email: liangzhu@usc.edu 655 John Heidemann 656 USC/Information Sciences Institute 657 4676 Admiralty Way, Suite 1001 658 Marina del Rey, CA 90292 659 USA 661 Phone: +1 310 822-1511 662 Email: johnh@isi.edu 664 Allison Mankin 665 Verisign Labs 666 12061 Bluemont Way 667 Reston, VA 20190 669 Phone: +1 703 948-3200 670 Email: amankin@verisign.com 672 Duane Wessels 673 Verisign Labs 674 12061 Bluemont Way 675 Reston, VA 20190 677 Phone: +1 703 948-3200 678 Email: dwessels@verisign.com 680 Paul Hoffman 681 VPN Consortium 683 Email: paul.hoffman@vpnc.org