idnits 2.17.00 (12 Aug 2021) /tmp/idnits45102/draft-hzhwm-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 == 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 (February 12, 2015) is 2655 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: draft-ietf-dnsop-5966bis has been published as RFC 7766 == Outdated reference: draft-ietf-dprive-problem-statement has been published as RFC 7626 -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 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: August 16, 2015 USC/Information Sciences 6 Institute 7 A. Mankin 8 D. Wessels 9 Verisign Labs 10 P. Hoffman 11 VPN Consortium 12 February 12, 2015 14 TLS for DNS: Initiation and Performance Considerations 15 draft-hzhwm-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 7285. In addition, this document discusses 25 performance considerations to minimize overheads from using TCP and 26 TLS with DNS, pertaining to both approaches. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 16, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 1. Introduction 62 Today, nearly all DNS queries ([RFC1034] and [RFC1035]) are sent 63 unencrypted, which makes them vulnerable to eavesdropping by an 64 attacker that has access to the network channel, reducing the privacy 65 of the querier. Recent news reports have elevated these concerns, 66 and ongoing efforts are beginning to identify privacy concerns about 67 DNS ([I-D.ietf-dprive-problem-statement]). 69 Prior work has addressed some aspects of DNS security, but there has 70 been little work till recently on privacy between a DNS client and 71 server. DNS Security Extensions (DNSSEC, [RFC4033]) provide 72 _response integrity_ by defining mechanisms to cryptographically sign 73 zones, allowing end-users (or their first-hop resolver) to verify 74 replies are correct. DNSSEC by intention does not protect request 75 and response privacy. Traditionally, either privacy was not 76 considered a requirement for DNS traffic, or it was assumed that 77 network traffic was sufficiently private, however these perceptions 78 are evolving due to recent events [RFC7285]. 80 DNSCurve [draft-dempsky-dnscurve] defines a method to add 81 confidentiality to the link between DNS clients and servers; however, 82 it does so with a new cryptographic protocol and does not take 83 advantage of an existing standard protocol such as TLS. 84 ConfidentialDNS [draft-wijngaards-confidentialdns] and IPSECA 85 [draft-osterweil-dane-ipsec] use opportunistic encryption to offer 86 privacy for DNS queries and responses. Finally, others have 87 suggested DNS-over-TLS. Unbound DNS software [unbound] includes a 88 DNS-over-TLS implementation. The present document goes beyond past 89 DNS-over-TLS discussions by providing two modes of initiation for 90 DNS-over-TLS, use of a well-known port, TBD, and use of a negotiation 91 mechanism in an established connection. 93 This document describes a protocol that is resilient in environments 94 affected by differing middle box concerns. The port-based initiation 95 of TLS is very straightforward, but might be blocked by firewalls or 96 be unwelcome to some DNS client or server implementations. If port- 97 based initiation of TLS fails, there is an upgrade-based negotiation 98 mechanism to enable DNS clients and servers to upgrade an existing 99 DNS-over-TCP connection to a DNS-over-TLS connection, analogous to 100 upgrade mechanisms in other uses of TLS, such as STARTTLS [RFC2595] 101 used in SMTP [RFC3207], IMAP [RFC3501] and POP [RFC1939], to name 102 just a few of many. But like those, the upgrade-based approach has 103 middle box considerations, particularly downgrade attacks, as 104 discussed in Section 2.4. 106 The protocol described here works for any DNS client to server 107 communication using DNS-over-TCP. In particular, the same protocol 108 can be used for stub-recursive and recursive-authoritative 109 communications. We expect implementation initially between stubs and 110 recursives. 112 In specifying TLS negotiation for DNS, this document defines only the 113 protocol extensions that are needed. It does not describe how DNS 114 clients might validate server certificates or specify trusted 115 certificate authorities. Solutions for certificate authentication 116 are currently outside the scope of this document. 118 1.1. Reserved Words 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 2. Protocol Changes 126 The only changes required for port-based DNS-over-TLS are those 127 optimizing TCP and TLS performance discussed in the following. The 128 DNS protocol itself is unchanged. 130 Clients and servers negotiate upgrade-based DNS-over-TLS by setting a 131 bit in the Flags field of the EDNS0 [RFC6891] OPT meta-RR. The "TLS 132 OK" (TO) bit is defined as the second bit of the third and fourth 133 bytes of the "extended RCODE and flags" portion of the EDNS0 OPT 134 meta-RR, immediately adjacent to the "DNSSEC OK" (DO) bit [RFC4033]: 136 +0 (MSB) +1 (LSB) 137 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 138 0: | EXTENDED-RCODE | VERSION | 139 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 140 2: |DO|TO| Z | 141 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 143 2.1. Use by DNS Clients 145 DNS clients first try port-based DNS-over-TLS. If that connection 146 fails, they try upgrade-based DNS-over-TLS. 148 2.1.1. Port-Based DNS-over-TLS for Clients 150 DNS clients SHOULD first try using port-based DNS-over-TLS by 151 establishing the TCP connection to the dedicated port TBD (number to 152 be defined in Section 4). 154 Stub resolvers do not change their recursive resolvers often. A 155 slight delay in failing to establish a port-based DNS-over-TLS 156 connection is probably minor relative to the benefit of encrypted DNS 157 queries and responses. The stub resolver should give a reasonable 158 amount of time for the recursive resolver to start the TLS setup, 159 such as a few seconds. 161 It SHOULD be an implementation and/or local determination as to 162 whether to attempt TLS via the dedicated port first and then fall 163 back to STARTTLS use, or to choose some other order of attempts and 164 fallbacks. 166 2.1.2. Sending Queries for Upgrade-Based DNS-over-TLS 168 Setting the TO bit in queries sent using UDP transport has no 169 protocol meaning. However, the client MAY set the TO bit when using 170 UDP transport. The server MUST ignore the TO bit when receiving UDP 171 transport. 173 DISCUSSION: community advice is sought on this. The advantage of 174 allowing a client to send UDP on TO is that servers can collect 175 information on deployment (as happened with the DO bit). The 176 disadvantage is that a meaningless bit (TO over UDP) might cause 177 confusion, and some middleboxes might not pass a UDP query with the 178 TO bit set. 180 DNS clients set the TO bit in the initial query sent to a server 181 using TCP transport to signal their desire that the TCP connection be 182 upgraded to TLS. DNS clients SHOULD NOT set the TO bit on queries 183 when using TCP or TLS transport because doing so has no meaning in 184 this protocol. 186 Since the motivation for upgrade-based DNS-over-TLS is to preserve 187 privacy, DNS clients SHOULD use an initial (unprotected) query that 188 reveals no private information in the initial TO=1 query to a server. 189 To provide a standard "dummy" query, it is RECOMMENDED to send the 190 initial query with RD=0, QNAME="STARTTLS", QCLASS=CH, and QTYPE=TXT 191 ("STARTTLS/CH/TXT") analogous to administrative queries already in 192 widespread use [RFC4892]. 194 After sending the initial TO=1 query using TCP transport, DNS clients 195 MUST wait for the initial response before sending any subsequent 196 queries over the same TCP connection. 198 2.1.3. Receiving Responses for Upgrade-Based DNS-over-TLS 200 A DNS client that receives a response using UDP transport that has 201 the TO bit set handles that response as usual. It MAY record the 202 server's support for DNS-over-TLS and use that information as part of 203 its server selection algorithm in the case where multiple servers are 204 available to service a particular query. 206 A DNS client that has sent the TO bit using TCP transport and 207 receives a response to its initial query that has the TO bit set MUST 208 immediately initiate a TLS handshake using the procedure described in 209 [RFC5246]. (Note that this document does not yet deal with what 210 happens when the TLS handshake does not succeed.) 212 DISCUSSION: are there any cases in which a DNS client that sent TO on 213 DNS-over-TCP and receives TO in the initial response from the server 214 would not initiate the TLS handshake? Is there any reason for this 215 to be SHOULD rather than MUST? 217 A DNS client that receives a response to its initial query using TCP 218 transport that has the TO bit clear MUST not initiate a TLS handshake 219 and SHOULD utilize the existing TCP connection for subsequent 220 queries. DNS clients SHOULD remember server IP addresses that don't 221 support upgrade-based DNS-over-TLS, including TLS handshake failures, 222 and not request DNS-over-TLS from them for reasonable period (such as 223 one hour per server). 225 2.2. Use by DNS Servers 227 A DNS server that supports DNS-over-TLS SHOULD support port-based 228 DNS-over-TLS, and SHOULD support upgrade-based DNS-over TLS. 230 2.2.1. Receiving Queries for Upgrade-Based DNS-over-TLS 232 A DNS server receiving a query over UDP with the TO bit ignores that 233 bit. A DNS server receiving a query over an existing TLS connection 234 with the TO bit ignores that bit. 236 A DNS server receiving an initial query over TCP that has the TO bit 237 set MAY inform the client it is willing to establish a TLS session, 238 as described in the next section. 240 A DNS server receiving subsequent queries over TCP MUST ignore the TO 241 bit. (A client wishing to start TLS after the initial query MUST 242 open a new TCP connection to do so.) 244 2.2.2. Sending Responses 246 A DNS server sending a response over UDP to a query that had an OPT 247 meta-RR SHOULD set the TO bit to indicate its general support for 248 DNS-over-TLS, as long as it is willing and able to support a TLS 249 connection with the particular client. 251 A DNS server receiving an initial query over TCP that has the TO bit 252 set MAY set the TO bit in its response. The server MUST then proceed 253 with the TLS handshake protocol. 255 A DNS server receiving a "dummy" STARTTLS/CH/TXT query over TCP MUST 256 respond with RCODE=0 and a TXT RR in the Answer section. Contents of 257 the TXT RR are strictly informative (for humans) and MUST NOT be 258 interpreted by the client software. Recommended TXT RDATA values are 259 "STARTTLS" or "NO_TLS". 261 2.3. Established Sessions 263 After TLS negotiation completes, the connection will be encrypted and 264 is now protected from eavesdropping and normal DNS queries SHOULD 265 take place, following DNS-over-TCP framing ([RFC1035], section 266 4.2.2). 268 Both clients and servers SHOULD follow existing DNS-over-TCP timeout 269 rules, which are often implementation- and situation-dependent. In 270 the absence of any other advice, the RECOMMENDED timeout values are 271 30 seconds for recursive name servers, 60 seconds for clients of 272 recursive name servers, 10 seconds for authoritative name servers, 273 and 20 seconds for clients of authoritative name servers. Current 274 work in this area may assist DNS-over-TLS clients and servers select 275 useful timeout values [draft-wouters-edns-tcp-keepalive] [tdns]. 277 As with current DNS-over-TCP, DNS servers MAY close the connection at 278 any time (e.g., due to resource constraints). As with current DNS- 279 over-TCP, clients MUST handle abrupt closes and be prepared to 280 reestablish connections and/or retry queries. DNS servers SHOULD use 281 the TLS close-notify request to shift TCP TIME-WAIT state to the 282 clients. Additional requirements and guidance for optimizing DNS- 283 over-TCP are provided by [RFC5966], [I-D.ietf-dnsop-5966bis]. As 284 discussed in [I-D.ietf-dnsop-5966bis], TCP Fast Open [RFC7413] is of 285 benefit. 287 DNS servers SHOULD enable fast TLS session resumption [RFC5077] to 288 avoid keeping per-client session state. 290 2.4. Downgrade Attacks and Middleboxes 292 Middleboxes [RFC3234] may be present in some networks and have been 293 known to interfere with normal DNS resolution and create problems for 294 DNS-over-TLS. Remarkably, downgrade attacks can affect plaintext 295 protocols that utilize "STARTTLS" signaling in a similar way. A DNS 296 client attempting upgrade-based DNS-over-TLS through a middlebox, or 297 in the presence of a downgrade attack, could have one of the 298 following outcomes. (These outcomes are similar to those discussed 299 in prior RFCs, such as [RFC3207].) 301 o The DNS client sends a TO=1 query and receives a TO=0 response. 302 In this case there is no upgrade to TLS and DNS resolution occurs 303 normally, without encryption. 305 o The DNS client sends a TO=1 query and receives a TO=1 response, 306 but the middlebox does not understand the TLS negotiation. 307 Middleboxes SHOULD clear TO in replies if they are not prepared to 308 pass through TLS negotiation. Clients SHOULD retry DNS without TO 309 set if negotiation fails, and then retry with TLS after a 310 reasonable period (see Section 2.1.3). 312 o The DNS client sends a TO=1 query but receives no response at all. 313 The middlebox might be silently dropping the query due to the 314 presence of the TO bit, when it should, in fact, ignore and pass 315 through unknown flag bits [RFC6891]. The client SHOULD fall back 316 to normal (unencrypted) DNS for a reasonable period (as discussed 317 in Section 2.1.3). 319 In general, clients that attempt TLS and fail can either fall back on 320 unencrypted DNS, or wait and retry later, depending on their privacy 321 requirements. 323 3. Performance Considerations 325 DNS-over-TLS incurs additional latency at session startup. It also 326 requires additional state (memory) increased processing (CPU). 328 1. Latency: Compared to UDP, DNS-over-TCP requires an additional 329 round-trip-time (RTT) of latency to establish the connection. 330 The TLS handshake adds another two RTTs of latency. Clients and 331 servers should support connection keepalive (reuse) and out-of- 332 order processing to amortize connection setup costs. Moreover, 333 TLS connection resumption can further reduce the setup delay. 335 2. State: The use of connection-oriented TCP requires keeping 336 additional state in both kernels and applications. TLS has 337 marginal increases in state over TCP alone. The state 338 requirements are of particular concerns on servers with many 339 clients. Smaller timeout values will reduce the number of 340 concurrent connections, and servers can preemptively close 341 connections when resources limits are exceeded. 343 3. Processing: Use of TLS encryption algorithms results in slightly 344 higher CPU usage. Servers can choose to refuse new DNS-over-TCP 345 clients if processing limits are exceeded. 347 A full performance evaluation is outside the scope of this 348 specification. A more detailed analysis of the performance 349 implications of DNS-over-TLS (and DNS-over-TCP) is discussed in a 350 technical report [tdns]. 352 4. IANA Considerations 354 This document defines a new bit ("TO") in the Flags field of the 355 EDNS0 OPT meta-RR. At the time of approval of this draft in the 356 standards track, as per the IANA Considerations of RFC 6891, IANA is 357 requested to reserve the second leftmost bit of the flags as the TO 358 bit, immediately adjacent to the DNSSEC DO bit, as shown in 359 Section 2. 361 IANA is requested add the following value to the "Service Name and 362 Transport Protocol Port Number Registry" registry. That registry is 363 populated by expert review [RFC6335], and such a review will be 364 requested if this document progresses. It would be desirable to be 365 assigned port 54 upon completion of review. 367 Service Name DNS-over-TLS 368 Transport Protocol(s) TCP 369 Assignee IESG 370 Contact TBD 371 Description DNS query-response protocol run over TLS 372 Reference This document 374 5. Security Considerations 376 The goal of this proposal is to address the security risks that arise 377 because DNS queries may be eavesdropped upon, as described above. 378 There are a number of residual risks that may impact this goal. 380 1. There are known attacks on TLS, such as person-in-the-middle and 381 protocol downgrade. These are general attacks on TLS and not 382 specific to DNS-over-TLS; we refer to the TLS RFCs for discussion 383 of these security issues. 385 2. Any protocol interactions prior to the TLS handshake are 386 performed in the clear and can be modified by a man-in-the-middle 387 attacker. For this reason, clients MAY discard cached 388 information about server capabilities advertised prior to the 389 start of the TLS handshake. 391 3. As with other uses of STARTTLS-upgrade to TLS, the mechanism 392 specified here is susceptible to downgrade attacks, where a 393 person-in-the-middle prevents a successful TLS upgrade. Keeping 394 track of servers known to support TLS (i.e., "pinning") enables 395 clients to detect downgrade attacks. For servers with no 396 connection history, clients may choose to refuse non-TLS DNS, or 397 they may continue without TLS, depending on their privacy 398 requirements. 400 4. This document does not propose new ideas for certificate 401 authentication for TLS in the context of DNS. Several external 402 methods are possible, although each has weaknesses. The current 403 Certificate Authority infrastructure [RFC5280] is used by HTTP/ 404 TLS [RFC2818]. With many trusted CAs, this approach has 405 recognized weaknesses [CA_Compromise]. Some work is underway to 406 partially address these concerns (for example, with certificate 407 pinning [certificate_pinning], but more work is needed. DANE 408 [RFC6698] provides mechanisms to root certificate trust with 409 DNSSEC. That use here must be carefully evaluated to address 410 potential issues in trust recursion. For stub-to-recursive 411 resolver use, certificate authentication is sometimes either easy 412 or nearly impossible. If the recursive resolver is manually 413 configured, its certificate can be authenticated when it is 414 configured. If the recursive resolver is automatically 415 configured (such as with DHCP [RFC2131]), it could use DHCP 416 authentication mechanisms [RFC3118]). 418 Ongoing discussion and development of opportunistic TLS (connections 419 without CA validation, [RFC7435]) may be relevant to DNS-over-TLS. 421 6. Acknowledgments 423 We would like to thank Stephane Bortzmeyer, Brian Haberman, Kim-Minh 424 Kaplan, Bill Manning, George Michaelson, Eric Osterweil, Glen Wiley, 425 John Dickinson, and Sara Dickinson for reviewing this Internet-draft, 426 and Nikita Somaiya for early work on this idea. 428 Work by Zi Hu, Liang Zhu, and John Heidemann in this paper is 429 partially sponsored by the U.S. Dept. of Homeland Security (DHS) 430 Science and Technology Directorate, HSARPA, Cyber Security Division, 431 BAA 11-01-RIKA and Air Force Research Laboratory, Information 432 Directorate under agreement number FA8750-12-2-0344, and contract 433 number D08PC75599. 435 7. References 437 7.1. Normative References 439 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 440 STD 13, RFC 1034, November 1987. 442 [RFC1035] Mockapetris, P., "Domain names - implementation and 443 specification", STD 13, RFC 1035, November 1987. 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, March 1997. 448 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 449 "Transport Layer Security (TLS) Session Resumption without 450 Server-Side State", RFC 5077, January 2008. 452 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 453 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 455 [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation 456 Requirements", RFC 5966, August 2010. 458 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 459 Cheshire, "Internet Assigned Numbers Authority (IANA) 460 Procedures for the Management of the Service Name and 461 Transport Protocol Port Number Registry", BCP 165, 462 RFC 6335, August 2011. 464 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 465 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 467 7.2. Informative References 469 [CA_Compromise] 470 Infosec Island Admin, "CA Compromise", January 2012, . 475 [I-D.ietf-dnsop-5966bis] 476 Dickinson, J., Bellis, R., Mankin, A., and D. Wessels, 477 "DNS Transport over TCP - Implementation Requirements", 478 draft-ietf-dnsop-5966bis-00 (work in progress), 479 December 2014. 481 [I-D.ietf-dprive-problem-statement] 482 Bortzmeyer, S., "DNS privacy considerations", 483 draft-ietf-dprive-problem-statement-00 (work in progress), 484 October 2014. 486 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 487 STD 53, RFC 1939, May 1996. 489 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 490 RFC 2131, March 1997. 492 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 493 RFC 2595, June 1999. 495 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 497 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 498 Messages", RFC 3118, June 2001. 500 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 501 Transport Layer Security", RFC 3207, February 2002. 503 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 504 Issues", RFC 3234, February 2002. 506 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 507 4rev1", RFC 3501, March 2003. 509 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 510 Rose, "DNS Security Introduction and Requirements", 511 RFC 4033, March 2005. 513 [RFC4892] Woolf, S. and D. Conrad, "Requirements for a Mechanism 514 Identifying a Name Server Instance", RFC 4892, June 2007. 516 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 517 Housley, R., and W. Polk, "Internet X.509 Public Key 518 Infrastructure Certificate and Certificate Revocation List 519 (CRL) Profile", RFC 5280, May 2008. 521 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 522 of Named Entities (DANE) Transport Layer Security (TLS) 523 Protocol: TLSA", RFC 6698, August 2012. 525 [RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., 526 Roome, W., Shalunov, S., and R. Woundy, "Application-Layer 527 Traffic Optimization (ALTO) Protocol", RFC 7285, 528 September 2014. 530 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 531 Fast Open", RFC 7413, December 2014. 533 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 534 Most of the Time", RFC 7435, December 2014. 536 [certificate_pinning] 537 OWASP, "Certificate and Public Key Pinning", 2014, . 541 [draft-dempsky-dnscurve] 542 Dempsky, M., "DNSCurve", draft-dempsky-dnscurve-01 (work 543 in progress), August 2010, 544 . 546 [draft-osterweil-dane-ipsec] 547 Osterweil, E., Wiley, G., Mitchell, D., and A. Newton, 548 "Opportunistic Encryption with DANE Semantics and IPsec: 549 IPSECA", draft-osterweil-dane-ipsec-00 (work in progress), 550 February 2014, 551 . 554 [draft-wijngaards-confidentialdns] 555 Wijngaards, W., "Confidential DNS", 556 draft-wijngaards-dnsop-confidentialdns-00 (work in 557 progress), November 2013, . 560 [draft-wouters-edns-tcp-keepalive] 561 Wouters, P. and J. Abley, "The edns-tcp-keepalive EDNS0 562 Option", draft-wouters-edns-tcp-keepalive-00 (work in 563 progress), October 2013, . 566 [tdns] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A., 567 and N. Somaiya, "T-DNS: Connection-Oriented DNS to Improve 568 Privacy and Security", Technical report ISI-TR-688, 569 February 2014, . 572 [unbound] NLnet Labs, Verisign labs, "Unbound", December 2013, 573 . 575 Authors' Addresses 577 Zi Hu 578 USC/Information Sciences Institute 579 4676 Admiralty Way, Suite 1133 580 Marina del Rey, CA 90292 581 USA 583 Phone: +1 213 587-1057 584 Email: zihu@usc.edu 586 Liang Zhu 587 USC/Information Sciences Institute 588 4676 Admiralty Way, Suite 1133 589 Marina del Rey, CA 90292 590 USA 592 Phone: +1 310 448-8323 593 Email: liangzhu@usc.edu 595 John Heidemann 596 USC/Information Sciences Institute 597 4676 Admiralty Way, Suite 1001 598 Marina del Rey, CA 90292 599 USA 601 Phone: +1 310 822-1511 602 Email: johnh@isi.edu 604 Allison Mankin 605 Verisign Labs 606 12061 Bluemont Way 607 Reston, VA 20190 609 Phone: +1 703 948-3200 610 Email: amankin@verisign.com 611 Duane Wessels 612 Verisign Labs 613 12061 Bluemont Way 614 Reston, VA 20190 616 Phone: +1 703 948-3200 617 Email: dwessels@verisign.com 619 Paul Hoffman 620 VPN Consortium 622 Email: paul.hoffman@vpnc.org