--- 1/draft-ietf-dprive-dns-over-tls-08.txt 2016-03-17 23:16:53.695158403 -0700 +++ 2/draft-ietf-dprive-dns-over-tls-09.txt 2016-03-17 23:16:53.771160287 -0700 @@ -1,107 +1,105 @@ Network Working Group Z. Hu Internet-Draft L. Zhu Intended status: Standards Track J. Heidemann -Expires: September 16, 2016 USC/Information Sciences - Institute +Expires: September 18, 2016 USC/Information Sciences Institute A. Mankin D. Wessels Verisign Labs P. Hoffman ICANN - March 15, 2016 + March 17, 2016 Specification for DNS over TLS - draft-ietf-dprive-dns-over-tls-08 + draft-ietf-dprive-dns-over-tls-09 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 7626. 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. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE working group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. - Note: this document was formerly named - draft-ietf-dprive-start-tls-for-dns. Its name has been changed to - better describe the mechanism now used. Please refer to working - group archives under the former name for history and previous - discussion. [RFC Editor: please remove this paragraph prior to - publication] + Note: this document was formerly named draft-ietf-dprive-start-tls- + for-dns. Its name has been changed to better describe the mechanism + now used. Please refer to working group archives under the former + name for history and previous discussion. [RFC Editor: please remove + this paragraph prior to publication] -Status of this Memo +Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 September 16, 2016. + This Internet-Draft will expire on September 18, 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3. Establishing and Managing DNS-over-TLS Sessions . . . . . . . 5 - 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 5 - 3.2. TLS Handshake and Authentication . . . . . . . . . . . . . 6 - 3.3. Transmitting and Receiving Messages . . . . . . . . . . . 6 - 3.4. Connection Reuse, Close and Reestablishment . . . . . . . 7 - 4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . . 8 - 4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 8 - 4.2. Out-of-band Key-pinned Privacy Profile . . . . . . . . . . 8 - 5. Performance Considerations . . . . . . . . . . . . . . . . . . 10 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . . 11 - 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 - 8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 14 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 - Appendix A. Out-of-band Key-pinned Privacy Profile Example . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 + 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 . . . . . . . . . . . . 5 + 3.3. Transmitting and Receiving Messages . . . . . . . . . . . 5 + 3.4. Connection Reuse, Close and Reestablishment . . . . . . . 6 + 4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 7 + 4.2. Out-of-band Key-pinned Privacy Profile . . . . . . . . . 7 + 5. Performance Considerations . . . . . . . . . . . . . . . . . 9 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . 10 + 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 + 8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 13 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 + 12.2. Informative References . . . . . . . . . . . . . . . . . 16 + Appendix A. Out-of-band Key-pinned Privacy Profile Example . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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]. @@ -161,36 +159,35 @@ 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 MUST by default listen for - and accept TCP connections on port 853. By mutual agreement with its - clients, the server MAY, instead, use a port other than 853 for DNS- - over-TLS. In order to use a port other than 853, both clients and - servers would need a configuration option in their software. + and accept TCP connections on port 853, unless it has mutual + agreement with its clients to use a port other than 853 for DNS-over- + TLS. In order to use a port other than 853, both clients and servers + would need a configuration option in their software. DNS clients desiring privacy from DNS-over-TLS from a particular server MUST by default establish a TCP connection to port 853 on the - server. By mutual agreement with its server, the client MAY, - instead, use a port other than port 853 for DNS-over-TLS. Such an - other port MUST NOT be port 53, but MAY be from the "first-come, - first-served" port range. This recommendation against use of port 53 - for DNS-over-TLS is to avoid complication in selecting use or non-use - of TLS, and to reduce risk of downgrade attacks. The first data - exchange on this TCP connection MUST be the client and server - initiating a TLS handshake using the procedure described in - [RFC5246]. + server, unless it has mutual agreement with its server to use a port + other than port 853 for DNS-over-TLS. Such an other port MUST NOT be + port 53, but MAY be from the "first-come, first-served" port range. + This recommendation against use of port 53 for DNS-over-TLS is to + avoid complication in selecting use or non-use of TLS, and to reduce + risk of downgrade attacks. 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. @@ -202,21 +199,21 @@ 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 port for DNS-over-TLS, it proceeds with the TLS handshake [RFC5246], following the best practices specified in [BCP195]. The client will then authenticate the server, if required. This document does not propose new ideas for authentication. Depending on - the privacy profile in use Section 4, the DNS client may choose not + the privacy profile in use (Section 4), the DNS client may choose not to require authentication of the server, or it may make use of a trusted Subject Public Key Info (SPKI) Fingerprint pinset. After TLS negotiation completes, the connection will be encrypted and is now protected from eavesdropping. 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 @@ -235,21 +232,21 @@ responses to outstanding queries on the same TLS connection using the Message ID. If the response contains a question section, the client MUST match the QNAME, QCLASS, and QTYPE fields. Failure by clients to properly match responses to outstanding queries can have serious consequences for interoperability ([RFC7766], Section 7). 3.4. Connection Reuse, Close and Reestablishment For DNS clients that use library functions such as "getaddrinfo()" and "gethostbyname()", current implementations are known to open and - close TCP connections each DNS call. To avoid excess TCP + close TCP connections for each DNS query. To avoid excess TCP connections, each with a single query, clients SHOULD reuse a single TCP connection to the recursive resolver. Alternatively they may prefer to use UDP to a DNS-over-TLS enabled caching resolver on the same machine that then uses a system-wide TCP connection to the recursive resolver. In order to amortize TCP and TLS connection setup costs, clients and servers SHOULD NOT immediately close a connection after each response. Instead, clients and servers SHOULD reuse existing connections for subsequent queries as long as they have sufficient @@ -313,21 +310,21 @@ 4.1. Opportunistic Privacy Profile For opportunistic privacy, analogous to SMTP opportunistic security [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's DNS server option [RFC3646] to discover the IP address followed by attemting the DNS-over-TLS on port 853, or with a future DHCP option - that specifics DNS port). With such an discovered DNS server, the + that specifies DNS port). With such a discovered DNS server, the client might or might not validate the resolver. These choices maximize availability and performance, but they leave the client vulnerable to on-path attacks that remove privacy. Opportunistic privacy can be used by any current client, but it only provides privacy when there are no on-path active attackers. 4.2. Out-of-band Key-pinned Privacy Profile The out-of-band key-pinned privacy profile can be used in @@ -460,22 +457,22 @@ The TEMPORARY assignment expires 2016-10-08. IANA is requested to make the assigmnent permanent upon publication of this document as an RFC. 7. Design Evolution [Note to RFC Editor: please do not remove this section as it may be useful to future Foo-over-TLS efforts] Earlier versions of this document proposed an upgrade-based approach - to establishing a TLS session. The client would signal its interest - in TLS by setting a "TLS OK" bit in the EDNS0 flags field. A server + to establish a TLS session. The client would signal its interest in + TLS by setting a "TLS OK" bit in the EDNS0 flags field. A server would signal its acceptance by responding with the TLS OK bit set. Since we assume the client doesn't want to reveal (leak) any information prior to securing the channel, we proposed the use of a "dummy query" that clients could send for this purpose. The proposed query name was STARTTLS, query type TXT, and query class CH. The TLS OK signaling approach has both advantages and disadvantages. One important advantage is that clients and servers could negotiate TLS. If the server is too busy, or doesn't want to provide TLS @@ -534,23 +531,23 @@ The Unbound recursive name server software added support for DNS- over-TLS in version 1.4.14. The unbound.conf configuration file has the following configuration directives: ssl-port, ssl-service-key, ssl-service-pem, ssl-upstream. See https://unbound.net/documentation/unbound.conf.html. 8.2. ldns Sinodun Internet Technologies has implemented DNS-over-TLS in the ldns library from NLnetLabs. This also gives DNS-over-TLS support to - the drill DNS client program. Patches available at https:// - portal.sinodun.com/stash/projects/TDNS/repos/dns-over-tls_patches/ - browse. + the drill DNS client program. Patches available at + https://portal.sinodun.com/stash/projects/TDNS/repos/dns-over- + tls_patches/browse. 8.3. digit The digit DNS client from USC/ISI supports DNS-over-TLS. Source code available at http://www.isi.edu/ant/software/tdns/index.html. 8.4. getdns The getdns API implementation supports DNS-over-TLS. Source code available at https://getdnsapi.net. @@ -644,106 +641,137 @@ Directorate under agreement number FA8750-12-2-0344, and contract number D08PC75599. 12. References 12.1. Normative References [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security - (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, - May 2015. + (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May + 2015. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ - RFC2119, March 1997, + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security - (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ - RFC5246, August 2008, + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code - Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, - January 2014, . + Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January + 2014, . [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning - Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, - April 2015, . + Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April + 2015, . [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, . 12.2. Informative References + [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, . + + [dnscrypt-website] + Denis, F., "DNSCrypt", 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, . + + [draft-ietf-tls-falsestart] + Moeller, B., Langley, A., and N. Modadugu, "Transport + Layer Security (TLS) False Start", draft-ietf-tls- + falsestart-01 (work in progress), November 2015, + . + [I-D.confidentialdns] - Wijngaards, W., "Confidential DNS", - draft-wijngaards-dnsop-confidentialdns-03 (work in - progress), March 2015, . [I-D.edns-tcp-keepalive] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The - edns-tcp-keepalive EDNS0 Option", - draft-ietf-dnsop-edns-tcp-keepalive-02 (work in progress), - July 2015, . [I-D.edns0-padding] - Mayrhofer, A., "The EDNS(0) Padding Option", - draft-mayrhofer-edns0-padding-01 (work in progress), - August 2015, . [I-D.ipseca] Osterweil, E., Wiley, G., Okubo, T., Lavu, R., and A. Mohaisen, "Opportunistic Encryption with DANE Semantics and IPsec: IPSECA", draft-osterweil-dane-ipsec-03 (work in - progress), July 2015, - . - [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ - RFC2818, May 2000, + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, + DOI 10.17487/RFC2818, May 2000, . [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, . [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, DOI 10.17487/RFC3646, December 2003, . @@ -754,73 +782,39 @@ . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) - Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, - August 2012, . + Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August + 2012, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an - Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, - May 2014, . + Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May + 2014, . [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, . [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, . [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, . - - [dnscrypt-website] - Denis, F., "DNSCrypt", 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, . - - [draft-ietf-tls-falsestart] - Moeller, B., Langley, A., and N. Modadugu, "Transport - Layer Security (TLS) False Start", - draft-ietf-tls-falsestart-01 (work in progress), - November 2015, - . - [tdns] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A., and N. Somaiya, "T-DNS: Connection-Oriented DNS to Improve Privacy and Security", Technical report ISI-TR-688, February 2014, . Appendix A. Out-of-band Key-pinned Privacy Profile Example This section presents an example of how the out-of-band key-pinned privacy profile could work in practice based on a minimal pinset (two @@ -861,21 +855,21 @@ Authors' Addresses Zi Hu USC/Information Sciences Institute 4676 Admiralty Way, Suite 1133 Marina del Rey, CA 90292 United States Phone: +1 213 587 1057 - Email: zihu@usc.edu + Email: zihu@outlook.com Liang Zhu USC/Information Sciences Institute 4676 Admiralty Way, Suite 1133 Marina del Rey, CA 90292 United States Phone: +1 310 448 8323 Email: liangzhu@usc.edu