< draft-hzhwm-dprive-start-tls-for-dns-00.txt		draft-hzhwm-dprive-start-tls-for-dns-01.txt >
	Network Working Group Z. Hu		Network Working Group Z. Hu
	Internet-Draft L. Zhu		Internet-Draft L. Zhu
	Intended status: Standards Track J. Heidemann		Intended status: Standards Track J. Heidemann
	Expires: April 24, 2015 USC/Information Sciences		Expires: August 16, 2015 USC/Information Sciences
	Institute		Institute
	A. Mankin		A. Mankin
	D. Wessels		D. Wessels
	Verisign Labs		Verisign Labs
	October 21, 2014		P. Hoffman
			VPN Consortium
			February 12, 2015
	TLS for DNS: Initiation and Performance Considerations		TLS for DNS: Initiation and Performance Considerations
	draft-hzhwm-dprive-start-tls-for-dns-00		draft-hzhwm-dprive-start-tls-for-dns-01
	Abstract		Abstract
	This memo offers one approach to initiating TLS for DNS over the		This document offers an approach to initiating TLS for DNS: use of a
	standard port (TCP/53). Encryption provided by TLS eliminates		dedicated DNS-over-TLS port, and fallback to a mechanism for
	opportunities for eavesdropping on DNS queries in the network. In		upgrading a DNS-over-TCP connection over the standard port (TCP/53)
	addition, and most importantly, the document discusses performance		to a DNS-over-TLS connection. Encryption provided by TLS eliminates
	considerations to minimize overheads from using TCP and TLS with DNS.		opportunities for eavesdropping on DNS queries in the network, such
	These considerations may apply to other approaches for DNS over TCP		as discussed in RFC 7285. In addition, this document discusses
	and TLS using other ports.		performance considerations to minimize overheads from using TCP and
			TLS with DNS, pertaining to both approaches.
	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
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 April 24, 2015.		This Internet-Draft will expire on August 16, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	1. Introduction		1. Introduction
	Today, nearly all DNS queries ([RFC1034] and [RFC1035]) are sent		Today, nearly all DNS queries ([RFC1034] and [RFC1035]) are sent
	unencrypted, which makes them vulnerable to eavesdropping by an		unencrypted, which makes them vulnerable to eavesdropping by an
	attacker that has access to the network channel, reducing the privacy		attacker that has access to the network channel, reducing the privacy
	of the querier. Recent news reports have elevated these concerns,		of the querier. Recent news reports have elevated these concerns,
	and ongoing efforts are beginning to identify privacy concerns about		and ongoing efforts are beginning to identify privacy concerns about
	DNS ([draft-bortzmeyer-dnsop-dns-privacy]).		DNS ([I-D.ietf-dprive-problem-statement]).
	Prior work has addressed some aspects of DNS security, but none		Prior work has addressed some aspects of DNS security, but there has
	addresses privacy between a DNS client and server using standard		been little work till recently on privacy between a DNS client and
	protocols. DNS Security Extensions (DNSSEC, [RFC4033]) provide		server. DNS Security Extensions (DNSSEC, [RFC4033]) provide
	_response integrity_ by defining mechanisms to cryptographically sign		_response integrity_ by defining mechanisms to cryptographically sign
	zones, allowing end-users (or their first-hop resolver) to verify		zones, allowing end-users (or their first-hop resolver) to verify
	replies are correct. DNSSEC however does nothing to protect request		replies are correct. DNSSEC by intention does not protect request
	or response privacy. Traditionally, either privacy was not		and response privacy. Traditionally, either privacy was not
	considered a requirement for DNS traffic, or it was assumed that		considered a requirement for DNS traffic, or it was assumed that
	network traffic was sufficiently private, however these perceptions		network traffic was sufficiently private, however these perceptions
	are evolving due to recent events.		are evolving due to recent events [RFC7285].
	More recently, DNSCurve [draft-dempsky-dnscurve] defines a method to		DNSCurve [draft-dempsky-dnscurve] defines a method to add
	provide link-level confidentiality and integrity between DNS clients		confidentiality to the link between DNS clients and servers; however,
	and servers. However, it does so with a new cryptographic protocol		it does so with a new cryptographic protocol and does not take
	and so does not take advantage of TLS. ConfidentialDNS		advantage of an existing standard protocol such as TLS.
	[draft-wijngaards-confidentialdns] and IPSECA		ConfidentialDNS [draft-wijngaards-confidentialdns] and IPSECA
	[draft-osterweil-dane-ipsec] use opportunistic encryption to provide		[draft-osterweil-dane-ipsec] use opportunistic encryption to offer
	privacy for DNS queries and responses. However, it is unclear how a		privacy for DNS queries and responses. Finally, others have
	client can locate an RR specific to its first-hop resolver. Finally,		suggested DNS-over-TLS. Unbound DNS software [unbound] includes a
	others have suggested DNS-over-TLS. Recent work suggests DNS-over-		DNS-over-TLS implementation. The present document goes beyond past
	TLS ([draft-bortzmeyer-dnsop-privacy-sol]), and the Unbound DNS		DNS-over-TLS discussions by providing two modes of initiation for
	software [unbound] includes a DNS-over-TLS implementation. However,		DNS-over-TLS, use of a well-known port, TBD, and use of a negotiation
	neither defines methods to negotiate TLS use over an existing		mechanism in an established connection.
	connection; unbound instead requires DNS-over-TLS to run on a
	different port.
	The mechanism described in this document enables DNS clients and		This document describes a protocol that is resilient in environments
	servers to upgrade an existing DNS-over-TCP connection to a DNS-over-		affected by differing middle box concerns. The port-based initiation
	TLS connection. It is analogous to STARTTLS [RFC2595] used in SMTP		of TLS is very straightforward, but might be blocked by firewalls or
	[RFC3207], IMAP [RFC3501] and POP [RFC1939].		be unwelcome to some DNS client or server implementations. If port-
			based initiation of TLS fails, there is an upgrade-based negotiation
			mechanism to enable DNS clients and servers to upgrade an existing
			DNS-over-TCP connection to a DNS-over-TLS connection, analogous to
			upgrade mechanisms in other uses of TLS, such as STARTTLS [RFC2595]
			used in SMTP [RFC3207], IMAP [RFC3501] and POP [RFC1939], to name
			just a few of many. But like those, the upgrade-based approach has
			middle box considerations, particularly downgrade attacks, as
			discussed in Section 2.4.
	This document defines only the protocol extensions necessary to		The protocol described here works for any DNS client to server
	support TLS negotiation. It does not describe how DNS clients might		communication using DNS-over-TCP. In particular, the same protocol
	validate server certificates or specify trusted certificate		can be used for stub-recursive and recursive-authoritative
	authorities. Solutions for certificate authentication are outside		communications. We expect implementation initially between stubs and
	the scope of this document.		recursives.
			In specifying TLS negotiation for DNS, this document defines only the
			protocol extensions that are needed. It does not describe how DNS
			clients might validate server certificates or specify trusted
			certificate authorities. Solutions for certificate authentication
			are currently outside the scope of this document.
	1.1. Reserved Words		1.1. 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].
	2. Protocol Changes		2. Protocol Changes
	Clients and servers indicate their support for, and desire to use,		The only changes required for port-based DNS-over-TLS are those
	DNS-over-TLS by setting a bit in the Flags field of the EDNS0		optimizing TCP and TLS performance discussed in the following. The
	[RFC6891] OPT meta-RR. The "TLS OK" (TO) bit is defined as the		DNS protocol itself is unchanged.
	second bit of the third and fourth bytes of the "extended RCODE and
	flags" portion of the EDNS0 OPT meta-RR, immediately adjacent to the		Clients and servers negotiate upgrade-based DNS-over-TLS by setting a
	"DNSSEC OK" (DO) bit [RFC4033]:		bit in the Flags field of the EDNS0 [RFC6891] OPT meta-RR. The "TLS
			OK" (TO) bit is defined as the second bit of the third and fourth
			bytes of the "extended RCODE and flags" portion of the EDNS0 OPT
			meta-RR, immediately adjacent to the "DNSSEC OK" (DO) bit [RFC4033]:
	+0 (MSB) +1 (LSB)		+0 (MSB) +1 (LSB)
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	0: | EXTENDED-RCODE | VERSION |		0: | EXTENDED-RCODE | VERSION |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	2: |DO|TO| Z |		2: |DO|TO| Z |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	2.1. Use by DNS Clients		2.1. Use by DNS Clients
	2.1.1. Sending Queries		DNS clients first try port-based DNS-over-TLS. If that connection
			fails, they try upgrade-based DNS-over-TLS.
	DNS clients MAY set the TO bit in queries sent using UDP transport to		2.1.1. Port-Based DNS-over-TLS for Clients
	signal their general ability to support DNS-over-TLS. Clients which
	get no response to UDP TO=1 queries SHOULD retransmit them without
	the TO bit set.
	DNS clients MAY set the TO bit in the initial query sent to a server		DNS clients SHOULD first try using port-based DNS-over-TLS by
			establishing the TCP connection to the dedicated port TBD (number to
			be defined in Section 4).
			Stub resolvers do not change their recursive resolvers often. A
			slight delay in failing to establish a port-based DNS-over-TLS
			connection is probably minor relative to the benefit of encrypted DNS
			queries and responses. The stub resolver should give a reasonable
			amount of time for the recursive resolver to start the TLS setup,
			such as a few seconds.
			It SHOULD be an implementation and/or local determination as to
			whether to attempt TLS via the dedicated port first and then fall
			back to STARTTLS use, or to choose some other order of attempts and
			fallbacks.
			2.1.2. Sending Queries for Upgrade-Based DNS-over-TLS
			Setting the TO bit in queries sent using UDP transport has no
			protocol meaning. However, the client MAY set the TO bit when using
			UDP transport. The server MUST ignore the TO bit when receiving UDP
			transport.
			DISCUSSION: community advice is sought on this. The advantage of
			allowing a client to send UDP on TO is that servers can collect
			information on deployment (as happened with the DO bit). The
			disadvantage is that a meaningless bit (TO over UDP) might cause
			confusion, and some middleboxes might not pass a UDP query with the
			TO bit set.
			DNS clients set the TO bit in the initial query sent to a server
	using TCP transport to signal their desire that the TCP connection be		using TCP transport to signal their desire that the TCP connection be
	upgraded to TLS. DNS clients MUST NOT set the TO bit on subsequent		upgraded to TLS. DNS clients SHOULD NOT set the TO bit on queries
	queries when using TCP or TLS transport (to avoid ambiguity).		when using TCP or TLS transport because doing so has no meaning in
			this protocol.
	Since the motivation for DNS-over-TLS is to preserve privacy, DNS		Since the motivation for upgrade-based DNS-over-TLS is to preserve
	clients SHOULD use a query that reveals no private information in the		privacy, DNS clients SHOULD use an initial (unprotected) query that
	initial TO=1 query to a server. To provide a standard "dummy" query,		reveals no private information in the initial TO=1 query to a server.
	it is RECOMMENDED to send the initial query with RD=0,		To provide a standard "dummy" query, it is RECOMMENDED to send the
	QNAME="STARTTLS", QCLASS=CH, and QTYPE=TXT ("STARTTLS/CH/TXT")		initial query with RD=0, QNAME="STARTTLS", QCLASS=CH, and QTYPE=TXT
	analogous to administrative queries already in widespread use		("STARTTLS/CH/TXT") analogous to administrative queries already in
	[RFC4892].		widespread use [RFC4892].
	After sending the initial TO=1 query using TCP transport, DNS clients		After sending the initial TO=1 query using TCP transport, DNS clients
	MUST wait for the initial response before sending any subsequent		MUST wait for the initial response before sending any subsequent
	queries over the same TCP connection.		queries over the same TCP connection.
	2.1.2. Receiving Responses		2.1.3. Receiving Responses for Upgrade-Based DNS-over-TLS
	A DNS client that receives a response using UDP transport that has		A DNS client that receives a response using UDP transport that has
	the TO bit set MUST handle that response as usual. It MAY record the		the TO bit set handles that response as usual. It MAY record the
	server's support for DNS-over-TLS and use that information as part of		server's support for DNS-over-TLS and use that information as part of
	its server selection algorithm in the case where multiple servers are		its server selection algorithm in the case where multiple servers are
	available to service a particular query.		available to service a particular query.
	A DNS client that receives a response to its initial query using TCP		A DNS client that has sent the TO bit using TCP transport and
	transport that has the TO bit set MUST immediately initiate a TLS		receives a response to its initial query that has the TO bit set MUST
	handshake using the procedure described in [RFC5246].		immediately initiate a TLS handshake using the procedure described in
			[RFC5246]. (Note that this document does not yet deal with what
			happens when the TLS handshake does not succeed.)
			DISCUSSION: are there any cases in which a DNS client that sent TO on
			DNS-over-TCP and receives TO in the initial response from the server
			would not initiate the TLS handshake? Is there any reason for this
			to be SHOULD rather than MUST?
	A DNS client that receives a response to its initial query using TCP		A DNS client that receives a response to its initial query using TCP
	transport that has the TO bit clear MUST not initiate a TLS handshake		transport that has the TO bit clear MUST not initiate a TLS handshake
	and SHOULD utilize the existing TCP connection for subsequent		and SHOULD utilize the existing TCP connection for subsequent
	queries. DNS clients SHOULD remember server IP addresses that don't		queries. DNS clients SHOULD remember server IP addresses that don't
	support DNS-over-TLS (including TLS handshake failures) and SHOULD		support upgrade-based DNS-over-TLS, including TLS handshake failures,
	NOT request DNS-over-TLS from them for reasonable period. (We		and not request DNS-over-TLS from them for reasonable period (such as
	suggest 1 hour, or when the client discovers a new resolver.)		one hour per server).
	2.2. Use by DNS Servers		2.2. Use by DNS Servers
	2.2.1. Receiving Queries		A DNS server that supports DNS-over-TLS SHOULD support port-based
			DNS-over-TLS, and SHOULD support upgrade-based DNS-over TLS.
	A DNS server receiving a query over UDP MUST ignore the TO bit.		2.2.1. Receiving Queries for Upgrade-Based DNS-over-TLS
	A DNS server receiving a query over an existing TLS connection MUST		A DNS server receiving a query over UDP with the TO bit ignores that
	ignore the TO bit.		bit. A DNS server receiving a query over an existing TLS connection
			with the TO bit ignores that bit.
	A DNS server receiving an initial query over TCP that has the TO bit		A DNS server receiving an initial query over TCP that has the TO bit
	set MAY inform the client it is willing to establish a TLS session,		set MAY inform the client it is willing to establish a TLS session,
	as described in the next section.		as described in the next section.
	A DNS server receiving subsequent queries over TCP MUST ignore the TO		A DNS server receiving subsequent queries over TCP MUST ignore the TO
	bit. (A client wishing to start TLS after the initial query MUST		bit. (A client wishing to start TLS after the initial query MUST
	open a new TCP connection to do so.)		open a new TCP connection to do so.)
	2.2.2. Sending Responses		2.2.2. Sending Responses
	A DNS server sending a response over UDP SHOULD set the TO bit to		A DNS server sending a response over UDP to a query that had an OPT
	indicate its general support for DNS-over-TLS, as long as it is		meta-RR SHOULD set the TO bit to indicate its general support for
	willing and able to support a TLS connection with the particular		DNS-over-TLS, as long as it is willing and able to support a TLS
	client.		connection with the particular client.
	A DNS server receiving an initial query over TCP that has the TO bit		A DNS server receiving an initial query over TCP that has the TO bit
	set MAY set the TO bit in its response. The server MUST then proceed		set MAY set the TO bit in its response. The server MUST then proceed
	with the TLS handshake protocol.		with the TLS handshake protocol.
	A DNS server receiving a "dummy" STARTTLS/CH/TXT query over TCP MUST		A DNS server receiving a "dummy" STARTTLS/CH/TXT query over TCP MUST
	respond with RCODE=0 and a TXT RR in the Answer section. Contents of		respond with RCODE=0 and a TXT RR in the Answer section. Contents of
	the TXT RR are strictly informative (for humans) and MUST NOT be		the TXT RR are strictly informative (for humans) and MUST NOT be
	interpreted by the client software. Recommended TXT RDATA values are		interpreted by the client software. Recommended TXT RDATA values are
	"STARTTLS" or "NO_TLS".		"STARTTLS" or "NO_TLS".
	2.3. Established Sessions		2.3. Established Sessions
	After TLS negotiation completes, the connection will be encrypted and		After TLS negotiation completes, the connection will be encrypted and
	is now protected from eavesdropping and normal DNS queries SHOULD		is now protected from eavesdropping and normal DNS queries SHOULD
	take place.		take place, following DNS-over-TCP framing ([RFC1035], section
			4.2.2).
	Both clients and servers SHOULD follow existing DNS-over-TCP timeout		Both clients and servers SHOULD follow existing DNS-over-TCP timeout
	rules, which are often implementation- and situation-dependent. In		rules, which are often implementation- and situation-dependent. In
	the absence of any other advice, the RECOMMENDED timeout values are		the absence of any other advice, the RECOMMENDED timeout values are
	30 seconds for recursive name servers, 60 seconds for clients of		30 seconds for recursive name servers, 60 seconds for clients of
	recursive name servers, 10 seconds for authoritative name servers,		recursive name servers, 10 seconds for authoritative name servers,
	and 20 seconds for clients of authoritative name servers. Current		and 20 seconds for clients of authoritative name servers. Current
	work in this area may assist DNS-over-TLS clients and servers select		work in this area may assist DNS-over-TLS clients and servers select
	useful timeout values [draft-wouters-edns-tcp-keepalive] [tdns].		useful timeout values [draft-wouters-edns-tcp-keepalive] [tdns].
	As with current DNS-over-TCP, DNS servers MAY close the connection at		As with current DNS-over-TCP, DNS servers MAY close the connection at
	any time (e.g., due to resource constraints). As with current DNS-		any time (e.g., due to resource constraints). As with current DNS-
	over-TCP, clients MUST handle abrupt closes and be prepared to		over-TCP, clients MUST handle abrupt closes and be prepared to
	reestablish connections and/or retry queries. DNS servers SHOULD use		reestablish connections and/or retry queries. DNS servers SHOULD use
	the TLS close-notify request to shift TCP TIME-WAIT state to the		the TLS close-notify request to shift TCP TIME-WAIT state to the
	clients.		clients. Additional requirements and guidance for optimizing DNS-
			over-TCP are provided by [RFC5966], [I-D.ietf-dnsop-5966bis]. As
			discussed in [I-D.ietf-dnsop-5966bis], TCP Fast Open [RFC7413] is of
			benefit.
	DNS servers SHOULD enable fast TLS session resumption [RFC5077] to		DNS servers SHOULD enable fast TLS session resumption [RFC5077] to
	avoid keeping per-client session state.		avoid keeping per-client session state.
	2.4. Downgrade Attacks and Middleboxes		2.4. Downgrade Attacks and Middleboxes
	Middleboxes [RFC3234] may be present in some networks and have been		Middleboxes [RFC3234] may be present in some networks and have been
	known to interfere with normal DNS resolution and create problems for		known to interfere with normal DNS resolution and create problems for
	DNS-over-TLS. Remarkably, downgrade attacks can affect plaintext		DNS-over-TLS. Remarkably, downgrade attacks can affect plaintext
	protocols that utilize "STARTTLS" signaling in a similar way. A DNS		protocols that utilize "STARTTLS" signaling in a similar way. A DNS
	client attempting DNS-over-TLS through a middlebox, or in the		client attempting upgrade-based DNS-over-TLS through a middlebox, or
	presence of a downgrade attack, could have one of the following		in the presence of a downgrade attack, could have one of the
	outcomes (as discussed in prior RFCs [RFC3207]):		following outcomes. (These outcomes are similar to those discussed
			in prior RFCs, such as [RFC3207].)
	1. The DNS client sends a TO=1 query and receives a TO=0 response.
	In this case there is no upgrade to TLS and DNS resolution occurs
	normally, without encryption.
	2. The DNS client sends a TO=1 query and receives a TO=1 response,		o The DNS client sends a TO=1 query and receives a TO=0 response.
	but the TLS handshake fails because the server's certificate		In this case there is no upgrade to TLS and DNS resolution occurs
	cannot be authenticated. In this case the client SHOULD close		normally, without encryption.
	the established connection and fall back to unencrypted DNS for a
	reasonable period (as discussed in Section 2.1.2).
	3. The DNS client sends a TO=1 query and receives a TO=1 response,		o The DNS client sends a TO=1 query and receives a TO=1 response,
	but the middlebox does not understand the TLS negotiation.		but the middlebox does not understand the TLS negotiation.
	Middleboxes SHOULD clear TO in replies if they are not prepared		Middleboxes SHOULD clear TO in replies if they are not prepared to
	to pass through TLS negotiation. Clients SHOULD retry DNS		pass through TLS negotiation. Clients SHOULD retry DNS without TO
	without TO set if negotiation fails, and then retry with TLS		set if negotiation fails, and then retry with TLS after a
	after a reasonable period (see Section 2.1.2).		reasonable period (see Section 2.1.3).
	4. The DNS client sends a TO=1 query but receives no response at		o The DNS client sends a TO=1 query but receives no response at all.
	all. The middlebox might be silently dropping the query due to		The middlebox might be silently dropping the query due to the
	the presence of the TO bit, when it should, in fact, ignore and		presence of the TO bit, when it should, in fact, ignore and pass
	pass through unknown flag bits [RFC6891]. The client SHOULD fall		through unknown flag bits [RFC6891]. The client SHOULD fall back
	back to normal (unencrypted) DNS for a reasonable period (as		to normal (unencrypted) DNS for a reasonable period (as discussed
	discussed in Section 2.1.2).		in Section 2.1.3).
	In general, clients that attempt TLS and fail can either fall back on		In general, clients that attempt TLS and fail can either fall back on
	unencrypted DNS, or wait and retry later, depending on their privacy		unencrypted DNS, or wait and retry later, depending on their privacy
	requirements. If the problem of middleboxes and threat of downgrade		requirements.
	attacks is too serious, the IETF might consider allocating a
	dedicated port for DNS-over-TLS [RFC6335].
	3. Performance Considerations		3. 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) increased processing (CPU).		requires additional state (memory) increased processing (CPU).
	1. Latency: Compared to UDP, DNS-over-TCP requires an additional		1. Latency: Compared to UDP, DNS-over-TCP requires an additional
	round-trip-time (RTT) of latency to establish the connection.		round-trip-time (RTT) of latency to establish the connection.
	The TLS handshake adds another two RTTs of latency. Clients and		The TLS handshake adds another two RTTs of latency. Clients and
	servers should support connection keepalive (reuse) and out-of-		servers should support connection keepalive (reuse) and out-of-
	skipping to change at page 7, line 25 ¶		skipping to change at page 8, line 31 ¶
	4. IANA Considerations		4. IANA Considerations
	This document defines a new bit ("TO") in the Flags field of the		This document defines a new bit ("TO") in the Flags field of the
	EDNS0 OPT meta-RR. At the time of approval of this draft in the		EDNS0 OPT meta-RR. At the time of approval of this draft in the
	standards track, as per the IANA Considerations of RFC 6891, IANA is		standards track, as per the IANA Considerations of RFC 6891, IANA is
	requested to reserve the second leftmost bit of the flags as the TO		requested to reserve the second leftmost bit of the flags as the TO
	bit, immediately adjacent to the DNSSEC DO bit, as shown in		bit, immediately adjacent to the DNSSEC DO bit, as shown in
	Section 2.		Section 2.
			IANA is requested add the following value to the "Service Name and
			Transport Protocol Port Number Registry" registry. That registry is
			populated by expert review [RFC6335], and such a review will be
			requested if this document progresses. It would be desirable to be
			assigned port 54 upon completion of review.
			Service Name DNS-over-TLS
			Transport Protocol(s) TCP
			Assignee IESG
			Contact TBD
			Description DNS query-response protocol run over TLS
			Reference This document
	5. Security Considerations		5. Security Considerations
	The goal of this proposal is to address the security risks that arise		The goal of this proposal is to address the security risks that arise
	because DNS queries may be eavesdropped upon, as described above.		because DNS queries may be eavesdropped upon, as described above.
	There are a number of residual risks that may impact this goal.		There are a number of residual risks that may impact this goal.
	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; we refer to the TLS RFCs for discussion		specific to DNS-over-TLS; we refer to the TLS RFCs for discussion
	of these security issues.		of these security issues.
	skipping to change at page 8, line 23 ¶		skipping to change at page 9, line 43 ¶
	[RFC6698] provides mechanisms to root certificate trust with		[RFC6698] provides mechanisms to root certificate trust with
	DNSSEC. That use here must be carefully evaluated to address		DNSSEC. That use here must be carefully evaluated to address
	potential issues in trust recursion. For stub-to-recursive		potential issues in trust recursion. For stub-to-recursive
	resolver use, certificate authentication is sometimes either easy		resolver use, certificate authentication is sometimes either easy
	or nearly impossible. If the recursive resolver is manually		or nearly impossible. If the recursive resolver is manually
	configured, its certificate can be authenticated when it is		configured, its certificate can be authenticated when it is
	configured. If the recursive resolver is automatically		configured. If the recursive resolver is automatically
	configured (such as with DHCP [RFC2131]), it could use DHCP		configured (such as with DHCP [RFC2131]), it could use DHCP
	authentication mechanisms [RFC3118]).		authentication mechanisms [RFC3118]).
	Ongoing discussion of opportunistic TLS (connections without CA		Ongoing discussion and development of opportunistic TLS (connections
	validation, [draft-hoffman-uta-opportunistic-tls]) may be relevant to		without CA validation, [RFC7435]) may be relevant to DNS-over-TLS.
	DNS-over-TLS.
	6. Acknowledgments		6. Acknowledgments
	We would like to thank Stephane Bortzmeyer, Brian Haberman, Paul		We would like to thank Stephane Bortzmeyer, Brian Haberman, Kim-Minh
	Hoffman, Kim-Minh Kaplan, Bill Manning, George Michaelson, Eric		Kaplan, Bill Manning, George Michaelson, Eric Osterweil, Glen Wiley,
	Osterweil and Glen Wiley for reviewing this Internet-draft, and to		John Dickinson, and Sara Dickinson for reviewing this Internet-draft,
	Nikita Somaiya for early work on this idea.		and Nikita Somaiya for early work on this idea.
	Work by Zi Hu, Liang Zhu, and John Heidemann in this paper is		Work by Zi Hu, Liang Zhu, and John Heidemann in this paper is
	partially sponsored by the U.S. Dept. of Homeland Security (DHS)		partially sponsored by the U.S. Dept. of Homeland Security (DHS)
	Science and Technology Directorate, HSARPA, Cyber Security Division,		Science and Technology Directorate, HSARPA, Cyber Security Division,
	BAA 11-01-RIKA and Air Force Research Laboratory, Information		BAA 11-01-RIKA and Air Force Research Laboratory, Information
	Directorate under agreement number FA8750-12-2-0344, and contract		Directorate under agreement number FA8750-12-2-0344, and contract
	number D08PC75599.		number D08PC75599.
	7. References		7. References
	skipping to change at page 9, line 15 ¶		skipping to change at page 10, line 32 ¶
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,		[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
	"Transport Layer Security (TLS) Session Resumption without		"Transport Layer Security (TLS) Session Resumption without
	Server-Side State", RFC 5077, January 2008.		Server-Side State", RFC 5077, January 2008.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
			[RFC5966] Bellis, R., "DNS Transport over TCP - Implementation
			Requirements", RFC 5966, August 2010.
			[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
			Cheshire, "Internet Assigned Numbers Authority (IANA)
			Procedures for the Management of the Service Name and
			Transport Protocol Port Number Registry", BCP 165,
			RFC 6335, August 2011.
	[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms		[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
	for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.		for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
	7.2. Informative References		7.2. Informative References
	[CA_Compromise]		[CA_Compromise]
	Infosec Island Admin, "CA Compromise", January 2012, <http		Infosec Island Admin, "CA Compromise", January 2012, <http
	://www.infosecisland.com/blogview/		://www.infosecisland.com/blogview/
	19782-Web-Authentication-A-Broken-Trust-with-No-Easy-		19782-Web-Authentication-A-Broken-Trust-with-No-Easy-
	Fix.html>.		Fix.html>.
			[I-D.ietf-dnsop-5966bis]
			Dickinson, J., Bellis, R., Mankin, A., and D. Wessels,
			"DNS Transport over TCP - Implementation Requirements",
			draft-ietf-dnsop-5966bis-00 (work in progress),
			December 2014.
			[I-D.ietf-dprive-problem-statement]
			Bortzmeyer, S., "DNS privacy considerations",
			draft-ietf-dprive-problem-statement-00 (work in progress),
			October 2014.
	[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",		[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
	STD 53, RFC 1939, May 1996.		STD 53, RFC 1939, May 1996.
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
	RFC 2131, March 1997.		RFC 2131, March 1997.
	[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",		[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
	RFC 2595, June 1999.		RFC 2595, June 1999.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
	skipping to change at page 10, line 13 ¶		skipping to change at page 11, line 51 ¶
	RFC 4033, March 2005.		RFC 4033, March 2005.
	[RFC4892] Woolf, S. and D. Conrad, "Requirements for a Mechanism		[RFC4892] Woolf, S. and D. Conrad, "Requirements for a Mechanism
	Identifying a Name Server Instance", RFC 4892, June 2007.		Identifying a Name Server Instance", RFC 4892, June 2007.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, May 2008.		(CRL) Profile", RFC 5280, May 2008.
	[RFC5966] Bellis, R., "DNS Transport over TCP - Implementation
	Requirements", RFC 5966, August 2010.
	[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
	Cheshire, "Internet Assigned Numbers Authority (IANA)
	Procedures for the Management of the Service Name and
	Transport Protocol Port Number Registry", BCP 165,
	RFC 6335, August 2011.
	[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication		[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
	of Named Entities (DANE) Transport Layer Security (TLS)		of Named Entities (DANE) Transport Layer Security (TLS)
	Protocol: TLSA", RFC 6698, August 2012.		Protocol: TLSA", RFC 6698, August 2012.
	[certificate_pinning]		[RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S.,
	OWASP, "Certificate and Public Key Pinning", <https://		Roome, W., Shalunov, S., and R. Woundy, "Application-Layer
	www.owasp.org/index.php/		Traffic Optimization (ALTO) Protocol", RFC 7285,
	Certificate_and_Public_Key_Pinning>.		September 2014.
	[draft-bortzmeyer-dnsop-dns-privacy]		[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
	Bortzmeyer, S., "DNS Privacy issues",		Fast Open", RFC 7413, December 2014.
	draft-bortzmeyer-dnsop-dns-privacy-01 (work in progress),
	November 2013, <http://tools.ietf.org/html/
	draft-bortzmeyer-dnsop-dns-privacy-01>.
	[draft-bortzmeyer-dnsop-privacy-sol]		[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
	Bortzmeyer, S., "Solutions to DNS privacy issues",		Most of the Time", RFC 7435, December 2014.
	draft-bortzmeyer-dnsop-privacy-sol-00 (work in progress),
	December 2013, <http://tools.ietf.org/html/		[certificate_pinning]
	draft-bortzmeyer-dnsop-privacy-sol-00>.		OWASP, "Certificate and Public Key Pinning", 2014, <https:
			//www.owasp.org/index.php/
			Certificate_and_Public_Key_Pinning>.
	[draft-dempsky-dnscurve]		[draft-dempsky-dnscurve]
	Dempsky, M., "DNSCurve", draft-dempsky-dnscurve-01 (work		Dempsky, M., "DNSCurve", draft-dempsky-dnscurve-01 (work
	in progress), August 2010,		in progress), August 2010,
	<http://tools.ietf.org/html/draft-dempsky-dnscurve-01>.		<http://tools.ietf.org/html/draft-dempsky-dnscurve-01>.
	[draft-hoffman-uta-opportunistic-tls]
	Hoffman, P., "Opportunistic Encryption Using TLS",
	draft-hoffman-uta-opportunistic-tls-00 (work in progress),
	February 2014, <http://tools.ietf.org/html/
	draft-hoffman-uta-opportunistic-tls-00>.
	[draft-osterweil-dane-ipsec]		[draft-osterweil-dane-ipsec]
	Osterweil, E., Wiley, G., Mitchell, D., and A. Newton,		Osterweil, E., Wiley, G., Mitchell, D., and A. Newton,
	"Opportunistic Encryption with DANE Semantics and IPsec:		"Opportunistic Encryption with DANE Semantics and IPsec:
	IPSECA", draft-osterweil-dane-ipsec-00 (work in progress),		IPSECA", draft-osterweil-dane-ipsec-00 (work in progress),
	February 2014,		February 2014,
	<http://tools.ietf.org/html/		<http://tools.ietf.org/html/
	draft-osterweil-dane-ipsec-00>.		draft-osterweil-dane-ipsec-00>.
	[draft-wijngaards-confidentialdns]		[draft-wijngaards-confidentialdns]
	Wijngaards, W., "Confidential DNS",		Wijngaards, W., "Confidential DNS",
	skipping to change at page 12, line 29 ¶		skipping to change at page 14, line 4 ¶
	Phone: +1 310 822-1511		Phone: +1 310 822-1511
	Email: johnh@isi.edu		Email: johnh@isi.edu
	Allison Mankin		Allison Mankin
	Verisign Labs		Verisign Labs
	12061 Bluemont Way		12061 Bluemont Way
	Reston, VA 20190		Reston, VA 20190
	Phone: +1 703 948-3200		Phone: +1 703 948-3200
	Email: amankin@verisign.com		Email: amankin@verisign.com
	Duane Wessels		Duane Wessels
	Verisign Labs		Verisign Labs
	12061 Bluemont Way		12061 Bluemont Way
	Reston, VA 20190		Reston, VA 20190
	Phone: +1 703 948-3200		Phone: +1 703 948-3200
	Email: dwessels@verisign.com		Email: dwessels@verisign.com
			Paul Hoffman
			VPN Consortium
			Email: paul.hoffman@vpnc.org
End of changes. 46 change blocks.
	145 lines changed or deleted		213 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/