draft-ietf-dprive-dns-over-tls-00.txt		draft-ietf-dprive-dns-over-tls-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: March 21, 2016 USC/Information Sciences		Expires: April 13, 2016 USC/Information Sciences
	Institute		Institute
	A. Mankin		A. Mankin
	D. Wessels		D. Wessels
	Verisign Labs		Verisign Labs
	P. Hoffman		P. Hoffman
	ICANN		ICANN
	September 18, 2015		October 11, 2015
	DNS over TLS: Initiation and Performance Considerations		DNS over TLS: Initiation and Performance Considerations
	draft-ietf-dprive-dns-over-tls-00		draft-ietf-dprive-dns-over-tls-01
	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
	on DNS queries in the network, such as discussed in RFC 7258. In		and on-path tampering with DNS queries in the network, such as
	addition, this document specifies two usage profiles for DNS-over-TLS		discussed in RFC 7258. In addition, this document specifies two
	and provides advice on performance considerations to minimize		usage profiles for DNS-over-TLS and provides advice on performance
	overhead from using TCP and TLS with DNS.		considerations to minimize overhead from using TCP and TLS with DNS.
	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
	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 March 21, 2016.		This Internet-Draft will expire on April 13, 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
	skipping to change at page 2, line 37		skipping to change at page 2, line 37
	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 . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 7		4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 7
	4.2. Pre-Deployed Profile . . . . . . . . . . . . . . . . . . . 7		4.2. Pre-Deployed Profile . . . . . . . . . . . . . . . . . . . 7
	5. Performance Considerations . . . . . . . . . . . . . . . . . . 8		5. Performance Considerations . . . . . . . . . . . . . . . . . . 8
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . . 9		7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . . 9
	8. Implementation Status . . . . . . . . . . . . . . . . . . . . 10		8. Implementation Status . . . . . . . . . . . . . . . . . . . . 10
	8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 10		8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 11		8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . . 11		8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 11		9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 12		10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 12
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 12		12.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	12.2. Informative References . . . . . . . . . . . . . . . . . . 13		12.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
	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 24		skipping to change at page 4, line 24
	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 SHOULD listen for and accept
	TCP connections on a designated port TBD identified in Section 6.		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 TBD on the server.		server SHOULD establish a TCP connection to port 853 on the server.
	Upon successful establishment of the TCP connection, client and		Upon successful establishment of the TCP connection, client and
	server SHOULD immediately initiate a TLS handshake using the		server SHOULD immediately initiate a TLS handshake using the
	procedure described in [RFC5246].		procedure described in [RFC5246].
	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 a pre-deployed privacy profile MAY be more aggressive about		following a pre-deployed privacy profile MAY be more aggressive about
	retrying DNS-over-TLS connection failures.		retrying DNS-over-TLS connection failures.
	skipping to change at page 5, line 20		skipping to change at page 5, line 20
	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		transmit the two-octet length field, and the message described by
	that length field, in a single TCP segment ([I-D.ietf-dnsop-5966bis],		that length field, to the TCP layer at the same time (e.g., in a
	Section 8).		single "write" system call) to make it more likely that all the data
			will be transmitted in a single TCP segment
			([I-D.ietf-dnsop-5966bis], 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 and port number.		responses to outstanding queries using the ID field, query name,
	Failure by clients to properly match responses to outstanding queries		type, and class. Failure by clients to properly match responses to
	can have serious consequences for interoperability		outstanding queries can have serious consequences for
	([I-D.ietf-dnsop-5966bis], Section 7).		interoperability ([I-D.ietf-dnsop-5966bis], Section 7).
	3.4. Connection Reuse, Close and Reestablishment		3.4. Connection Reuse, Close and Reestablishment
	For DNS clients that use library functions such as "gethostbyname()",		For DNS clients that use library functions such as "getaddrinfo()"
	current implementations are known to open and close TCP connections		and "gethostbyname()", current implementations are known to open and
	each DNS call. To avoid excess TCP connections, each with a single		close TCP connections each DNS call. To avoid excess TCP
	query, clients SHOULD reuse a single TCP connection to the recursive		connections, each with a single query, clients SHOULD reuse a single
	resolver. Alternatively they may prefer to use UDP to a DNS-over-TLS		TCP connection to the recursive resolver. Alternatively they may
	enabled caching resolver on the same machine that then uses a system-		prefer to use UDP to a DNS-over-TLS enabled caching resolver on the
	wide TCP connection to the recursive resolver.		same machine that then uses a system-wide TCP connection to the
			recursive resolver.
	In order to amortize TCP and TLS connection setup costs, clients and		In order to amortize TCP and TLS connection setup costs, clients and
	servers SHOULD NOT immediately close a connection after each		servers SHOULD NOT immediately close a connection after each
	response. Instead, clients and servers SHOULD reuse existing		response. Instead, clients and servers SHOULD reuse existing
	connections for subsequent queries as long as they have sufficient		connections for subsequent queries as long as they have sufficient
	resources. In some cases, this means that clients and servers may		resources. In some cases, this means that clients and servers may
	need to keep idle connections open for some amount of time.		need to keep idle connections open for some amount of time.
	Proper management of established and idle connections is important to		Proper management of established and idle connections is important to
	the healthy operation of a DNS server. An implementor of DNS-over-		the healthy operation of a DNS server. An implementor of DNS-over-
	skipping to change at page 7, line 50		skipping to change at page 7, line 50
	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 rely on DNS interception and spoofing. Techniques such as those		may rely on DNS interception and spoofing. Techniques such as those
	used by DNSSEC-trigger [dnssec-trigger] MAY be used during network		used by DNSSEC-trigger [dnssec-trigger] MAY be used during network
	configuration, with the intent to transition to the designated DNS		configuration, with the intent to transition to the designated DNS
	provider after authentication. The user MUST be alerted that the DNS		provider after authentication. The user MUST be alerted that the DNS
	is not private 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, for instance within the		may be provided at system installation.
	authenticated DHCP exchange [RFC3118].
	5. Performance Considerations		5. 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 a TCP connection.		round-trip-time (RTT) of latency to establish a TCP connection.
	TCP Fast Open [RFC7413] can eliminate that RTT when information		TCP Fast Open [RFC7413] can eliminate that RTT when information
	exists from prior connections. The TLS handshake adds another		exists from prior connections. The TLS handshake adds another
	skipping to change at page 8, line 51		skipping to change at page 8, line 51
	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		implications of DNS-over-TLS (and DNS-over-TCP) is discussed in
	[tdns] and [I-D.ietf-dnsop-5966bis].		[tdns] and [I-D.ietf-dnsop-5966bis].
	6. IANA Considerations		6. IANA Considerations
	IANA is requested to add the following value to the "Service Name and		IANA is requested to add the following value to the "Service Name and
	Transport Protocol Port Number Registry" registry in the System		Transport Protocol Port Number Registry" registry in the System
	Range. The registry for that range requires IETF Review or IESG		Range. The registry for that range requires IETF Review or IESG
	Approval [RFC6335] and such a review has been requested using the		Approval [RFC6335] and such a review was requested using the Early
	Early Allocation process [RFC7120] for the well-known TCP port in		Allocation process [RFC7120] for the well-known TCP port in this
	this document.		document.
	We further recommend that IANA reserve the same port number over UDP		We further recommend that IANA reserve the same port number over UDP
	for the proposed DNS-over-DTLS protocol [draft-ietf-dprive-dnsodtls].		for the proposed DNS-over-DTLS protocol [draft-ietf-dprive-dnsodtls].
	Service Name domain-s		IANA responded to the early allocation request with the following
	Transport Protocol(s) TCP/UDP		TEMPORARY assignment:
	Assignee IESG
	Contact TBD		Service Name domain-s
	Description DNS query-response protocol run over TLS		Port Number 853
	Reference This document		Transport Protocol(s) TCP/UDP
			Assignee IETF DPRIVE Chairs
			Contact Paul Hoffman
			Description DNS query-response protocol run over TLS/DTLS
			Reference This document
			The TEMPORARY assignment expires 2016-10-08. IANA is requested to
			make the assigmnent permanent upon publication of this document as an
			RFC.
	7. Design Evolution		7. Design Evolution
	[Note to RFC Editor: please do not remove this section prior to		[Note to RFC Editor: please do not remove this section prior to
	publication as it may be useful to future Foo-over-TLS efforts]		publication as it may be useful to future Foo-over-TLS efforts]
	Earlier versions of this document proposed an upgrade-based approach		Earlier versions of this document proposed an upgrade-based approach
	to establishing a TLS session. The client would signal its interest		to establishing a TLS session. The client would signal its interest
	in TLS by setting a "TLS OK" bit in the EDNS0 flags field. A server		in TLS by setting a "TLS OK" bit in the EDNS0 flags field. A server
	would signal its acceptance by responding with the TLS OK bit set.		would signal its acceptance by responding with the TLS OK bit set.
	skipping to change at page 11, line 30		skipping to change at page 11, line 38
	arise out of the ability to eavesdrop on DNS messages. It does not		arise out of the ability to eavesdrop on DNS messages. It does not
	address other security issues in DNS, and there are a number of		address other security issues in DNS, and there are a number of
	residual risks that may affect its success at protecting privacy:		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. Clients and servers MUST		discussion of these security issues. Clients and servers MUST
	adhere to the TLS implementation recommendations and security		adhere to the TLS implementation recommendations and security
	considerations of [RFC7525]. DNS clients keeping track of		considerations of [RFC7525]. DNS clients keeping track of
	servers known to support TLS (i.e., "pinning") enables clients to		servers known to support TLS enables clients to detect downgrade
	detect downgrade attacks. For servers with no connection history		attacks. For servers with no connection history and no apparent
	and no apparent support for TLS, clients depending on their		support for TLS, clients depending on their Privacy Profile and
	Privacy Profile and privacy requirements may choose to (a) try		privacy requirements may choose to (a) try another server when
	another server when available, (b) continue without TLS, or (c)		available, (b) continue without TLS, or (c) refuse to forward the
	refuse to forward the query.		query.
	2. Middleboxes [RFC3234] are be present in some networks and have		2. Middleboxes [RFC3234] are present in some networks and have been
	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 protocol interactions prior to the TLS handshake are		3. Any DNS protocol interactions prior to the TLS handshake that are
	performed in the clear and can be modified by a person-in-the-		performed in the clear can be modified by a person-in-the-middle
	middle attacker. For this reason, clients MAY discard cached		attacker. For example, unencrypted queries and responses might
	information about server capabilities advertised prior to the		take place over port 53 between a client and server prior to TLS.
	start of the TLS handshake.		For this reason, clients MAY discard cached information about
			server capabilities advertised prior to the start of the TLS
			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 14, line 31		skipping to change at page 14, line 39
	Mohaisen, "Opportunistic Encryption with DANE Semantics		Mohaisen, "Opportunistic Encryption with DANE Semantics
	and IPsec: IPSECA", draft-osterweil-dane-ipsec-03 (work in		and IPsec: IPSECA", draft-osterweil-dane-ipsec-03 (work in
	progress), July 2015,		progress), July 2015,
	<http://tools.ietf.org/html/		<http://tools.ietf.org/html/
	draft-osterweil-dane-ipsec-03>.		draft-osterweil-dane-ipsec-03>.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/
	RFC2818, May 2000,		RFC2818, May 2000,
	<http://www.rfc-editor.org/info/rfc2818>.		<http://www.rfc-editor.org/info/rfc2818>.
	[RFC3118] Droms, R. and W. Arbaugh., Ed., "Authentication for DHCP
	Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001,
	<http://www.rfc-editor.org/info/rfc3118>.
	[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and		[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
	Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,		Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
	<http://www.rfc-editor.org/info/rfc3234>.		<http://www.rfc-editor.org/info/rfc3234>.
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements",		Rose, "DNS Security Introduction and Requirements",
	RFC 4033, DOI 10.17487/RFC4033, March 2005,		RFC 4033, DOI 10.17487/RFC4033, March 2005,
	<http://www.rfc-editor.org/info/rfc4033>.		<http://www.rfc-editor.org/info/rfc4033>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
End of changes. 19 change blocks.
	55 lines changed or deleted		63 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/