< draft-ietf-dprive-dtls-and-tls-profiles-00.txt		draft-ietf-dprive-dtls-and-tls-profiles-01.txt >
	dprive S. Dickinson		dprive S. Dickinson
	Internet-Draft Sinodun		Internet-Draft Sinodun
	Intended status: Standards Track D. Gillmor		Intended status: Standards Track D. Gillmor
	Expires: August 2, 2016 ACLU		Expires: September 22, 2016 ACLU
	T. Reddy		T. Reddy
	Cisco		Cisco
	January 30, 2016		March 21, 2016
	Authentication and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS		Authentication and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS
	draft-ietf-dprive-dtls-and-tls-profiles-00		draft-ietf-dprive-dtls-and-tls-profiles-01
	Abstract		Abstract
	This document describes how a DNS client can use a domain name to		This document describes how a DNS client can use a domain name to
	authenticate a DNS server that uses Transport Layer Security (TLS)		authenticate a DNS server that uses Transport Layer Security (TLS)
	and Datagram TLS (DTLS). Additionally, it defines (D)TLS profiles		and Datagram TLS (DTLS). Additionally, it defines (D)TLS profiles
	for DNS clients and servers implementing DNS-over-TLS and DNS-over-		for DNS clients and servers implementing DNS-over-TLS and DNS-over-
	DTLS.		DTLS.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 August 2, 2016.		This Internet-Draft will expire on September 22, 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 21 ¶		skipping to change at page 2, line 21 ¶
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 5		4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 5
	4.2. Usage Profiles . . . . . . . . . . . . . . . . . . . . . 5		4.2. Usage Profiles . . . . . . . . . . . . . . . . . . . . . 5
	4.3. Authentication . . . . . . . . . . . . . . . . . . . . . 6		4.3. Authentication . . . . . . . . . . . . . . . . . . . . . 6
	4.3.1. DNS-over-(D)TLS Bootstrapping Problems . . . . . . . 6		4.3.1. DNS-over-(D)TLS Bootstrapping Problems . . . . . . . 6
	4.3.2. Credential Verification . . . . . . . . . . . . . . . 7		4.3.2. Credential Verification . . . . . . . . . . . . . . . 7
	4.3.3. Implementation guidance . . . . . . . . . . . . . . . 7		4.3.3. Implementation guidance . . . . . . . . . . . . . . . 7
	5. Authentication in Opportunistic DNS-over(D)TLS Privacy . . . 7		5. Authentication in Opportunistic DNS-over(D)TLS Privacy . . . 7
	6. Authentication in Strict DNS-over(D)TLS Privacy . . . . . . . 7		6. Authentication in Strict DNS-over(D)TLS Privacy . . . . . . . 8
	7. In Band Source of Domain Name: SRV Service Label . . . . . . 8		7. In Band Source of Domain Name: SRV Service Label . . . . . . 8
	8. Out of Band Sources of Domain Name . . . . . . . . . . . . . 8		8. Out of Band Sources of Domain Name . . . . . . . . . . . . . 8
	8.1. Full direct configuration . . . . . . . . . . . . . . . . 8		8.1. Full direct configuration . . . . . . . . . . . . . . . . 9
	8.2. Direct configuration of name only . . . . . . . . . . . . 8		8.2. Direct configuration of name only . . . . . . . . . . . . 9
	8.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 9		8.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	9. Credential Verification . . . . . . . . . . . . . . . . . . . 9		9. Credential Verification . . . . . . . . . . . . . . . . . . . 10
	9.1. X.509 Certificate Based Authentication . . . . . . . . . 9		9.1. X.509 Certificate Based Authentication . . . . . . . . . 10
	9.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 10		9.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 10		9.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 11
	9.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 11		9.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 11
	10. Combined Credentials with SPKI Pinsets . . . . . . . . . . . 11		10. Combined Credentials with SPKI Pinsets . . . . . . . . . . . 12
	11. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 12		11. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 12
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 13		13. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	13.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 13		13.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 13
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	15.1. Normative References . . . . . . . . . . . . . . . . . . 14		15.1. Normative References . . . . . . . . . . . . . . . . . . 14
	15.2. Informative References . . . . . . . . . . . . . . . . . 15		15.2. Informative References . . . . . . . . . . . . . . . . . 15
	Appendix A. Server capability probing and caching by DNS clients 16		Appendix A. Server capability probing and caching by DNS clients 17
	Appendix B. Changes between revisions . . . . . . . . . . . . . 17		Appendix B. Changes between revisions . . . . . . . . . . . . . 17
	B.1. draft-ietf-dprive-dtls-and-tls-profiles . . . . . . . . . 17		B.1. -01 version . . . . . . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		B.2. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 18
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	The DPRIVE working group has two active documents that provide DNS		The DPRIVE working group has two active documents that provide DNS
	privacy between DNS clients and DNS servers (to address the concerns		privacy between DNS clients and DNS servers (to address the concerns
	in [RFC7626]):		in [RFC7626]):
	o DNS-over-TLS [I-D.ietf-dprive-dns-over-tls]		o DNS-over-TLS [I-D.ietf-dprive-dns-over-tls]
	o DNS-over-DTLS [I-D.ietf-dprive-dnsodtls]		o DNS-over-DTLS [I-D.ietf-dprive-dnsodtls]
	skipping to change at page 5, line 26 ¶		skipping to change at page 5, line 26 ¶
	provide protection against active attackers pretending to be the		provide protection against active attackers pretending to be the
	server, the client must authenticate the server.		server, the client must authenticate the server.
	4.2. Usage Profiles		4.2. Usage Profiles
	A DNS client has a choice of privacy usage profiles available. This		A DNS client has a choice of privacy usage profiles available. This
	choice is briefly discussed in both [I-D.ietf-dprive-dns-over-tls]		choice is briefly discussed in both [I-D.ietf-dprive-dns-over-tls]
	and [I-D.ietf-dprive-dnsodtls]. In summary, the usage profiles are:		and [I-D.ietf-dprive-dnsodtls]. In summary, the usage profiles are:
	o Strict Privacy: the DNS client requires both an encrypted and		o Strict Privacy: the DNS client requires both an encrypted and
	authenticated connection to a DNS Server. A hard failure occurs		authenticated connection to a privacy-enabling DNS Server. A hard
	if this is not available. This requires the client to securely		failure occurs if this is not available. This requires the client
	obtain information it can use to authenticate the server. This		to securely obtain information it can use to authenticate the
	provides strong privacy guarantees to the client. This is		server. This profile can include some initial meta queries
			(performed using Opportunistic Privacy) to securely obtain the IP
			address and authentication information for the privacy-enabling
			DNS server to which the DNS client will subsequently connect. The
			rationale for this is that requiring Strict Privacy for such meta
			queries would introduce significant deployment obstacles. This
			profile provides strong privacy guarantees to the client. This is
	discussed in detail in Section 6.		discussed in detail in Section 6.
	o Opportunistic Privacy: the DNS client uses Opportunistic Security		o Opportunistic Privacy: the DNS client uses Opportunistic Security
	as described in [RFC7435]		as described in [RFC7435]
	"... the use of cleartext as the baseline communication		"... the use of cleartext as the baseline communication
	security policy, with encryption and authentication negotiated		security policy, with encryption and authentication negotiated
	and applied to the communication when available."		and applied to the communication when available."
	In the best case scenario (authenticated and encrypted connection)		In the best case scenario (authenticated and encrypted connection)
	this is equivalent to Strict Privacy, in the worst case (clear		this is equivalent to Strict Privacy, in the worst case (clear
	text connection) this is equivalent to No Privacy. Clients will		text connection) this is equivalent to No Privacy. Clients will
	try for the best case but are willing to fallback to intermediate		try for the best case but are willing to fallback to intermediate
	cases and eventually the worst case scenario in order to obtain a		cases and eventually the worst case scenario in order to obtain a
	response. This provides an undetermined privacy guarantee to the		response. This provides an undetermined privacy guarantee to the
	user depending on what kind of connection is actually used. This		user depending on what kind of connection is actually used. This
	is discussed in Section 5		is discussed in Section 5.
	o No Privacy: the DNS client does not require or attempt to use		o No Privacy: the DNS client does not require or attempt to use
	either encryption or authentication. Queries are always sent in		either encryption or authentication. Queries are always sent in
	clear text. This provides no privacy guarantees to the client.		clear text. This provides no privacy guarantees to the client.
	+-----------------------+------------------+-----------------+		+-----------------------+------------------+-----------------+
	| Usage Profile | Passive Attacker | Active Attacker |		| Usage Profile | Passive Attacker | Active Attacker |
	+-----------------------+------------------+-----------------+		+-----------------------+------------------+-----------------+
	| No Privacy | N | N |		| No Privacy | N | N |
	| Opportunistic Privacy | P | N (D) |		| Opportunistic Privacy | N (D) | N (D) |
	| Strict Privacy | P | P |		| Strict Privacy | P | P |
	+-----------------------+------------------+-----------------+		+-----------------------+------------------+-----------------+
	P == protection; N == no protection; D == detection is possible		P == protection; N == no protection; D == detection is possible
	Table 1: DNS Privacy Protection by Usage Profile and type of attacker		Table 1: DNS Privacy Protection by Usage Profile and type of attacker
	Since Strict Privacy provides the strongest privacy guarantees it is		Since Strict Privacy provides the strongest privacy guarantees it is
	preferable to Opportunistic Privacy which is preferable to No		preferable to Opportunistic Privacy which is preferable to No
	Privacy. However since the different profiles require varying levels		Privacy. However since the different profiles require varying levels
	of configuration (or a trusted relationship with a provider) DNS		of configuration (or a trusted relationship with a provider) DNS
	clients will need to carefully select which profile to use based on		clients will need to carefully select which profile to use based on
	their communication privacy needs.		their communication privacy needs. For the case where a client has a
			trusted relationship with a provider it is expected that the provider
			will provide either a domain name or SPKI pinset via a secure out-of-
			band mechanism and therefore Strict Privacy should be used.
	A DNS client SHOULD select a particular usage profile when resolving		A DNS client SHOULD select a particular usage profile when resolving
	a query. A DNS client MUST NOT fallback from Strict Privacy to		a query. A DNS client MUST NOT fallback from Strict Privacy to
	Opportunistic Privacy during the resolution process as this could		Opportunistic Privacy during the resolution process as this could
	invalidate the protection offered against active attackers.		invalidate the protection offered against active attackers.
	4.3. Authentication		4.3. Authentication
	This document describes authentication mechanisms that can be used in		This document describes authentication mechanisms that can be used in
	either Strict or Opportunistic Privacy for DNS-over-(D)TLS.		either Strict or Opportunistic Privacy for DNS-over-(D)TLS.
	skipping to change at page 7, line 31 ¶		skipping to change at page 7, line 37 ¶
	Section 11 describes the (D)TLS profile for DNS-over(D)TLS.		Section 11 describes the (D)TLS profile for DNS-over(D)TLS.
	Additional considerations relating to general implementation		Additional considerations relating to general implementation
	guidelines are discussed in both Section 13 and in Appendix A.		guidelines are discussed in both Section 13 and in Appendix A.
	5. Authentication in Opportunistic DNS-over(D)TLS Privacy		5. Authentication in Opportunistic DNS-over(D)TLS Privacy
	An Opportunistic Security [RFC7435] profile is described in		An Opportunistic Security [RFC7435] profile is described in
	[I-D.ietf-dprive-dns-over-tls] which MAY be used for DNS-over-(D)TLS.		[I-D.ietf-dprive-dns-over-tls] which MAY be used for DNS-over-(D)TLS.
	DNS clients issuing queries under an opportunistic profile which know		DNS clients issuing queries under an opportunistic profile which know
	of a domain name for a DNS server MAY choose to try to authenticate		of a domain name or SPKI pinset for a given privacy-enabling DNS
	the server using the mechanisms described here. This is useful for		server MAY choose to try to authenticate the server using the
	detecting (but not preventing) active attack, and for debugging or		mechanisms described here. This is useful for detecting (but not
	diagnostic purposes if there are means to report the result of the		preventing) active attack, since the fact that authentication
	authentication attempt. This information can provide a basis for a		information is available indicates that the server in question is a
	DNS client to switch to (preferred) Strict Privacy where it is		privacy-enabling DNS server to which it should be possible to
	viable.		establish an authenticated, encrypted connection. In this case,
			whilst a client cannot know the reason for an authentication failure,
			from a privacy standpoint the client should consider an active attack
			in progress and proceed under that assumption. Attempting
			authentication is also useful for debugging or diagnostic purposes if
			there are means to report the result. This information can provide a
			basis for a DNS client to switch to (preferred) Strict Privacy where
			it is viable.
	6. Authentication in Strict DNS-over(D)TLS Privacy		6. Authentication in Strict DNS-over(D)TLS Privacy
	To authenticate a privacy-enabling DNS server, a DNS client needs to		To authenticate a privacy-enabling DNS server, a DNS client needs to
	know the domain name for each server it is willing to contact. This		know the domain name for each server it is willing to contact. This
	is necessary to protect against active attacks on DNS privacy.		is necessary to protect against active attacks on DNS privacy.
	A DNS client requiring Strict Privacy MUST either use one of the		A DNS client requiring Strict Privacy MUST either use one of the
	sources listed in Section 8 to obtain a domain name for the server it		sources listed in Section 8 to obtain a domain name for the server it
	contacts, or use an SPKI pinset as described in		contacts, or use an SPKI pinset as described in
	skipping to change at page 8, line 34 ¶		skipping to change at page 9, line 4 ¶
	enabling DNS servers.		enabling DNS servers.
	Example service records (for TLS and DTLS respectively):		Example service records (for TLS and DTLS respectively):
	_domain-s._tcp.dns.example.com. SRV 0 1 853 dns1.example.com.		_domain-s._tcp.dns.example.com. SRV 0 1 853 dns1.example.com.
	_domain-s._tcp.dns.example.com. SRV 0 1 853 dns2.example.com.		_domain-s._tcp.dns.example.com. SRV 0 1 853 dns2.example.com.
	_domain-s._udp.dns.example.com. SRV 0 1 853 dns3.example.com.		_domain-s._udp.dns.example.com. SRV 0 1 853 dns3.example.com.
	8. Out of Band Sources of Domain Name		8. Out of Band Sources of Domain Name
	8.1. Full direct configuration		8.1. Full direct configuration
	DNS clients may be directly and securely provisioned with the domain		DNS clients may be directly and securely provisioned with the domain
	name of each privacy-enabling DNS server. For example, using a		name of each privacy-enabling DNS server. For example, using a
	client specific configuration file or API.		client specific configuration file or API.
	In this case, direct configuration for a DNS client would consist of		In this case, direct configuration for a DNS client would consist of
	both an IP address and a domain name for each DNS server.		both an IP address and a domain name for each DNS server.
	8.2. Direct configuration of name only		8.2. Direct configuration of name only
	A DNS client may be configured directly and securely with only the		A DNS client may be configured directly and securely with only the
	domain name of its privacy-enabling DNS server. For example, using a		domain name of its privacy-enabling DNS server. For example, using a
	client specific configuration file or API.		client specific configuration file or API.
	It can then use opportunistic DNS connections to untrusted DNS		A DNS client might learn of a default recursive DNS resolver from an
	servers (e.g. provided by the local DHCP service) to establish the IP		untrusted source (such as DHCP's DNS server option [RFC3646]). It
	address of the intended privacy-enabling DNS server by doing a lookup		can then use opportunistic DNS connections to untrusted recursive DNS
	of SRV records. Such records MUST be validated using DNSSEC.		resolver to establish the IP address of the intended privacy-enabling
			DNS server by doing a lookup of SRV records. Such records MUST be
			validated using DNSSEC. Private DNS resolution can now be done by
			the DNS client against the configured privacy-enabling DNS server.
	Example: For a DNSSEC validating DNS client configured in this way to		Example:
	do strict DNS privacy to dns.example.net, it would opportunistically
	look up the SRV for _domain-s._tcp.dns.example.net and determine		o A DNSSEC validating DNS client is configured with the domain name
	addresses (via opportunistic A and/or AAAA lookups) for the resulting		dns.example.net for a privacy-enabling DNS server
	SRV response(s). The records obtained during this process would only
	be used if they were validated by the client using DNSSEC.		o Using Opportunistic Privacy to a default DNS resolver (acquired,
			for example, using DHCP) the client performs look ups for
			* SRV record for _domain-s._tcp.dns.example.net to obtain the
			server host name
			* A and/or AAAA lookups to obtain IP address for the server host
			name
			o Client validates all the records obtained in the previous step
			using DNSSEC.
			o If the records successfully validate the client proceeds to
			connect to the privacy-enabling DNS server using Strict Privacy.
	A DNS client so configured that successfully connects to a privacy-		A DNS client so configured that successfully connects to a privacy-
	enabling DNS server MAY choose to locally cache the looked up		enabling DNS server MAY choose to locally cache the looked up
	addresses in order to not have to repeat the opportunistic lookup.		addresses in order to not have to repeat the opportunistic lookup.
	8.3. DHCP		8.3. DHCP
	Some clients may have an established trust relationship with a known		Some clients may have an established trust relationship with a known
	DHCP [RFC2131] server for discovering their network configuration.		DHCP [RFC2131] server for discovering their network configuration.
	In the typical case, such a DHCP server provides a list of IP		In the typical case, such a DHCP server provides a list of IP
	skipping to change at page 13, line 47 ¶		skipping to change at page 14, line 29 ¶
	DNS client ought to be able to inform the DNS Resolver that it		DNS client ought to be able to inform the DNS Resolver that it
	does not want any address information leaked, and the DNS Resolver		does not want any address information leaked, and the DNS Resolver
	should honor that request.		should honor that request.
	14. Acknowledgements		14. Acknowledgements
	Thanks to the authors of both [I-D.ietf-dprive-dnsodtls] and		Thanks to the authors of both [I-D.ietf-dprive-dnsodtls] and
	[I-D.ietf-dprive-dns-over-tls] for laying the ground work that this		[I-D.ietf-dprive-dns-over-tls] for laying the ground work that this
	draft builds on and for reviewing the contents. The authors would		draft builds on and for reviewing the contents. The authors would
	also like to thank John Dickinson, Shumon Huque, Melinda Shore, Gowri		also like to thank John Dickinson, Shumon Huque, Melinda Shore, Gowri
	Visweswaran and Ray Bellis for review and discussion of the ideas		Visweswaran, Ray Bellis, Stephane Bortzmeyer and Jinmei Tatuya for
	presented here.		review and discussion of the ideas presented here.
	15. References		15. References
	15.1. Normative References		15.1. Normative References
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 15, line 32 ¶		skipping to change at page 16, line 12 ¶
	NLnetLabs, "Dnssec-Trigger", May 2014,		NLnetLabs, "Dnssec-Trigger", May 2014,
	<https://www.nlnetlabs.nl/projects/dnssec-trigger/>.		<https://www.nlnetlabs.nl/projects/dnssec-trigger/>.
	[I-D.ietf-dnsop-edns-client-subnet]		[I-D.ietf-dnsop-edns-client-subnet]
	Contavalli, C., Gaast, W., tale, t., and W. Kumari,		Contavalli, C., Gaast, W., tale, t., and W. Kumari,
	"Client Subnet in DNS Queries", draft-ietf-dnsop-edns-		"Client Subnet in DNS Queries", draft-ietf-dnsop-edns-
	client-subnet-06 (work in progress), December 2015.		client-subnet-06 (work in 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, "DNS over TLS: Initiation and Performance		and P. Hoffman, "Specification for DNS over TLS", draft-
	Considerations", draft-ietf-dprive-dns-over-tls-05 (work		ietf-dprive-dns-over-tls-09 (work in progress), March
	in progress), January 2016.		2016.
	[I-D.ietf-dprive-dnsodtls]		[I-D.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-04 (work in		(DNSoD)", draft-ietf-dprive-dnsodtls-05 (work in
	progress), January 2016.		progress), March 2016.
	[I-D.ietf-dprive-edns0-padding]		[I-D.ietf-dprive-edns0-padding]
	Mayrhofer, A., "The EDNS(0) Padding Option", draft-ietf-		Mayrhofer, A., "The EDNS(0) Padding Option", draft-ietf-
	dprive-edns0-padding-02 (work in progress), January 2016.		dprive-edns0-padding-03 (work in progress), March 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.
	[I-D.ietf-tls-falsestart]		[I-D.ietf-tls-falsestart]
	Langley, A., Modadugu, N., and B. Moeller, "Transport		Langley, A., Modadugu, N., and B. Moeller, "Transport
	Layer Security (TLS) False Start", draft-ietf-tls-		Layer Security (TLS) False Start", draft-ietf-tls-
	falsestart-01 (work in progress), November 2015.		falsestart-01 (work in progress), November 2015.
	skipping to change at page 16, line 24 ¶		skipping to change at page 16, line 49 ¶
	progress), October 2015.		progress), October 2015.
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
	RFC 2131, DOI 10.17487/RFC2131, March 1997,		RFC 2131, DOI 10.17487/RFC2131, March 1997,
	<http://www.rfc-editor.org/info/rfc2131>.		<http://www.rfc-editor.org/info/rfc2131>.
	[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor		[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
	Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,		Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
	<http://www.rfc-editor.org/info/rfc2132>.		<http://www.rfc-editor.org/info/rfc2132>.
			[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic
			Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
			DOI 10.17487/RFC3646, December 2003,
			<http://www.rfc-editor.org/info/rfc3646>.
	[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>.
	[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning		[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
	Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April		Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
	2015, <http://www.rfc-editor.org/info/rfc7469>.		2015, <http://www.rfc-editor.org/info/rfc7469>.
	[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,
	skipping to change at page 17, line 14 ¶		skipping to change at page 17, line 44 ¶
	authenticated encrypted connection before falling back to a lower		authenticated encrypted connection before falling back to a lower
	security. (RATIONALE: This approach can increase latency while		security. (RATIONALE: This approach can increase latency while
	discovering server capabilities but maximizes the chance of sending		discovering server capabilities but maximizes the chance of sending
	the query over an authenticated encrypted connection.)		the query over an authenticated encrypted connection.)
	Appendix B. Changes between revisions		Appendix B. Changes between revisions
	[Note to RFC Editor: please remove this section prior to		[Note to RFC Editor: please remove this section prior to
	publication.]		publication.]
	B.1. draft-ietf-dprive-dtls-and-tls-profiles		B.1. -01 version
			Section 4.2: Make clear that the Strict Privacy Profile can include
			meta queries performed using Opportunistic Privacy.
			Section 4.2, Table 1: Update to clarify that Opportunistic Privacy
			does not guarantee protection against passive attack.
			Section 4.2: Add sentence discussing client/provider trusted
			relationships.
			Section 5: Add more discussion of detection of active attacks when
			using Opportunistic Privacy.
			Section 8.2: Clarify description and example.
			B.2. draft-ietf-dprive-dtls-and-tls-profiles-00
	Re-submission of draft-dgr-dprive-dtls-and-tls-profiles with name		Re-submission of draft-dgr-dprive-dtls-and-tls-profiles with name
	change to draft-ietf-dprive-dtls-and-tls-profiles. Also minor nits		change to draft-ietf-dprive-dtls-and-tls-profiles. Also minor nits
	fixed.		fixed.
	Authors' Addresses		Authors' Addresses
	Sara Dickinson		Sara Dickinson
	Sinodun Internet Technologies		Sinodun Internet Technologies
	Magdalen Centre		Magdalen Centre
End of changes. 24 change blocks.
	51 lines changed or deleted		104 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/