draft-ietf-dprive-dns-over-tls-03.txt   draft-ietf-dprive-dns-over-tls-04.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 7, 2016 USC/Information Sciences Expires: July 24, 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 4, 2016 January 21, 2016
DNS over TLS: Initiation and Performance Considerations DNS over TLS: Initiation and Performance Considerations
draft-ietf-dprive-dns-over-tls-03 draft-ietf-dprive-dns-over-tls-04
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 RFC 7258. 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.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 7, 2016. This Internet-Draft will expire on July 24, 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Establishing and Managing DNS-over-TLS Sessions . . . . . . . 4 3. Establishing and Managing DNS-over-TLS Sessions . . . . . . . 4
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 4 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 4
3.2. TLS Handshake and Authentication . . . . . . . . . . . . . 4 3.2. TLS Handshake and Authentication . . . . . . . . . . . . . 5
3.3. Transmitting and Receiving Messages . . . . . . . . . . . 5 3.3. Transmitting and Receiving Messages . . . . . . . . . . . 5
3.4. Connection Reuse, Close and Reestablishment . . . . . . . 5 3.4. Connection Reuse, Close and Reestablishment . . . . . . . 5
4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 7 4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 7
4.2. Out-of-band Key-pinned Privacy Profile . . . . . . . . . . 7 4.2. Out-of-band Key-pinned Privacy Profile . . . . . . . . . . 7
5. Performance Considerations . . . . . . . . . . . . . . . . . . 8 5. Performance Considerations . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . . 9 7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . . 10
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 11
8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 12 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 13
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Out-of-band Key-pinned Privacy Profile Example . . . 16 Appendix A. Out-of-band Key-pinned Privacy Profile Example . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
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 4, line 4 skipping to change at page 4, line 4
successor. successor.
The protocol described here works for any DNS client to server The protocol described here works for any DNS client to server
communication using DNS-over-TCP. That is, it may be used for communication using DNS-over-TCP. That is, it may be used for
queries and responses between stub clients and recursive servers as queries and responses between stub clients and recursive servers as
well as between recursive clients and authoritative servers. well as between recursive clients and authoritative servers.
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 [TBD] will further describe additional future document based on [dgr-dprive-dtls-and-tls-profiles] will
privacy profiles for DNS over both TLS and DTLS. [Note to RFC further describe additional privacy profiles for DNS over both TLS
Editor: informative reference for that document will be forthcoming] 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,
essentially, "STARTTLS for DNS". To simplify the protocol, this essentially, "STARTTLS for DNS". To simplify the protocol, this
document now only uses a well-known port to specify TLS use, omitting document now only uses a well-known port to specify TLS use, omitting
the upgrade approach. The upgrade approach no longer appears in this the upgrade approach. The upgrade approach no longer appears in this
document, which now focuses exclusively on the use of a well-known document, which now focuses exclusively on the use of a well-known
port for DNS-over-TLS. port for DNS-over-TLS.
2. Reserved Words 2. Reserved Words
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 SHOULD 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.
DNS clients desiring privacy from DNS-over-TLS from a particular DNS clients desiring privacy from DNS-over-TLS from a particular
server SHOULD establish a TCP connection to port 853 on the server. server MUST establish a TCP connection which SHOULD be to port 853 on
Upon successful establishment of the TCP connection, client and the server. This is a SHOULD rather than a MUST because a server MAY
server SHOULD immediately initiate a TLS handshake using the also offer DNS-over-TLS service on another port by agreement with its
client. Such an additional port MUST NOT be port 53, but MAY be from
the FCFS port range. The first data exchange on this TCP connection
MUST be the client and server initiating a TLS handshake using the
procedure described in [RFC5246]. procedure described in [RFC5246].
DNS clients and servers MUST NOT use port 853 to transport clear text
DNS messages. DNS clients MUST NOT send and DNS servers MUST NOT
respond to clear text DNS messages on any port used for DNS-over-TLS
(including, for example, after a failed TLS handshake). There are
significant security issues in mixing protected and unprotected data
and for this reason TCP connections on a port designated by a given
server for DNS-over-TLS are reserved purely for encrypted
communications.
DNS clients SHOULD remember server IP addresses that don't support DNS 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 MAY be more
aggressive about retrying DNS-over-TLS connection failures. 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
skipping to change at page 5, line 17 skipping to change at page 5, line 29
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. At this point, normal DNS is now protected from eavesdropping. At this point, normal DNS
queries SHOULD take place. queries SHOULD take place.
3.3. Transmitting and Receiving Messages 3.3. Transmitting and Receiving Messages
All messages (requests and responses) in the established TLS session All messages (requests and responses) in the established TLS session
MUST use the two-octet length field described in Section 4.2.2 of MUST use the two-octet length field described in Section 4.2.2 of
[RFC1035]. For reasons of efficiency, DNS clients and servers SHOULD [RFC1035]. For reasons of efficiency, DNS clients and servers SHOULD
transmit the two-octet length field, and the message described by pass the two-octet length field, and the message described by that
that length field, to the TCP layer at the same time (e.g., in a length field, to the TCP layer at the same time (e.g., in a single
single "write" system call) to make it more likely that all the data "write" system call) to make it more likely that all the data will be
will be transmitted in a single TCP segment transmitted in a single TCP segment ([I-D.ietf-dnsop-5966bis],
([I-D.ietf-dnsop-5966bis], Section 8). Section 8).
In order to minimize latency, clients SHOULD pipeline multiple In order to minimize latency, clients SHOULD pipeline multiple
queries over a TLS session. When a DNS client sends multiple queries queries over a TLS session. When a DNS client sends multiple queries
to a server, it should not wait for an outstanding reply before to a server, it should not wait for an outstanding reply before
sending the next query ([I-D.ietf-dnsop-5966bis], Section 6.2.1.1). sending the next query ([I-D.ietf-dnsop-5966bis], Section 6.2.1.1).
Since pipelined responses can arrive out-of-order, clients MUST match Since pipelined responses can arrive out-of-order, clients MUST match
responses to outstanding queries using the ID field, query name, responses to outstanding queries using the ID field, query name,
type, and class. Failure by clients to properly match responses to type, and class. Failure by clients to properly match responses to
outstanding queries can have serious consequences for outstanding queries can have serious consequences for
skipping to change at page 6, line 37 skipping to change at page 6, line 48
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
benefit. DNS servers SHOULD enable fast TLS session resumption benefit. Underlining the requirement for sending only encrypted DNS
[RFC5077] and this SHOULD be used when reestablishing connections. data on a DNS-over-TLS port (Section 3.2), when using TCP Fast Open
the client and server MUST immediately initiate or resume a TLS
handshake (clear text DNS MUST NOT be exchanged). DNS servers SHOULD
enable fast TLS session resumption [RFC5077] and this SHOULD be used
when reestablishing connections.
When closing a connection, DNS servers SHOULD use the TLS close- When closing a connection, DNS servers SHOULD use the TLS close-
notify request to shift TCP TIME-WAIT state to the clients. notify request to shift TCP TIME-WAIT state to the clients.
Additional requirements and guidance for optimizing DNS-over-TCP are Additional requirements and guidance for optimizing DNS-over-TCP are
provided by [RFC5966], [I-D.ietf-dnsop-5966bis]. provided by [RFC5966], [I-D.ietf-dnsop-5966bis].
4. Usage Profiles 4. Usage Profiles
This protocol provides flexibility to accommodate several different This protocol provides flexibility to accommodate several different
use cases. This document defines two usage profiles: (1) use cases. This document defines two usage profiles: (1)
skipping to change at page 7, line 4 skipping to change at page 7, line 19
Additional requirements and guidance for optimizing DNS-over-TCP are Additional requirements and guidance for optimizing DNS-over-TCP are
provided by [RFC5966], [I-D.ietf-dnsop-5966bis]. provided by [RFC5966], [I-D.ietf-dnsop-5966bis].
4. Usage Profiles 4. Usage Profiles
This protocol provides flexibility to accommodate several different This protocol provides flexibility to accommodate several different
use cases. This document defines two usage profiles: (1) use cases. This document defines two usage profiles: (1)
opportunistic privacy, and (2) out-of-band key-pinned authentication opportunistic privacy, and (2) out-of-band key-pinned authentication
that can be used to obtain stronger privacy guarantees if the client that can be used to obtain stronger privacy guarantees if the client
has a trusted relationship with a DNS server supporting TLS. has a trusted relationship with a DNS server supporting TLS.
Additional methods of authentication will be defined in a forthcoming Additional methods of authentication will be defined in a forthcoming
draft [TBD]. draft [dgr-dprive-dtls-and-tls-profiles].
4.1. Opportunistic Privacy Profile 4.1. Opportunistic Privacy Profile
For opportunistic privacy, analogous to SMTP opportunistic encryption For opportunistic privacy, analogous to SMTP opportunistic encryption
[RFC7435] one does not require privacy, but one desires privacy when [RFC7435] one does not require privacy, but one desires privacy when
possible. possible.
With opportunistic privacy, a client might learn of a TLS-enabled With opportunistic privacy, a client might learn of a TLS-enabled
recursive DNS resolver from an untrusted source (such as DHCP while recursive DNS resolver from an untrusted source (such as DHCP while
roaming), it might or might not validate the resolver. These choices roaming), it might or might not validate the resolver. These choices
skipping to change at page 12, line 25 skipping to change at page 12, line 43
another server when available, (b) continue without TLS, or (c) another server when available, (b) continue without TLS, or (c)
refuse to forward the query. refuse to forward the query.
2. Middleboxes [RFC3234] are present in some networks and have been 2. Middleboxes [RFC3234] are present in some networks and have been
known to interfere with normal DNS resolution. Use of a known to interfere with normal DNS resolution. Use of a
designated port for DNS-over-TLS should avoid such interference. designated port for DNS-over-TLS should avoid such interference.
In general, clients that attempt TLS and fail can either fall In general, clients that attempt TLS and fail can either fall
back on unencrypted DNS, or wait and retry later, depending on back on unencrypted DNS, or wait and retry later, depending on
their Privacy Profile and privacy requirements. their Privacy Profile and privacy requirements.
3. Any DNS protocol interactions prior to the TLS handshake that are 3. Any DNS protocol interactions performed in the clear can be
performed in the clear can be modified by a person-in-the-middle modified by a person-in-the-middle attacker. For example,
attacker. For example, unencrypted queries and responses might unencrypted queries and responses might take place over port 53
take place over port 53 between a client and server prior to TLS. between a client and server. For this reason, clients MAY
For this reason, clients MAY discard cached information about discard cached information about server capabilities advertised
server capabilities advertised prior to the start of the TLS in clear text.
handshake.
4. This document does not itself specify ideas to resist known 4. This document does not itself specify ideas to resist known
traffic analysis or side channel leaks. Even with encrypted traffic analysis or side channel leaks. Even with encrypted
messages, a well-positioned party may be able to glean certain messages, a well-positioned party may be able to glean certain
details from an analysis of message timings and sizes. Clients details from an analysis of message timings and sizes. Clients
and servers may consider the use of a padding method to address and servers may consider the use of a padding method to address
privacy leakage due to message sizes [I-D.edns0-padding] privacy leakage due to message sizes [I-D.edns0-padding]
10. Contributing Authors 10. Contributing Authors
skipping to change at page 16, line 26 skipping to change at page 16, line 38
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015, DOI 10.17487/RFC7626, August 2015,
<http://www.rfc-editor.org/info/rfc7626>. <http://www.rfc-editor.org/info/rfc7626>.
[dempsky-dnscurve] [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>.
[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, <https://
tools.ietf.org/html/
draft-dgr-dprive-dtls-and-tls-profiles-00>.
[dnssec-trigger] [dnssec-trigger]
NLnet Labs, "Dnssec-Trigger", May 2014, NLnet Labs, "Dnssec-Trigger", May 2014,
<https://www.nlnetlabs.nl/projects/dnssec-trigger/>. <https://www.nlnetlabs.nl/projects/dnssec-trigger/>.
[draft-ietf-dprive-dnsodtls] [draft-ietf-dprive-dnsodtls]
Reddy, T., Wing, D., and P. Patil, "DNS over DTLS Reddy, T., Wing, D., and P. Patil, "DNS over DTLS
(DNSoD)", draft-ietf-dprive-dnsodtls-01 (work in (DNSoD)", draft-ietf-dprive-dnsodtls-01 (work in
progress), June 2015, <https://tools.ietf.org/html/ progress), June 2015, <https://tools.ietf.org/html/
draft-ietf-dprive-dnsodtls-01>. draft-ietf-dprive-dnsodtls-01>.
 End of changes. 19 change blocks. 
40 lines changed or deleted 62 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/