draft-ietf-dprive-dns-over-tls-05.txt | draft-ietf-dprive-dns-over-tls-06.txt | |||
---|---|---|---|---|
Network Working Group Z. Hu | Network Working Group Z. Hu | |||
Internet-Draft L. Zhu | Internet-Draft L. Zhu | |||
Intended status: Standards Track J. Heidemann | Intended status: Standards Track J. Heidemann | |||
Expires: July 25, 2016 USC/Information Sciences | Expires: August 25, 2016 USC/Information Sciences | |||
Institute | Institute | |||
A. Mankin | A. Mankin | |||
D. Wessels | D. Wessels | |||
Verisign Labs | Verisign Labs | |||
P. Hoffman | P. Hoffman | |||
ICANN | ICANN | |||
January 22, 2016 | February 22, 2016 | |||
DNS over TLS: Initiation and Performance Considerations | Specification for DNS over TLS | |||
draft-ietf-dprive-dns-over-tls-05 | draft-ietf-dprive-dns-over-tls-06 | |||
Abstract | Abstract | |||
This document describes the use of TLS to provide privacy for DNS. | This document describes the use of TLS to provide privacy for DNS. | |||
Encryption provided by TLS eliminates opportunities for eavesdropping | Encryption provided by TLS eliminates opportunities for eavesdropping | |||
and on-path tampering with DNS queries in the network, such as | and on-path tampering with DNS queries in the network, such as | |||
discussed in RFC 7258. In addition, this document specifies two | discussed in [RFC7258]. In addition, this document specifies two | |||
usage profiles for DNS-over-TLS and provides advice on performance | usage profiles for DNS-over-TLS and provides advice on performance | |||
considerations to minimize overhead from using TCP and TLS with DNS. | 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 | Note: this document was formerly named | |||
draft-ietf-dprive-start-tls-for-dns. Its name has been changed to | draft-ietf-dprive-start-tls-for-dns. Its name has been changed to | |||
better describe the mechanism now used. Please refer to working | better describe the mechanism now used. Please refer to working | |||
group archives under the former name for history and previous | group archives under the former name for history and previous | |||
discussion. [RFC Editor: please remove this paragraph prior to | discussion. [RFC Editor: please remove this paragraph prior to | |||
publication] | publication] | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
skipping to change at page 1, line 49 | skipping to change at page 2, line 7 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on July 25, 2016. | This Internet-Draft will expire on August 25, 2016. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3. Establishing and Managing DNS-over-TLS Sessions . . . . . . . 4 | 3. Establishing and Managing DNS-over-TLS Sessions . . . . . . . 5 | |||
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 4 | 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 5 | |||
3.2. TLS Handshake and Authentication . . . . . . . . . . . . . 5 | 3.2. TLS Handshake and Authentication . . . . . . . . . . . . . 6 | |||
3.3. Transmitting and Receiving Messages . . . . . . . . . . . 5 | 3.3. Transmitting and Receiving Messages . . . . . . . . . . . 6 | |||
3.4. Connection Reuse, Close and Reestablishment . . . . . . . 5 | 3.4. Connection Reuse, Close and Reestablishment . . . . . . . 7 | |||
4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . . 7 | 4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 7 | 4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 8 | |||
4.2. Out-of-band Key-pinned Privacy Profile . . . . . . . . . . 7 | 4.2. Out-of-band Key-pinned Privacy Profile . . . . . . . . . . 8 | |||
5. Performance Considerations . . . . . . . . . . . . . . . . . . 8 | 5. Performance Considerations . . . . . . . . . . . . . . . . . . 9 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . . 10 | 7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 | 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 | |||
8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | |||
10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 13 | 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 14 | |||
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 | 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 | 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . . 15 | 12.2. Informative References . . . . . . . . . . . . . . . . . . 16 | |||
Appendix A. Out-of-band Key-pinned Privacy Profile Example . . . 17 | Appendix A. Out-of-band Key-pinned Privacy Profile Example . . . 18 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
1. Introduction | 1. Introduction | |||
Today, nearly all DNS queries [RFC1034], [RFC1035] are sent | Today, nearly all DNS queries [RFC1034], [RFC1035] are sent | |||
unencrypted, which makes them vulnerable to eavesdropping by an | unencrypted, which makes them vulnerable to eavesdropping by an | |||
attacker that has access to the network channel, reducing the privacy | attacker that has access to the network channel, reducing the privacy | |||
of the querier. Recent news reports have elevated these concerns, | of the querier. Recent news reports have elevated these concerns, | |||
and recent IETF work has specified privacy considerations for DNS | and recent IETF work has specified privacy considerations for DNS | |||
[RFC7626]. | [RFC7626]. | |||
skipping to change at page 3, line 46 | skipping to change at page 4, line 46 | |||
Initiation of DNS-over-TLS is very straightforward. By establishing | Initiation of DNS-over-TLS is very straightforward. By establishing | |||
a connection over a well-known port, clients and servers expect and | a connection over a well-known port, clients and servers expect and | |||
agree to negotiate a TLS session to secure the channel. Deployment | agree to negotiate a TLS session to secure the channel. Deployment | |||
will be gradual. Not all servers will support DNS-over-TLS and the | will be gradual. Not all servers will support DNS-over-TLS and the | |||
well-known port might be blocked by some firewalls. Clients will be | well-known port might be blocked by some firewalls. Clients will be | |||
expected to keep track of servers that support TLS and those that | expected to keep track of servers that support TLS and those that | |||
don't. Clients and servers will adhere to the TLS implementation | don't. Clients and servers will adhere to the TLS implementation | |||
recommendations and security considerations of [RFC7525] or its | recommendations and security considerations of [RFC7525] or its | |||
successor. | successor. | |||
The protocol described here works for any DNS client to server | The protocol described here works for queries and responses between | |||
communication using DNS-over-TCP. That is, it may be used for | stub clients and recursive servers. It might work equally between | |||
queries and responses between stub clients and recursive servers as | recursive clients and authoritative servers, but this application of | |||
well as between recursive clients and authoritative servers. | the protocol is out of scope for the DNS PRIVate Exchange (DPRIVE) | |||
Working Group per its current charter. | ||||
This document describes two profiles in Section 4 providing different | This document describes two profiles in Section 4 providing different | |||
levels of assurance of privacy: an opportunistic privacy profile and | levels of assurance of privacy: an opportunistic privacy profile and | |||
an out-of-band key-pinned privacy profile. It is expected that a | an out-of-band key-pinned privacy profile. It is expected that a | |||
future document based on [dgr-dprive-dtls-and-tls-profiles] will | future document based on [dgr-dprive-dtls-and-tls-profiles] will | |||
further describe additional privacy profiles for DNS over both TLS | further describe additional privacy profiles for DNS over both TLS | |||
and DTLS. | and DTLS. | |||
An earlier version of this document described a technique for | An earlier version of this document described a technique for | |||
upgrading a DNS-over-TCP connection to a DNS-over-TLS session with, | upgrading a DNS-over-TCP connection to a DNS-over-TLS session with, | |||
skipping to change at page 4, line 28 | skipping to change at page 5, line 29 | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
3. Establishing and Managing DNS-over-TLS Sessions | 3. Establishing and Managing DNS-over-TLS Sessions | |||
3.1. Session Initiation | 3.1. Session Initiation | |||
A DNS server that supports DNS-over-TLS MUST listen for and accept | A DNS server that supports DNS-over-TLS MUST listen for and accept | |||
TCP connections on port 853. | 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. | ||||
DNS clients desiring privacy from DNS-over-TLS from a particular | DNS clients desiring privacy from DNS-over-TLS from a particular | |||
server MUST establish a TCP connection which SHOULD be to port 853 on | server MUST establish a TCP connection to port 853 on the server. By | |||
the server. This is a SHOULD rather than a MUST because a server MAY | mutual agreement with its server, the client MAY, instead, use a port | |||
also offer DNS-over-TLS service on another port by agreement with its | other than port 853 for DNS-over-TLS. Such an other port MUST NOT be | |||
client. Such an additional port MUST NOT be port 53, but MAY be from | port 53, but MAY be from the "first-come, first-served" port range. | |||
the FCFS port range. The first data exchange on this TCP connection | The first data exchange on this TCP connection MUST be the client and | |||
MUST be the client and server initiating a TLS handshake using the | server initiating a TLS handshake using the procedure described in | |||
procedure described in [RFC5246]. | [RFC5246]. | |||
DNS clients and servers MUST NOT use port 853 to transport clear text | 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 | 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 | respond to clear text DNS messages on any port used for DNS-over-TLS | |||
(including, for example, after a failed TLS handshake). There are | (including, for example, after a failed TLS handshake). There are | |||
significant security issues in mixing protected and unprotected data | significant security issues in mixing protected and unprotected data | |||
and for this reason TCP connections on a port designated by a given | and for this reason TCP connections on a port designated by a given | |||
server for DNS-over-TLS are reserved purely for encrypted | server for DNS-over-TLS are reserved purely for encrypted | |||
communications. | communications. | |||
DNS clients SHOULD remember server IP addresses that don't support | DNS clients SHOULD remember server IP addresses that don't support | |||
DNS-over-TLS, including timeouts, connection refusals, and TLS | DNS-over-TLS, including timeouts, connection refusals, and TLS | |||
handshake failures, and not request DNS-over-TLS from them for a | handshake failures, and not request DNS-over-TLS from them for a | |||
reasonable period (such as one hour per server). DNS clients | reasonable period (such as one hour per server). DNS clients | |||
following an out-of-band key-pinned privacy profile MAY be more | following an out-of-band key-pinned privacy profile (Section 4.2) MAY | |||
aggressive about retrying DNS-over-TLS connection failures. | be more aggressive about retrying DNS-over-TLS connection failures. | |||
3.2. TLS Handshake and Authentication | 3.2. TLS Handshake and Authentication | |||
Once the DNS client succeeds in connecting via TCP on the well-known | 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], | port for DNS-over-TLS, it proceeds with the TLS handshake [RFC5246], | |||
following the best practices specified in [RFC7525] or its successor. | following the best practices specified in [RFC7525] or its successor. | |||
The client will then authenticate the server, if required. This | The client will then authenticate the server, if required. This | |||
document does not propose new ideas for authentication. Depending on | 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 | |||
skipping to change at page 6, line 37 | skipping to change at page 7, line 43 | |||
independent of timeouts or other recommendations for DNS-over-TCP | independent of timeouts or other recommendations for DNS-over-TCP | |||
without TLS. In other words, software implementing this protocol is | without TLS. In other words, software implementing this protocol is | |||
assumed to support idle, persistent connections and be prepared to | assumed to support idle, persistent connections and be prepared to | |||
manage multiple, potentially long-lived TCP connections. | manage multiple, potentially long-lived TCP connections. | |||
This document does not make specific recommendations for timeout | This document does not make specific recommendations for timeout | |||
values on idle connections. Clients and servers should reuse and/or | values on idle connections. Clients and servers should reuse and/or | |||
close connections depending on the level of available resources. | close connections depending on the level of available resources. | |||
Timeouts may be longer during periods of low activity and shorter | Timeouts may be longer during periods of low activity and shorter | |||
during periods of high activity. Current work in this area may also | during periods of high activity. Current work in this area may also | |||
assist DNS-over-TLS clients and servers select useful timeout values | assist DNS-over-TLS clients and servers in selecting useful timeout | |||
[I-D.edns-tcp-keepalive] [tdns]. | values [I-D.edns-tcp-keepalive] [tdns]. | |||
Clients and servers that keep idle connections open MUST be robust to | Clients and servers that keep idle connections open MUST be robust to | |||
termination of idle connection by either party. As with current DNS- | termination of idle connection by either party. As with current DNS- | |||
over-TCP, DNS servers MAY close the connection at any time (perhaps | over-TCP, DNS servers MAY close the connection at any time (perhaps | |||
due to resource constraints). As with current DNS-over-TCP, clients | due to resource constraints). As with current DNS-over-TCP, clients | |||
MUST handle abrupt closes and be prepared to reestablish connections | MUST handle abrupt closes and be prepared to reestablish connections | |||
and/or retry queries. | and/or retry queries. | |||
When reestablishing a DNS-over-TCP connection that was terminated, as | When reestablishing a DNS-over-TCP connection that was terminated, as | |||
discussed in [I-D.ietf-dnsop-5966bis], TCP Fast Open [RFC7413] is of | discussed in [I-D.ietf-dnsop-5966bis], TCP Fast Open [RFC7413] is of | |||
End of changes. 12 change blocks. | ||||
48 lines changed or deleted | 54 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |