< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/