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/