< draft-ietf-dprive-start-tls-for-dns-00.txt   draft-ietf-dprive-start-tls-for-dns-01.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: November 6, 2015 USC/Information Sciences Expires: January 6, 2016 USC/Information Sciences
Institute Institute
A. Mankin A. Mankin
D. Wessels D. Wessels
Verisign Labs Verisign Labs
P. Hoffman P. Hoffman
VPN Consortium ICANN
May 5, 2015 July 5, 2015
TLS for DNS: Initiation and Performance Considerations TLS for DNS: Initiation and Performance Considerations
draft-ietf-dprive-start-tls-for-dns-00 draft-ietf-dprive-start-tls-for-dns-01
Abstract Abstract
This document offers an approach to initiating TLS for DNS: use of a This document offers an approach to initiating TLS for DNS: use of a
dedicated DNS-over-TLS port, and fallback to a mechanism for dedicated DNS-over-TLS port, and fallback to a mechanism for
upgrading a DNS-over-TCP connection over the standard port (TCP/53) upgrading a DNS-over-TCP connection over the standard port (TCP/53)
to a DNS-over-TLS connection. Encryption provided by TLS eliminates to a DNS-over-TLS connection. Encryption provided by TLS eliminates
opportunities for eavesdropping on DNS queries in the network, such opportunities for eavesdropping on DNS queries in the network, such
as discussed in RFC 7258. In addition it specifies two usage as discussed in RFC 7258. In addition it specifies two usage
profiles for DNS-over-TLS. Finally, it provides advice on profiles for DNS-over-TLS. Finally, it provides advice on
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 November 6, 2015. This Internet-Draft will expire on January 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4
2. Protocol Changes . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Use by DNS Clients . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Port-Based DNS-over-TLS for Clients . . . . . . . . . 5
2.1.2. Sending Queries for Upgrade-Based DNS-over-TLS . . . . 5
2.1.3. Receiving Responses for Upgrade-Based DNS-over-TLS . . 5
2.1.4. Use by DNS Servers . . . . . . . . . . . . . . . . . . 6
2.1.5. Established Sessions . . . . . . . . . . . . . . . . . 7
2.2. Downgrade Attacks and Middleboxes . . . . . . . . . . . . 8
3. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 9
3.2. Pre-Deployed Profile . . . . . . . . . . . . . . . . . . . 9
4. Performance Considerations . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 11
6.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
Today, nearly all DNS queries ([RFC1034] and [RFC1035]) are sent Today, nearly all DNS queries ([RFC1034] and [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 ongoing efforts are beginning to identify privacy concerns about and ongoing efforts are beginning to identify privacy concerns about
DNS ([I-D.ietf-dprive-problem-statement]). DNS ([I-D.ietf-dprive-problem-statement]).
Prior work has addressed some aspects of DNS security, but until Prior work has addressed some aspects of DNS security, but until
skipping to change at page 3, line 39 skipping to change at page 4, line 26
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].
2. Protocol Changes 2. Protocol Changes
The only changes required for port-based DNS-over-TLS are those The only changes required for port-based DNS-over-TLS are those
optimizing TCP and TLS performance discussed in the following. The optimizing TCP and TLS performance discussed in the following. The
DNS protocol itself is unchanged. DNS protocol itself is unchanged.
DISCUSSION: Draft authors seek input from the working group regarding
the need for both port- and upgrade-based approaches. Removing the
upgrade-based technique would simplify this document and
implementations. However, there may perhaps be situations where the
upgrade-based technique works (over port 53) that a port-based
technique would not work (i.e., due to aggressive port blocking by
firewalls).
Clients and servers negotiate upgrade-based DNS-over-TLS by setting a Clients and servers negotiate upgrade-based DNS-over-TLS by setting a
bit in the Flags field of the EDNS0 [RFC6891] OPT meta-RR. The "TLS bit in the Flags field of the EDNS0 [RFC6891] OPT meta-RR. The "TLS
OK" (TO) bit is defined as the second bit of the third and fourth OK" (TO) bit is defined as the second bit of the third and fourth
bytes of the "extended RCODE and flags" portion of the EDNS0 OPT bytes of the "extended RCODE and flags" portion of the EDNS0 OPT
meta-RR, immediately adjacent to the "DNSSEC OK" (DO) bit [RFC4033]: meta-RR, immediately adjacent to the "DNSSEC OK" (DO) bit [RFC4033]:
+0 (MSB) +1 (LSB) +0 (MSB) +1 (LSB)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | EXTENDED-RCODE | VERSION | 0: | EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
skipping to change at page 4, line 28 skipping to change at page 5, line 28
fall back to STARTTLS use, or to choose some other order of attempts fall back to STARTTLS use, or to choose some other order of attempts
and fallbacks. and fallbacks.
2.1.2. Sending Queries for Upgrade-Based DNS-over-TLS 2.1.2. Sending Queries for Upgrade-Based DNS-over-TLS
Setting the TO bit in queries sent using UDP transport has no Setting the TO bit in queries sent using UDP transport has no
protocol meaning. However, the client MAY set the TO bit when using protocol meaning. However, the client MAY set the TO bit when using
UDP transport. The server MUST ignore the TO bit when receiving UDP UDP transport. The server MUST ignore the TO bit when receiving UDP
transport. transport.
DISCUSSION: community advice is sought on this. The advantage of
allowing a client to send UDP on TO is that servers can collect
information on deployment (as happened with the DO bit). The
disadvantage is that a meaningless bit (TO over UDP) might cause
confusion, and some middleboxes might not pass a UDP query with the
TO bit set.
DNS clients set the TO bit in the initial query sent to a server DNS clients set the TO bit in the initial query sent to a server
using TCP transport to signal their desire that the TCP connection be using TCP transport to signal their desire that the TCP connection be
upgraded to TLS. DNS clients SHOULD NOT set the TO bit on queries upgraded to TLS. DNS clients SHOULD NOT set the TO bit on queries
when using TLS transport because doing so has no meaning in this when using TLS transport because doing so has no meaning in this
protocol. protocol.
Since the motivation for upgrade-based DNS-over-TLS is to preserve Since the motivation for upgrade-based DNS-over-TLS is to preserve
privacy, DNS clients SHOULD use an initial (unprotected) query that privacy, DNS clients SHOULD use an initial (unprotected) query that
reveals no private information in the initial TO=1 query to a server. reveals no private information in the initial TO=1 query to a server.
To provide a standard "dummy" query, it is RECOMMENDED to send the To provide a standard "dummy" query, it is RECOMMENDED to send the
skipping to change at page 5, line 13 skipping to change at page 6, line 6
queries over the same TCP connection. queries over the same TCP connection.
2.1.3. Receiving Responses for Upgrade-Based DNS-over-TLS 2.1.3. Receiving Responses for Upgrade-Based DNS-over-TLS
A DNS client that receives a response using UDP transport that has A DNS client that receives a response using UDP transport that has
the TO bit set handles that response as usual. It MAY record the the TO bit set handles that response as usual. It MAY record the
server's support for DNS-over-TLS and use that information as part of server's support for DNS-over-TLS and use that information as part of
its server selection algorithm in the case where multiple servers are its server selection algorithm in the case where multiple servers are
available to service a particular query. available to service a particular query.
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 MAY utilize the existing TCP connection for subsequent
(unencrypted) 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 a
reasonable period (such as one hour per server).
A DNS client that has sent the TO bit using TCP transport and A DNS client that has sent the TO bit using TCP transport and
receives a response to its initial query that has the TO bit set MUST receives a response to its initial query that has the TO bit set MUST
immediately initiate a TLS handshake using the procedure described in immediately initiate a TLS handshake using the procedure described in
[RFC5246]. (Note that this document does not yet deal with what [RFC5246]. If the TLS handshake does not succeed, the client MUST
happens when the TLS handshake does not succeed.) close the connection and treat the server as described above for
future queries.
DISCUSSION: are there any cases in which a DNS client that sent TO on
DNS-over-TCP and receives TO in the initial response from the server
would not initiate the TLS handshake? Is there any reason for this
to be SHOULD rather than MUST?
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).
2.1.4. Use by DNS Servers 2.1.4. Use by DNS Servers
A DNS server that supports DNS-over-TLS SHOULD support port-based A DNS server that supports DNS-over-TLS SHOULD support port-based
DNS-over-TLS, and SHOULD support upgrade-based DNS-over-TLS. DNS-over-TLS, and SHOULD support upgrade-based DNS-over-TLS.
2.1.4.1. Receiving Queries for Upgrade-Based DNS-over-TLS 2.1.4.1. Receiving Queries for Upgrade-Based DNS-over-TLS
A DNS server receiving a query over UDP with the TO bit ignores that A DNS server receiving a query over UDP with the TO bit ignores that
bit. A DNS server receiving a query over an existing TLS connection bit. A DNS server receiving a query over an existing TLS connection
skipping to change at page 6, line 27 skipping to change at page 7, line 14
respond with RCODE=0 and a TXT RR in the Answer section. Contents of respond with RCODE=0 and a TXT RR in the Answer section. Contents of
the TXT RR are strictly informative (for humans) and MUST NOT be the TXT RR are strictly informative (for humans) and MUST NOT be
interpreted by the client software. Recommended TXT RDATA values are interpreted by the client software. Recommended TXT RDATA values are
"STARTTLS" or "NO_TLS". "STARTTLS" or "NO_TLS".
2.1.5. Established Sessions 2.1.5. Established Sessions
After TLS negotiation completes, the connection will be encrypted and After TLS negotiation completes, the connection will be encrypted and
is now protected from eavesdropping and normal DNS queries SHOULD is now protected from eavesdropping and normal DNS queries SHOULD
take place, following DNS-over-TCP framing ([RFC1035], section take place, following DNS-over-TCP framing ([RFC1035], section
4.2.2). 4.2.2). For reasons of efficiency, DNS clients and servers SHOULD
transmit the two-octet length field, and the message described by
that length field, in a single TCP segment ([I-D.ietf-dnsop-5966bis],
section 8).
It is expected that multiple DNS queries will be made over the same For DNS clients that use library functions such as "gethostbyname()",
TLS connection instead of tearing down the TLS connection after each current implementations are known to open and close UDP connections
response. A user of DNS-over-TLS SHOULD follow best practices for each DNS call. To avoid many TCP connections, each with a single
DNS-over-TCP, as described in [I-D.ietf-dnsop-5966bis]. (For DNS query, clients SHOULD reuse a single TCP connection to the recursive
clients that use library functions such as "gethostbyname()", current resolver. Alternatively they may prefer to use UDP to a DNS-over-TLS
clients may open and close UDP connections each DNS call. We enabled caching resolver on the same machine that then uses a system-
recommend they reuse a single TCP connection to the recursive wide TCP connection to the recursive resolver.
resolver or use UDP to a caching resolver that uses a system-wide TCP
connection to the recursive resolver.)
Both clients and servers SHOULD follow existing DNS-over-TCP timeout In order to amortize TCP and TLS connetion setup costs, clients and
rules, which are often implementation- and situation-dependent. In servers SHOULD NOT immediately close a connection after each
the absence of any other advice, the RECOMMENDED timeout values are response. Instead, clients and servers SHOULD reuse existing
30 seconds for recursive name servers, 60 seconds for clients of connections for subsequent queries as long as they have sufficient
recursive name servers, 10 seconds for authoritative name servers, resources. In some cases, this means that clients and servers may
and 20 seconds for clients of authoritative name servers. Current need to keep idle connections open for some amount of time.
work in this area may assist DNS-over-TLS clients and servers select
useful timeout values [draft-wouters-edns-tcp-keepalive] [tdns].
As with current DNS-over-TCP, DNS servers MAY close the connection at Proper management of established and idle connections is important to
any time (e.g., due to resource constraints). As with current DNS- the healthy operation of a DNS server. An implementor of DNS-over-
over-TCP, clients MUST handle abrupt closes and be prepared to TLS SHOULD follow best practices for DNS-over-TCP, as described in
reestablish connections and/or retry queries. DNS servers SHOULD use [I-D.ietf-dnsop-5966bis]. Failure to do so may lead to resource
the TLS close-notify request to shift TCP TIME-WAIT state to the exhaustion and denial-of-service.
clients. Additional requirements and guidance for optimizing DNS-
over-TCP are provided by [RFC5966], [I-D.ietf-dnsop-5966bis]. As
discussed in [I-D.ietf-dnsop-5966bis], TCP Fast Open [RFC7413] is of
benefit.
DNS servers SHOULD enable fast TLS session resumption [RFC5077] to Whereas client and server implementations from the [RFC1035] era are
avoid keeping per-client session state. known to have poor TCP connection management, this document
stipulates that successful negotation of TLS indicates the
willingness of both parties to keep idle DNS connections open,
independent of timeouts or other recommendations for DNS-over-TCP
without TLS. In other words, software implemeting this protocol is
assumed to support idle, persistent connections and to have good
connection management.
This document does not make specific recommendations for timeout
values on idle connections. Clients and servers should reuse and/or
close connections depending on the level of available resources.
Timeouts may be longer during periods of low activity and shorter
during periods of high activity. Current work in this area may also
assist DNS-over-TLS clients and servers select useful timeout values
[draft-wouters-edns-tcp-keepalive] [tdns].
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 (e.g., 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 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]. As discussed in
[I-D.ietf-dnsop-5966bis], TCP Fast Open [RFC7413] is of benefit.
2.2. Downgrade Attacks and Middleboxes 2.2. Downgrade Attacks and Middleboxes
Middleboxes [RFC3234] may be present in some networks and have been Middleboxes [RFC3234] may be present in some networks and have been
known to interfere with normal DNS resolution and create problems for known to interfere with normal DNS resolution and create problems for
DNS-over-TLS. Remarkably, downgrade attacks can affect plaintext DNS-over-TLS. Remarkably, downgrade attacks can affect plaintext
protocols that utilize "STARTTLS" signaling in a similar way. A DNS protocols that utilize "STARTTLS" signaling in a similar way. A DNS
client attempting upgrade-based DNS-over-TLS through a middlebox, or client attempting upgrade-based DNS-over-TLS through a middlebox, or
in the presence of a downgrade attack, could have one of the in the presence of a downgrade attack, could have one of the
following outcomes. (These outcomes are similar to those discussed following outcomes. (These outcomes are similar to those discussed
in prior RFCs, such as [RFC3207].) in prior RFCs, such as [RFC3207].)
o The DNS client sends a TO=1 query and receives a TO=0 response. o The DNS client sends a TO=1 query and receives a TO=0 response.
In this case there is no upgrade to TLS and DNS resolution occurs In this case there is no upgrade to TLS and DNS resolution occurs
normally, without encryption. normally, without encryption.
o The DNS client sends a TO=1 query and receives a TO=1 response, o The DNS client sends a TO=1 query and receives a TO=1 response,
but the middlebox does not understand the TLS negotiation and does but the middlebox does not understand the TLS negotiation and does
not allow those packets to pass through. Clients SHOULD retry DNS not allow the TLS handshake packets to pass. Clients SHOULD retry
without TO set if negotiation fails, and then retry with TLS after DNS without TO set if negotiation fails, and then retry with TLS
a reasonable period (see Section 2.1.3). after a reasonable period (see Section 2.1.3).
o The DNS client sends a TO=1 query but receives no response at all. o The DNS client sends a TO=1 query but receives no response at all.
The middlebox might be silently dropping the query due to the The middlebox might be silently dropping the query due to the
presence of the TO bit, when it should, in fact, ignore and pass presence of the TO bit, when it should, in fact, ignore and pass
through unknown flag bits [RFC6891]. The client SHOULD fall back through unknown flag bits [RFC6891]. The client SHOULD fall back
to normal (unencrypted) DNS for a reasonable period (as discussed to normal (unencrypted) DNS for a reasonable period (as discussed
in Section 2.1.3). in Section 2.1.3).
In general, clients that attempt TLS and fail can either fall back on In general, clients that attempt TLS and fail can either fall back on
unencrypted DNS, or wait and retry later, depending on their privacy unencrypted DNS, or wait and retry later, depending on their privacy
skipping to change at page 8, line 18 skipping to change at page 9, line 26
[RFC7435] one desires privacy when possible, but does not require it. [RFC7435] one desires privacy when possible, but does not require it.
With opportunistic privacy, a client might acquire a recursive DNS With opportunistic privacy, a client might acquire a recursive DNS
resolver from an untrusted source (such as DHCP while roaming), it resolver from an untrusted source (such as DHCP while roaming), it
might or might not validate the TLS certificate, and it might not use might or might not validate the TLS certificate, and it might not use
a dummy value for the initial query. These choices maximize a dummy value for the initial query. These choices maximize
availability and performance, but they are vulnerable to on-path availability and performance, but they are vulnerable to on-path
attacks. attacks.
Opportunistic privacy can be used by any current client, but it only Opportunistic privacy can be used by any current client, but it only
provides privacy when there are no on-path attackers. provides privacy when there are no on-path active attackers.
3.2. Pre-Deployed Profile 3.2. Pre-Deployed Profile
For pre-deployed privacy, the DNS client has one or more trusted For pre-deployed privacy, the DNS client has one or more trusted
recursive DNS providers. This profile provides strong privacy recursive DNS providers. This profile provides strong privacy
guarantees to the user. guarantees to the user.
With pre-deployed privacy, a client retains a copy of the TLS With pre-deployed privacy, a client retains a copy of the TLS
certificate and IP address of each provider. The client will only certificate (and/or other authentication credentials as appropriate)
use one of those DNS providers. Because it has a pre-deployed TLS and IP address of each provider. The client will only use one of
certificate, it may detect person-in-the-middle and downgrade those DNS providers. Because it has a pre-deployed TLS certificate,
attacks. it may detect person-in-the-middle and downgrade attacks.
With pre-deployed privacy, the DNS client MUST signal to the user With pre-deployed privacy, the DNS client MUST signal to the user
when none of the designated DNS servers are available, and MUST NOT when none of the designated DNS servers are available, and MUST NOT
provide DNS service until one of the designated DNS servers becomes provide DNS service until one of the designated DNS servers becomes
available. available.
The designated DNS provider may be temporarily unavailable when The designated DNS provider may be temporarily unavailable when
configuring a network. For example, for clients on networks that configuring a network. For example, for clients on networks that
require authentication through web-based login, such authentication require authentication through web-based login, such authentication
may require DNS interception and spoofing. Techniques such as those may require DNS interception and spoofing. Techniques such as those
used by DNSSEC-trigger MAY be used during network configuration, with used by DNSSEC-trigger [dnssec-trigger] MAY be used during network
the intent to transition to the designated DNS provider after configuration, with the intent to transition to the designated DNS
authentication. The user MUST be alerted that the DNS is not private provider after authentication. The user MUST be alerted that the DNS
during such bootstrap. is not private during such bootstrap.
Methods for pre-deployment of the designated DNS provider are outside Methods for pre-deployment of the designated DNS provider are outside
the scope of this document. In corporate settings, such information the scope of this document. In corporate settings, such information
may be provided at system installation. Use of multiple public DNS may be provided at system installation. Use of multiple public DNS
providers suggests that end users are able to configure DNS by hand. providers suggests that end users are able to configure DNS by hand.
4. Performance Considerations 4. Performance Considerations
DNS-over-TLS incurs additional latency at session startup. It also DNS-over-TLS incurs additional latency at session startup. It also
requires additional state (memory) and increased processing (CPU). requires additional state (memory) and increased processing (CPU).
1. Latency: Compared to UDP, DNS-over-TCP requires an additional 1. Latency: Compared to UDP, DNS-over-TCP requires an additional
round-trip-time (RTT) of latency to establish the connection. round-trip-time (RTT) of latency to establish the connection.
The TLS handshake adds another two RTTs of latency. Clients and The TLS handshake adds another two RTTs of latency. Clients and
servers should support connection keepalive (reuse) and out-of- servers should support connection keepalive (reuse) and out-of-
order processing to amortize connection setup costs. Moreover, order processing to amortize connection setup costs. Moreover,
TLS connection resumption can further reduce the setup delay. TLS connection resumption can further reduce the setup delay.
DNS servers SHOULD enable fast TLS session resumption [RFC5077]
to avoid keeping per-client session state. TLS False Start
[draft-tls-falsestart] can also lead to a latency reduction in
certain situations.
2. State: The use of connection-oriented TCP requires keeping 2. State: The use of connection-oriented TCP requires keeping
additional state in both kernels and applications. TLS has additional state in both kernels and applications. TLS has
marginal increases in state over TCP alone. The state marginal increases in state over TCP alone. The state
requirements are of particular concerns on servers with many requirements are of particular concerns on servers with many
clients. Smaller timeout values will reduce the number of clients. Smaller timeout values will reduce the number of
concurrent connections, and servers can preemptively close concurrent connections, and servers can preemptively close
connections when resources limits are exceeded. connections when resources limits are exceeded.
3. Processing: Use of TLS encryption algorithms results in slightly 3. Processing: Use of TLS encryption algorithms results in slightly
higher CPU usage. Servers can choose to refuse new DNS-over-TCP higher CPU usage. Servers can choose to refuse new DNS-over-TCP
clients if processing limits are exceeded. clients if processing limits are exceeded.
4. Number of connections: To minimize state on DNS servers and 4. Number of connections: To minimize state on DNS servers and
connection startup time, clients SHOULD minimize creation of new connection startup time, clients SHOULD minimize creation of new
TCP connections. Use of a local DNS forwarder allows a single TCP connections. Use of a local DNS request aggregator (a
active DNS-over-TLS connection allows a single active TCP particular type of forwarder) allows a single active DNS-over-TLS
connection for DNS per client computer. Additional guidance can connection from any given client computer to its server.
be found in [I-D.ietf-dnsop-5966bis]. Additional guidance can be found in [I-D.ietf-dnsop-5966bis].
A full performance evaluation is outside the scope of this A full performance evaluation is outside the scope of this
specification. A more detailed analysis of the performance specification. A more detailed analysis of the performance
implications of DNS-over-TLS (and DNS-over-TCP) is discussed in a implications of DNS-over-TLS (and DNS-over-TCP) is discussed in a
technical report [tdns] and [I-D.ietf-dnsop-5966bis]. technical report [tdns] and [I-D.ietf-dnsop-5966bis].
5. IANA Considerations 5. IANA Considerations
This document defines a new bit ("TO") in the Flags field of the This document defines a new bit ("TO") in the Flags field of the
EDNS0 OPT meta-RR. At the time of approval of this draft in the EDNS0 OPT meta-RR. At the time of approval of this draft in the
skipping to change at page 10, line 14 skipping to change at page 11, line 26
populated by expert review [RFC6335], and such a review will be populated by expert review [RFC6335], and such a review will be
requested if this document progresses. requested if this document progresses.
Service Name DNS-over-TLS Service Name DNS-over-TLS
Transport Protocol(s) TCP Transport Protocol(s) TCP
Assignee IESG Assignee IESG
Contact TBD Contact TBD
Description DNS query-response protocol run over TLS Description DNS query-response protocol run over TLS
Reference This document Reference This document
6. Security Considerations 6. Implementation Status
The goal of this proposal is to address the security risks that arise [Note to RFC Editor: please remove this section and reference to RFC
because DNS queries may be eavesdropped upon, as described above. 6982 prior to publication.]
There are a number of residual risks that may impact this goal.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in RFC 6982.
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to RFC 6982, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
6.1. Unbound
The Unbound recursive name server software added support for port-
based 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.
Sinodun Internet Technologies has implemented upgrade-based DNS-over-
TLS in Unbound-1.5.1 (patch available at https://portal.sinodun.com/
stash/projects/TDNS/repos/dns-over-tls_patches/browse) for both stub-
to-recursive and recursive-to-authoritative.
6.2. ldns
Sinodun Internet Technologies has implemented both upgrade-based and
port-based 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.
6.3. digit
The digit DNS client from USC/ISI supports both port- and upgrade-
based DNS-over-TLS. Source code available at
http://www.isi.edu/ant/software/tdns/index.html.
6.4. getdns
The getdns API implementation supports both port- and upgrade-based
DNS-over-TLS. Upgrade-based operation requires linking getdns with a
patched version of libunbound. Source code available at
https://getdnsapi.net.
7. Security Considerations
Use of TLS for DNS addresses is designed to address the privacy risks
arise because DNS queries may be eavesdropped upon. It does not
address other security issues in DNS, and there are a number of
residual risks that may affect its success at protecting privacy:
1. There are known attacks on TLS, such as person-in-the-middle and 1. There are known attacks on TLS, such as person-in-the-middle and
protocol downgrade. These are general attacks on TLS and not protocol downgrade. These are general attacks on TLS and not
specific to DNS-over-TLS; please refer to the TLS RFCs for specific to DNS-over-TLS; please refer to the TLS RFCs for
discussion of these security issues. discussion of these security issues.
2. Any protocol interactions prior to the TLS handshake are 2. Any protocol interactions prior to the TLS handshake are
performed in the clear and can be modified by a man-in-the-middle performed in the clear and can be modified by a man-in-the-middle
attacker. For this reason, clients MAY discard cached attacker. For this reason, clients MAY discard cached
information about server capabilities advertised prior to the information about server capabilities advertised prior to the
skipping to change at page 10, line 40 skipping to change at page 13, line 20
3. As with other uses of STARTTLS-upgrade to TLS, the mechanism 3. As with other uses of STARTTLS-upgrade to TLS, the mechanism
specified here is susceptible to downgrade attacks, where a specified here is susceptible to downgrade attacks, where a
person-in-the-middle prevents a successful TLS upgrade. Keeping person-in-the-middle prevents a successful TLS upgrade. Keeping
track of servers known to support TLS (i.e., "pinning") enables track of servers known to support TLS (i.e., "pinning") enables
clients to detect downgrade attacks. For servers with no clients to detect downgrade attacks. For servers with no
connection history, clients may choose to refuse non-TLS DNS, or connection history, clients may choose to refuse non-TLS DNS, or
they may continue without TLS, depending on their privacy they may continue without TLS, depending on their privacy
requirements. requirements.
4. This document does not propose new ideas for certificate 4. This document does not propose new ideas to provide resistance to
known traffic analysis techniques. Even with encrypted messages,
a well-positioned party may be able to glean certain details from
an analysis of message timings and sizes.
5. This document does not propose new ideas for certificate
authentication for TLS in the context of DNS. Several external authentication for TLS in the context of DNS. Several external
methods are possible, although each has weaknesses. The current methods are possible, although each has weaknesses. The current
Certificate Authority infrastructure [RFC5280] is used by HTTP/ Certificate Authority infrastructure [RFC5280] is used by HTTP/
TLS [RFC2818]. With many trusted CAs, this approach has TLS [RFC2818]. With many trusted CAs, this approach has
recognized weaknesses [CA_Compromise]. Some work is underway to recognized weaknesses [CA_Compromise]. Some work is underway to
partially address these concerns (for example, with certificate partially address these concerns (for example, with certificate
pinning [certificate_pinning], but more work is needed. DANE pinning [certificate_pinning], but more work is needed. DANE
[RFC6698] provides mechanisms to root certificate trust with [RFC6698] provides mechanisms to root certificate trust with
DNSSEC. That use here must be carefully evaluated to address DNSSEC. That use here must be carefully evaluated to address
potential issues in trust recursion. For stub-to-recursive potential issues in trust recursion. For stub-to-recursive
resolver use, certificate authentication is sometimes either easy resolver use, certificate authentication is sometimes either easy
or nearly impossible. If the recursive resolver is manually or nearly impossible. If the recursive resolver is manually
configured, its certificate can be authenticated when it is configured, its certificate can be authenticated when it is
configured. If the recursive resolver is automatically configured. If the recursive resolver is automatically
configured (such as with DHCP [RFC2131]), it could use DHCP configured (such as with DHCP [RFC2131]), it could use DHCP
authentication mechanisms [RFC3118]). authentication mechanisms [RFC3118]).
Ongoing discussion and development of opportunistic TLS (connections Ongoing discussion and development of opportunistic TLS (connections
without CA validation, [RFC7435]) may be relevant to DNS-over-TLS. without CA validation, [RFC7435]) may be relevant to DNS-over-TLS.
7. Acknowledgments 8. Acknowledgments
The authors would like to thank Stephane Bortzmeyer, Brian Haberman, The authors would like to thank Stephane Bortzmeyer, Brian Haberman,
Kim-Minh Kaplan, Bill Manning, George Michaelson, Eric Osterweil, Kim-Minh Kaplan, Bill Manning, George Michaelson, Eric Osterweil,
Glen Wiley, John Dickinson, and Sara Dickinson for reviewing this Glen Wiley, John Dickinson, Sara Dickinson, and Daniel Kahn Gillmor
Internet-draft, and Nikita Somaiya for early work on this idea. for reviewing this Internet-draft, and Nikita Somaiya for early work
on this idea.
Work by Zi Hu, Liang Zhu, and John Heidemann in this paper is Work by Zi Hu, Liang Zhu, and John Heidemann in this paper is
partially sponsored by the U.S. Dept. of Homeland Security (DHS) partially sponsored by the U.S. Dept. of Homeland Security (DHS)
Science and Technology Directorate, HSARPA, Cyber Security Division, Science and Technology Directorate, HSARPA, Cyber Security Division,
BAA 11-01-RIKA and Air Force Research Laboratory, Information BAA 11-01-RIKA and Air Force Research Laboratory, Information
Directorate under agreement number FA8750-12-2-0344, and contract Directorate under agreement number FA8750-12-2-0344, and contract
number D08PC75599. number D08PC75599.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 12, line 14 skipping to change at page 14, line 45
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, August 2011. RFC 6335, August 2011.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
8.2. Informative References 9.2. Informative References
[CA_Compromise] [CA_Compromise]
Infosec Island Admin, "CA Compromise", January 2012, <http Infosec Island Admin, "CA Compromise", January 2012, <http
://www.infosecisland.com/blogview/ ://www.infosecisland.com/blogview/
19782-Web-Authentication-A-Broken-Trust-with-No-Easy- 19782-Web-Authentication-A-Broken-Trust-with-No-Easy-
Fix.html>. Fix.html>.
[I-D.ietf-dnsop-5966bis] [I-D.ietf-dnsop-5966bis]
Dickinson, J., Bellis, R., Mankin, A., and D. Wessels, Dickinson, J., Bellis, R., Mankin, A., and D. Wessels,
"DNS Transport over TCP - Implementation Requirements", "DNS Transport over TCP - Implementation Requirements",
draft-ietf-dnsop-5966bis-00 (work in progress), draft-ietf-dnsop-5966bis-01 (work in progress),
December 2014. December 2014.
[I-D.ietf-dprive-problem-statement] [I-D.ietf-dprive-problem-statement]
Bortzmeyer, S., "DNS privacy considerations", Bortzmeyer, S., "DNS privacy considerations",
draft-ietf-dprive-problem-statement-01 (work in progress), draft-ietf-dprive-problem-statement-06 (work in progress),
October 2014. October 2014.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996. STD 53, RFC 1939, May 1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2595, June 1999. RFC 2595, June 1999.
skipping to change at page 13, line 38 skipping to change at page 16, line 23
Fast Open", RFC 7413, December 2014. Fast Open", RFC 7413, December 2014.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, December 2014. Most of the Time", RFC 7435, December 2014.
[certificate_pinning] [certificate_pinning]
OWASP, "Certificate and Public Key Pinning", 2014, <https: OWASP, "Certificate and Public Key Pinning", 2014, <https:
//www.owasp.org/index.php/ //www.owasp.org/index.php/
Certificate_and_Public_Key_Pinning>. Certificate_and_Public_Key_Pinning>.
[dnssec-trigger]
NLnet Labs, "Dnssec-Trigger", May 2014,
<https://www.nlnetlabs.nl/projects/dnssec-trigger/>.
[draft-dempsky-dnscurve] [draft-dempsky-dnscurve]
Dempsky, M., "DNSCurve", draft-dempsky-dnscurve-01 (work Dempsky, M., "DNSCurve", draft-dempsky-dnscurve-01 (work
in progress), August 2010, in progress), August 2010,
<http://tools.ietf.org/html/draft-dempsky-dnscurve-01>. <http://tools.ietf.org/html/draft-dempsky-dnscurve-01>.
[draft-osterweil-dane-ipsec] [draft-osterweil-dane-ipsec]
Osterweil, E., Wiley, G., Mitchell, D., and A. Newton, Osterweil, E., Wiley, G., Mitchell, D., and A. Newton,
"Opportunistic Encryption with DANE Semantics and IPsec: "Opportunistic Encryption with DANE Semantics and IPsec:
IPSECA", draft-osterweil-dane-ipsec-00 (work in progress), IPSECA", draft-osterweil-dane-ipsec-00 (work in progress),
February 2014, February 2014,
<http://tools.ietf.org/html/ <http://tools.ietf.org/html/
draft-osterweil-dane-ipsec-00>. draft-osterweil-dane-ipsec-00>.
[draft-tls-falsestart]
Moeller, B. and A. Langley, "Transport Layer Security
(TLS) False Start", draft-bmoeller-tls-falsestart-01 (work
in progress), November 2014, <http://tools.ietf.org/html/
draft-bmoeller-tls-falsestart-01>.
[draft-wijngaards-confidentialdns] [draft-wijngaards-confidentialdns]
Wijngaards, W., "Confidential DNS", Wijngaards, W., "Confidential DNS",
draft-wijngaards-dnsop-confidentialdns-03 (work in draft-wijngaards-dnsop-confidentialdns-03 (work in
progress), November 2013, <http://tools.ietf.org/html/ progress), November 2013, <http://tools.ietf.org/html/
draft-wijngaards-dnsop-confidentialdns-03>. draft-wijngaards-dnsop-confidentialdns-03>.
[draft-wouters-edns-tcp-keepalive] [draft-wouters-edns-tcp-keepalive]
Wouters, P. and J. Abley, "The edns-tcp-keepalive EDNS0 Wouters, P. and J. Abley, "The edns-tcp-keepalive EDNS0
Option", draft-wouters-edns-tcp-keepalive-00 (work in Option", draft-wouters-edns-tcp-keepalive-00 (work in
progress), October 2013, <http://tools.ietf.org/html/ progress), October 2013, <http://tools.ietf.org/html/
skipping to change at page 15, line 4 skipping to change at page 17, line 37
Email: zihu@usc.edu Email: zihu@usc.edu
Liang Zhu Liang Zhu
USC/Information Sciences Institute USC/Information Sciences Institute
4676 Admiralty Way, Suite 1133 4676 Admiralty Way, Suite 1133
Marina del Rey, CA 90292 Marina del Rey, CA 90292
USA USA
Phone: +1 310 448-8323 Phone: +1 310 448-8323
Email: liangzhu@usc.edu Email: liangzhu@usc.edu
John Heidemann John Heidemann
USC/Information Sciences Institute USC/Information Sciences Institute
4676 Admiralty Way, Suite 1001 4676 Admiralty Way, Suite 1001
Marina del Rey, CA 90292 Marina del Rey, CA 90292
USA USA
Phone: +1 310 822-1511 Phone: +1 310 822-1511
Email: johnh@isi.edu Email: johnh@isi.edu
Allison Mankin Allison Mankin
Verisign Labs Verisign Labs
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
Phone: +1 703 948-3200 Phone: +1 703 948-3200
Email: amankin@verisign.com Email: amankin@verisign.com
Duane Wessels Duane Wessels
Verisign Labs Verisign Labs
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
Phone: +1 703 948-3200 Phone: +1 703 948-3200
Email: dwessels@verisign.com Email: dwessels@verisign.com
Paul Hoffman Paul Hoffman
VPN Consortium ICANN
Email: paul.hoffman@vpnc.org Email: paul.hoffman@icann.org
 End of changes. 36 change blocks. 
87 lines changed or deleted 216 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/