--- 1/draft-ietf-dprive-dns-over-tls-03.txt 2016-01-21 15:15:10.209557788 -0800 +++ 2/draft-ietf-dprive-dns-over-tls-04.txt 2016-01-21 15:15:10.249558797 -0800 @@ -1,25 +1,25 @@ Network Working Group Z. Hu Internet-Draft L. Zhu Intended status: Standards Track J. Heidemann -Expires: July 7, 2016 USC/Information Sciences +Expires: July 24, 2016 USC/Information Sciences Institute A. Mankin D. Wessels Verisign Labs P. Hoffman ICANN - January 4, 2016 + January 21, 2016 DNS over TLS: Initiation and Performance Considerations - draft-ietf-dprive-dns-over-tls-03 + draft-ietf-dprive-dns-over-tls-04 Abstract This document describes the use of TLS to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7258. In addition, this document specifies two usage profiles for DNS-over-TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. @@ -38,21 +38,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on July 7, 2016. + This Internet-Draft will expire on July 24, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -61,42 +61,42 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Establishing and Managing DNS-over-TLS Sessions . . . . . . . 4 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 4 - 3.2. TLS Handshake and Authentication . . . . . . . . . . . . . 4 + 3.2. TLS Handshake and Authentication . . . . . . . . . . . . . 5 3.3. Transmitting and Receiving Messages . . . . . . . . . . . 5 3.4. Connection Reuse, Close and Reestablishment . . . . . . . 5 - 4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 7 4.2. Out-of-band Key-pinned Privacy Profile . . . . . . . . . . 7 5. Performance Considerations . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 - 7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . . 9 - 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 + 7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . . 10 + 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 12 + 8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 13 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 14 - Appendix A. Out-of-band Key-pinned Privacy Profile Example . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 15 + Appendix A. Out-of-band Key-pinned Privacy Profile Example . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction Today, nearly all DNS queries [RFC1034], [RFC1035] are sent unencrypted, which makes them vulnerable to eavesdropping by an attacker that has access to the network channel, reducing the privacy of the querier. Recent news reports have elevated these concerns, and recent IETF work has specified privacy considerations for DNS [RFC7626]. @@ -132,51 +132,63 @@ successor. The protocol described here works for any DNS client to server communication using DNS-over-TCP. That is, it may be used for queries and responses between stub clients and recursive servers as well as between recursive clients and authoritative servers. This document describes two profiles in Section 4 providing different levels of assurance of privacy: an opportunistic privacy profile and an out-of-band key-pinned privacy profile. It is expected that a - future document based on [TBD] will further describe additional - privacy profiles for DNS over both TLS and DTLS. [Note to RFC - Editor: informative reference for that document will be forthcoming] + future document based on [dgr-dprive-dtls-and-tls-profiles] will + further describe additional privacy profiles for DNS over both TLS + and DTLS. An earlier version of this document described a technique for upgrading a DNS-over-TCP connection to a DNS-over-TLS session with, essentially, "STARTTLS for DNS". To simplify the protocol, this document now only uses a well-known port to specify TLS use, omitting the upgrade approach. The upgrade approach no longer appears in this document, which now focuses exclusively on the use of a well-known port for DNS-over-TLS. 2. Reserved Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Establishing and Managing DNS-over-TLS Sessions 3.1. Session Initiation - A DNS server that supports DNS-over-TLS SHOULD listen for and accept + A DNS server that supports DNS-over-TLS MUST listen for and accept TCP connections on port 853. DNS clients desiring privacy from DNS-over-TLS from a particular - server SHOULD establish a TCP connection to port 853 on the server. - Upon successful establishment of the TCP connection, client and - server SHOULD immediately initiate a TLS handshake using the + server MUST establish a TCP connection which SHOULD be to port 853 on + the server. This is a SHOULD rather than a MUST because a server MAY + also offer DNS-over-TLS service on another port by agreement with its + client. Such an additional port MUST NOT be port 53, but MAY be from + the FCFS port range. The first data exchange on this TCP connection + MUST be the client and server initiating a TLS handshake using the procedure described in [RFC5246]. + DNS clients and servers MUST NOT use port 853 to transport clear text + DNS messages. DNS clients MUST NOT send and DNS servers MUST NOT + respond to clear text DNS messages on any port used for DNS-over-TLS + (including, for example, after a failed TLS handshake). There are + significant security issues in mixing protected and unprotected data + and for this reason TCP connections on a port designated by a given + server for DNS-over-TLS are reserved purely for encrypted + communications. + DNS clients SHOULD remember server IP addresses that don't support DNS-over-TLS, including timeouts, connection refusals, and TLS handshake failures, and not request DNS-over-TLS from them for a reasonable period (such as one hour per server). DNS clients following an out-of-band key-pinned privacy profile MAY be more aggressive about retrying DNS-over-TLS connection failures. 3.2. TLS Handshake and Authentication Once the DNS client succeeds in connecting via TCP on the well-known @@ -191,25 +203,25 @@ After TLS negotiation completes, the connection will be encrypted and is now protected from eavesdropping. At this point, normal DNS queries SHOULD take place. 3.3. Transmitting and Receiving Messages All messages (requests and responses) in the established TLS session MUST use the two-octet length field described in Section 4.2.2 of [RFC1035]. For reasons of efficiency, DNS clients and servers SHOULD - transmit the two-octet length field, and the message described by - that length field, to the TCP layer at the same time (e.g., in a - single "write" system call) to make it more likely that all the data - will be transmitted in a single TCP segment - ([I-D.ietf-dnsop-5966bis], Section 8). + pass the two-octet length field, and the message described by that + length field, to the TCP layer at the same time (e.g., in a single + "write" system call) to make it more likely that all the data will be + transmitted in a single TCP segment ([I-D.ietf-dnsop-5966bis], + Section 8). In order to minimize latency, clients SHOULD pipeline multiple queries over a TLS session. When a DNS client sends multiple queries to a server, it should not wait for an outstanding reply before sending the next query ([I-D.ietf-dnsop-5966bis], Section 6.2.1.1). Since pipelined responses can arrive out-of-order, clients MUST match responses to outstanding queries using the ID field, query name, type, and class. Failure by clients to properly match responses to outstanding queries can have serious consequences for @@ -258,22 +270,26 @@ Clients and servers that keep idle connections open MUST be robust to termination of idle connection by either party. As with current DNS- over-TCP, DNS servers MAY close the connection at any time (perhaps due to resource constraints). As with current DNS-over-TCP, clients MUST handle abrupt closes and be prepared to reestablish connections and/or retry queries. When reestablishing a DNS-over-TCP connection that was terminated, as discussed in [I-D.ietf-dnsop-5966bis], TCP Fast Open [RFC7413] is of - benefit. DNS servers SHOULD enable fast TLS session resumption - [RFC5077] and this SHOULD be used when reestablishing connections. + benefit. Underlining the requirement for sending only encrypted DNS + data on a DNS-over-TLS port (Section 3.2), when using TCP Fast Open + the client and server MUST immediately initiate or resume a TLS + handshake (clear text DNS MUST NOT be exchanged). DNS servers SHOULD + enable fast TLS session resumption [RFC5077] and this SHOULD be used + when reestablishing connections. When closing a connection, DNS servers SHOULD use the TLS close- notify request to shift TCP TIME-WAIT state to the clients. Additional requirements and guidance for optimizing DNS-over-TCP are provided by [RFC5966], [I-D.ietf-dnsop-5966bis]. 4. Usage Profiles This protocol provides flexibility to accommodate several different use cases. This document defines two usage profiles: (1) @@ -273,23 +289,22 @@ Additional requirements and guidance for optimizing DNS-over-TCP are provided by [RFC5966], [I-D.ietf-dnsop-5966bis]. 4. Usage Profiles This protocol provides flexibility to accommodate several different use cases. This document defines two usage profiles: (1) opportunistic privacy, and (2) out-of-band key-pinned authentication that can be used to obtain stronger privacy guarantees if the client has a trusted relationship with a DNS server supporting TLS. - Additional methods of authentication will be defined in a forthcoming - draft [TBD]. + draft [dgr-dprive-dtls-and-tls-profiles]. 4.1. Opportunistic Privacy Profile For opportunistic privacy, analogous to SMTP opportunistic encryption [RFC7435] one does not require privacy, but one desires privacy when possible. With opportunistic privacy, a client might learn of a TLS-enabled recursive DNS resolver from an untrusted source (such as DHCP while roaming), it might or might not validate the resolver. These choices @@ -529,27 +544,26 @@ another server when available, (b) continue without TLS, or (c) refuse to forward the query. 2. Middleboxes [RFC3234] are present in some networks and have been known to interfere with normal DNS resolution. Use of a designated port for DNS-over-TLS should avoid such interference. In general, clients that attempt TLS and fail can either fall back on unencrypted DNS, or wait and retry later, depending on their Privacy Profile and privacy requirements. - 3. Any DNS protocol interactions prior to the TLS handshake that are - performed in the clear can be modified by a person-in-the-middle - attacker. For example, unencrypted queries and responses might - take place over port 53 between a client and server prior to TLS. - For this reason, clients MAY discard cached information about - server capabilities advertised prior to the start of the TLS - handshake. + 3. Any DNS protocol interactions performed in the clear can be + modified by a person-in-the-middle attacker. For example, + unencrypted queries and responses might take place over port 53 + between a client and server. For this reason, clients MAY + discard cached information about server capabilities advertised + in clear text. 4. This document does not itself specify ideas to resist known traffic analysis or side channel leaks. Even with encrypted messages, a well-positioned party may be able to glean certain details from an analysis of message timings and sizes. Clients and servers may consider the use of a padding method to address privacy leakage due to message sizes [I-D.edns0-padding] 10. Contributing Authors @@ -713,20 +726,28 @@ [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, . [dempsky-dnscurve] Dempsky, M., "DNSCurve", draft-dempsky-dnscurve-01 (work in progress), August 2010, . + [dgr-dprive-dtls-and-tls-profiles] + Dickinson, S., Gillmor, D., and T. Reddy, + "Authentication and (D)TLS Profile for DNS-over-TLS and + DNS-over-DTLS", draft-dgr-dprive-dtls-and-tls-profiles-00 + (work in progress), December 2015, . + [dnssec-trigger] NLnet Labs, "Dnssec-Trigger", May 2014, . [draft-ietf-dprive-dnsodtls] Reddy, T., Wing, D., and P. Patil, "DNS over DTLS (DNSoD)", draft-ietf-dprive-dnsodtls-01 (work in progress), June 2015, .