< draft-ietf-dprive-dnsodtls-05.txt		draft-ietf-dprive-dnsodtls-06.txt >
	DPRIVE T. Reddy		DPRIVE T. Reddy
	Internet-Draft D. Wing		Internet-Draft D. Wing
	Intended status: Standards Track P. Patil		Intended status: Standards Track P. Patil
	Expires: September 16, 2016 Cisco		Expires: October 6, 2016 Cisco
	March 15, 2016		April 4, 2016
	DNS over DTLS (DNSoD)		DNS over DTLS (DNSoD)
	draft-ietf-dprive-dnsodtls-05		draft-ietf-dprive-dnsodtls-06
	Abstract		Abstract
	DNS queries and responses are visible to network elements on the path		DNS queries and responses are visible to network elements on the path
	between the DNS client and its server. These queries and responses		between the DNS client and its server. These queries and responses
	can contain privacy-sensitive information which is valuable to		can contain privacy-sensitive information which is valuable to
	protect. An active attacker can send bogus responses causing		protect. An active attacker can send bogus responses causing
	misdirection of the subsequent connection.		misdirection of the subsequent connection.
	To counter passive listening and active attacks, this document		To counter passive listening and active attacks, this document
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 September 16, 2016.		This Internet-Draft will expire on October 6, 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 22 ¶		skipping to change at page 2, line 22 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Relationship to TCP Queries and to DNSSEC . . . . . . . . 3		1.1. Relationship to TCP Queries and to DNSSEC . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. DTLS session initiation, Polling and Discovery . . . . . . . 3		3. DTLS session initiation, Polling and Discovery . . . . . . . 3
	4. Performance Considerations . . . . . . . . . . . . . . . . . 4		4. Performance Considerations . . . . . . . . . . . . . . . . . 4
	5. Established sessions . . . . . . . . . . . . . . . . . . . . 5		5. Established sessions . . . . . . . . . . . . . . . . . . . . 4
	6. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		6. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	7. Downgrade attacks . . . . . . . . . . . . . . . . . . . . . . 7		7. Downgrade attacks . . . . . . . . . . . . . . . . . . . . . . 6
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 8		9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	9.1. Authenticating a DNS Privacy Server . . . . . . . . . . . 8		9.1. Authenticating a DNS Privacy Server . . . . . . . . . . . 8
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	11.1. Normative References . . . . . . . . . . . . . . . . . . 9		11.1. Normative References . . . . . . . . . . . . . . . . . . 8
	11.2. Informative References . . . . . . . . . . . . . . . . . 10		11.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	The Domain Name System is specified in [RFC1034] and [RFC1035]. DNS		The Domain Name System is specified in [RFC1034] and [RFC1035]. DNS
	queries and responses are normally exchanged unencrypted and are thus		queries and responses are normally exchanged unencrypted and are thus
	vulnerable to eavesdropping. Such eavesdropping can result in an		vulnerable to eavesdropping. Such eavesdropping can result in an
	undesired entity learning domains that a host wishes to access, thus		undesired entity learning domains that a host wishes to access, thus
	resulting in privacy leakage. DNS privacy problem is further		resulting in privacy leakage. DNS privacy problem is further
	discussed in [RFC7626].		discussed in [RFC7626].
	skipping to change at page 4, line 18 ¶		skipping to change at page 4, line 18 ¶
	4. Performance Considerations		4. Performance Considerations
	To reduce number of octets of the DTLS handshake, especially the size		To reduce number of octets of the DTLS handshake, especially the size
	of the certificate in the ServerHello (which can be several		of the certificate in the ServerHello (which can be several
	kilobytes), DNS client and server can use raw public keys [RFC7250]		kilobytes), DNS client and server can use raw public keys [RFC7250]
	or Cached Information Extension [I-D.ietf-tls-cached-info]. Cached		or Cached Information Extension [I-D.ietf-tls-cached-info]. Cached
	Information Extension avoids transmitting the server's certificate		Information Extension avoids transmitting the server's certificate
	and certificate chain if the client has cached that information from		and certificate chain if the client has cached that information from
	a previous TLS handshake.		a previous TLS handshake.
	Multiple DNS queries can be sent over a single DTLS session and the		Since pipelined responses can arrive out of order, clients MUST match
	DNSoD client need not wait for an outstanding reply before sending		responses to outstanding queries on the same DTLS connection using
	the next query. The existing Query ID, Query type and Query class		the Message ID. If the response contains a question section, the
	allows multiple requests and responses to be interleaved in whatever		client MUST match the QNAME, QCLASS, and QTYPE fields. Failure by
	order they can be fulfilled by the DNS server. This means DNSoD		clients to properly match responses to outstanding queries can have
	reduces the consumption of UDP port numbers, and because DTLS		serious consequences for interoperability ([RFC7766], Section 7).
	protects the communication between a DNS client and its server, the
	resolver SHOULD NOT use random ephemeral source ports (Section 9.2 of
	[RFC5452]) because such source port use would incur additional,
	unnecessary DTLS load on the DNSoD server. When sending multiple
	queries over a single DTLS session, clients MUST take care to avoid
	Message ID collisions. In other words, they MUST NOT re-use the DNS
	Message ID of an in-flight query.
	It is highly advantageous to avoid server-side DTLS state and reduce		It is highly advantageous to avoid server-side DTLS state and reduce
	the number of new DTLS sessions on the server which can be done with		the number of new DTLS sessions on the server which can be done with
	[RFC5077]. This also eliminates a round-trip for subsequent DNSoD		[RFC5077]. This also eliminates a round-trip for subsequent DNSoD
	queries, because with [RFC5077] the DTLS session does not need to be		queries, because with [RFC5077] the DTLS session does not need to be
	re-established.		re-established.
	Compared to normal DNS, DTLS adds at least 13 octets of header, plus		Compared to normal DNS, DTLS adds at least 13 octets of header, plus
	cipher and authentication overhead to every query and every response.		cipher and authentication overhead to every query and every response.
	This reduces the size of the DNS payload that can be carried. DNS		This reduces the size of the DNS payload that can be carried. DNS
	skipping to change at page 8, line 21 ¶		skipping to change at page 7, line 30 ¶
	DTLS and TLS		DTLS and TLS
	Reference This document		Reference This document
	9. Security Considerations		9. Security Considerations
	The interaction between a DNS client and DNS server requires Datagram		The interaction between a DNS client and DNS server requires Datagram
	Transport Layer Security (DTLS) with a ciphersuite offering		Transport Layer Security (DTLS) with a ciphersuite offering
	confidentiality protection and guidance given in [RFC7525] must be		confidentiality protection and guidance given in [RFC7525] must be
	followed to avoid attacks on DTLS. DNS clients keeping track of		followed to avoid attacks on DTLS. DNS clients keeping track of
	servers known to support DTLS enables clients to detect downgrade		servers known to support DTLS enables clients to detect downgrade
	attacks. For servers with no connection history and no apparent		attacks. To interfere with DNS over DTLS, an on- or off-path
	support for DTLS, depending on their Privacy Profile and privacy		attacker might send an ICMP message towards the DTLS client or DTLS
	requirements, clients may choose to (a) try another server when		server. As these ICMP messages cannot be authenticated, all ICMP
	available, (b) continue without DTLS, or (c) refuse to forward the		errors should be treated as soft errors [RFC1122]. For servers with
	query. Once a DNSoD client has established a security association		no connection history and no apparent support for DTLS, depending on
	with a particular DNS server, and outstanding normal DNS queries with		their Privacy Profile and privacy requirements, clients may choose to
	that server (if any) have been received, the DNSoD client MUST ignore		(a) try another server when available, (b) continue without DTLS, or
	any subsequent normal DNS responses from that server, as all		(c) refuse to forward the query. Once a DNSoD client has established
	subsequent responses should be encrypted. This behavior mitigates		a security association with a particular DNS server, and outstanding
	all possible attacks described in Measures for Making DNS More		normal DNS queries with that server (if any) have been received, the
	Resilient against Forged Answers [RFC5452].		DNSoD client MUST ignore any subsequent normal DNS responses from
			that server, as all subsequent responses should be encrypted. This
			behavior mitigates all possible attacks described in Measures for
			Making DNS More Resilient against Forged Answers [RFC5452].
	A malicious client might attempt to perform a high number of DTLS		A malicious client might attempt to perform a high number of DTLS
	handshakes with a server. As the clients are not uniquely identified		handshakes with a server. As the clients are not uniquely identified
	by the protocol and can be obfuscated with IPv4 address sharing and		by the protocol and can be obfuscated with IPv4 address sharing and
	with IPv6 temporary addresses, a server needs to mitigate the impact		with IPv6 temporary addresses, a server needs to mitigate the impact
	of such an attack. Such mitigation might involve rate limiting		of such an attack. Such mitigation might involve rate limiting
	handshakes from a certain subnet or more advanced DoS/DDoS techniques		handshakes from a certain subnet or more advanced DoS/DDoS techniques
	beyond the scope of this paper.		beyond the scope of this paper.
	9.1. Authenticating a DNS Privacy Server		9.1. Authenticating a DNS Privacy Server
	skipping to change at page 10, line 41 ¶		skipping to change at page 10, line 8 ¶
	[I-D.dgr-dprive-dtls-and-tls-profiles]		[I-D.dgr-dprive-dtls-and-tls-profiles]
	Dickinson, S., Gillmor, D., and T. Reddy, "Authentication		Dickinson, S., Gillmor, D., and T. Reddy, "Authentication
	and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS",		and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS",
	draft-dgr-dprive-dtls-and-tls-profiles-00 (work in		draft-dgr-dprive-dtls-and-tls-profiles-00 (work in
	progress), December 2015.		progress), December 2015.
	[I-D.ietf-dprive-dns-over-tls]		[I-D.ietf-dprive-dns-over-tls]
	Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,		Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
	and P. Hoffman, "Specification for DNS over TLS", draft-		and P. Hoffman, "Specification for DNS over TLS", draft-
	ietf-dprive-dns-over-tls-07 (work in progress), March		ietf-dprive-dns-over-tls-09 (work in progress), March
	2016.		2016.
	[I-D.ietf-tls-cached-info]		[I-D.ietf-tls-cached-info]
	Santesson, S. and H. Tschofenig, "Transport Layer Security		Santesson, S. and H. Tschofenig, "Transport Layer Security
	(TLS) Cached Information Extension", draft-ietf-tls-		(TLS) Cached Information Extension", draft-ietf-tls-
	cached-info-22 (work in progress), January 2016.		cached-info-22 (work in progress), January 2016.
	[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -		[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
	Communication Layers", STD 3, RFC 1122,		Communication Layers", STD 3, RFC 1122,
	DOI 10.17487/RFC1122, October 1989,		DOI 10.17487/RFC1122, October 1989,
	skipping to change at page 11, line 23 ¶		skipping to change at page 10, line 39 ¶
	<http://www.rfc-editor.org/info/rfc7413>.		<http://www.rfc-editor.org/info/rfc7413>.
	[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection		[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
	Most of the Time", RFC 7435, DOI 10.17487/RFC7435,		Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
	December 2014, <http://www.rfc-editor.org/info/rfc7435>.		December 2014, <http://www.rfc-editor.org/info/rfc7435>.
	[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>.
	Authors' Addresses		[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
			D. Wessels, "DNS Transport over TCP - Implementation
			Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
			<http://www.rfc-editor.org/info/rfc7766>.
			Authors' Addresses
	Tirumaleswar Reddy		Tirumaleswar Reddy
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Cessna Business Park, Varthur Hobli		Cessna Business Park, Varthur Hobli
	Sarjapur Marathalli Outer Ring Road		Sarjapur Marathalli Outer Ring Road
	Bangalore, Karnataka 560103		Bangalore, Karnataka 560103
	India		India
	Email: tireddy@cisco.com		Email: tireddy@cisco.com
	Dan Wing		Dan Wing
End of changes. 12 change blocks.
	38 lines changed or deleted		38 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/