< draft-ietf-dprive-dtls-and-tls-profiles-03.txt		draft-ietf-dprive-dtls-and-tls-profiles-04.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: January 9, 2017 ACLU		Expires: April 10, 2017 ACLU
	T. Reddy		T. Reddy
	Cisco		Cisco
	July 8, 2016		October 7, 2016
	Authentication and (D)TLS Profile for DNS-over-(D)TLS		Authentication and (D)TLS Profile for DNS-over-(D)TLS
	draft-ietf-dprive-dtls-and-tls-profiles-03		draft-ietf-dprive-dtls-and-tls-profiles-04
	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 January 9, 2017.		This Internet-Draft will expire on April 10, 2017.
	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 44 ¶		skipping to change at page 2, line 44 ¶
	11. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 14		11. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 14
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 15		13. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	13.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 15		13.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 15
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16		14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	15.1. Normative References . . . . . . . . . . . . . . . . . . 16		15.1. Normative References . . . . . . . . . . . . . . . . . . 16
	15.2. Informative References . . . . . . . . . . . . . . . . . 17		15.2. Informative References . . . . . . . . . . . . . . . . . 17
	Appendix A. Server capability probing and caching by DNS clients 19		Appendix A. Server capability probing and caching by DNS clients 19
	Appendix B. Changes between revisions . . . . . . . . . . . . . 19		Appendix B. Changes between revisions . . . . . . . . . . . . . 19
	B.1. -03 version . . . . . . . . . . . . . . . . . . . . . . . 19		B.1. -04 version . . . . . . . . . . . . . . . . . . . . . . . 19
	B.2. -02 version . . . . . . . . . . . . . . . . . . . . . . . 19		B.2. -03 version . . . . . . . . . . . . . . . . . . . . . . . 19
	B.3. -01 version . . . . . . . . . . . . . . . . . . . . . . . 20		B.3. -02 version . . . . . . . . . . . . . . . . . . . . . . . 19
	B.4. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 20		B.4. -01 version . . . . . . . . . . . . . . . . . . . . . . . 20
			B.5. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	DNS Privacy issues are discussed in [RFC7626]. Two documents that		DNS Privacy issues are discussed in [RFC7626]. Two documents that
	provide DNS privacy between DNS clients and DNS servers are:		provide DNS privacy between DNS clients and DNS servers are:
	o Specification for DNS over Transport Layer Security (TLS)		o Specification for DNS over Transport Layer Security (TLS)
	[RFC7858], referred to here as simply 'DNS-over-TLS'		[RFC7858], referred to here as simply 'DNS-over-TLS'
	o DNS-over-DTLS (DNSoD) [I-D.ietf-dprive-dnsodtls], referred to here		o DNS-over-DTLS (DNSoD) [I-D.ietf-dprive-dnsodtls], referred to here
	simply as 'DNS-over-DTLS'		simply as 'DNS-over-DTLS'. Note that this document has the
			Intended status of Experimental.
	Both documents are limited in scope to encrypting DNS messages		Both documents are limited in scope to encrypting DNS messages
	between stub clients and recursive resolvers and the same scope is		between stub clients and recursive resolvers and the same scope is
	applied to this document (see Section 2 and Section 3). The		applied to this document (see Section 2 and Section 3). The
	proposals here might be adapted or extended in future to be used for		proposals here might be adapted or extended in future to be used for
	recursive clients and authoritative servers, but this application is		recursive clients and authoritative servers, but this application is
	out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group per		out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group per
	its current charter.		its current charter.
	This document defines two Usage Profiles (Strict and Opportunistic)		This document defines two Usage Profiles (Strict and Opportunistic)
	skipping to change at page 6, line 20 ¶		skipping to change at page 6, line 20 ¶
	example, which network the client is connected to). A Usage Profile		example, which network the client is connected to). A Usage Profile
	is a distinct concept to a usage policy or usage model, which might		is a distinct concept to a usage policy or usage model, which might
	dictate which Profile should be used in a particular context		dictate which Profile should be used in a particular context
	(enterprise vs coffee shop), with a particular set of DNS Servers or		(enterprise vs coffee shop), with a particular set of DNS Servers or
	with reference to other external factors. A description of the		with reference to other external factors. A description of the
	variety of usage policies is out of scope of this document, but may		variety of usage policies is out of scope of this document, but may
	be the subject of a future I-D.		be the subject of a future I-D.
	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 [RFC7858] and		choice is briefly discussed in both [RFC7858] and
	[I-D.ietf-dprive-dnsodtls]. In summary, the usage profiles are:		[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 privacy-enabling DNS Server. A hard		authenticated connection to a privacy-enabling DNS Server. A hard
	failure occurs if this is not available. This requires the client		failure occurs if this is not available. This requires the client
	to securely obtain information it can use to authenticate the		to securely obtain information it can use to authenticate the
	server. This profile can include some initial meta queries		server. This profile can include some initial meta queries
	(performed using Opportunistic Privacy) to securely obtain the IP		(performed using Opportunistic Privacy) to securely obtain the IP
	address and authentication information for the privacy-enabling		address and authentication information for the privacy-enabling
	DNS server to which the DNS client will subsequently connect. The		DNS server to which the DNS client will subsequently connect. The
	rationale for this is that requiring Strict Privacy for such meta		rationale for this is that requiring Strict Privacy for such meta
	queries would introduce significant deployment obstacles. This		queries would introduce significant deployment obstacles. This
	profile provides strong privacy guarantees to the client. This is		profile provides strong privacy guarantees to the client. This is
	discussed in detail in Section 6.		Profile 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."
	The use of Opportunistic Privacy is intended to support		The use of Opportunistic Privacy is intended to support
	incremental deployment of security capabilities with a view to		incremental deployment of security capabilities with a view to
	skipping to change at page 7, line 19 ¶		skipping to change at page 7, line 19 ¶
	depending on the fallback logic of the client, the available		depending on the fallback logic of the client, the available
	authentication information and the capabilities of the DNS Server.		authentication information and the capabilities of the DNS Server.
	In the first three cases the DNS client is willing to continue		In the first three cases the DNS client is willing to continue
	with a connection to the DNS Server and perform resolution of		with a connection to the DNS Server and perform resolution of
	queries.		queries.
	To compare the two Usage profiles the table below shows successful		To compare the two Usage profiles the table below shows successful
	Strict Privacy along side the 3 possible successful outcomes of		Strict Privacy along side the 3 possible successful outcomes of
	Opportunistic Privacy. In the best case scenario for Opportunistic		Opportunistic Privacy. In the best case scenario for Opportunistic
	(authenticated and encrypted connection) it is equivalent to Strict		Privacy (an authenticated and encrypted connection) it is equivalent
	Privacy. In the worst case scenario it is equivalent to clear text.		to Strict Privacy. In the worst case scenario it is equivalent to
	Clients using Opportunistic Privacy SHOULD try for the best case but		clear text. Clients using Opportunistic Privacy SHOULD try for the
	MAY fallback to intermediate cases and eventually the worst case		best case but MAY fallback to intermediate cases and eventually the
	scenario in order to obtain a response. It therefore provides no		worst case scenario in order to obtain a response. It therefore
	privacy guarantee to the user and varying protection depending on		provides no privacy guarantee to the user and varying protection
	what kind of connection is actually used. Note that there is no		depending on what kind of connection is actually used. Note that
	requirement in Opportunistic to notify the user what type of		there is no requirement in Opportunistic to notify the user what type
	connection is actually used, the detection described below is only		of connection is actually used, the 'detection' described below is
	possible if such connection information is available. This is		only possible if such connection information is available. This is
	discussed in Section 5.		discussed in Section 5.
	+---------------+------------+------------------+-----------------+		+---------------+------------+------------------+-----------------+
	| Usage Profile | Connection | Passive Attacker | Active Attacker |		| Usage Profile | Connection | Passive Attacker | Active Attacker |
	+---------------+------------+------------------+-----------------+		+---------------+------------+------------------+-----------------+
	| Strict | A, E | P | P |		| Strict | A, E | P | P |
	| Opportunistic | A, E | P | P |		| Opportunistic | A, E | P | P |
	| Opportunistic | E | P | N (D) |		| Opportunistic | E | P | N (D) |
	| Opportunistic | | N (D) | N (D) |		| Opportunistic | | N (D) | N (D) |
	+---------------+------------+------------------+-----------------+		+---------------+------------+------------------+-----------------+
	skipping to change at page 14, line 20 ¶		skipping to change at page 14, line 20 ¶
	This draft does not make explicit recommendations about how a SPKI		This draft does not make explicit recommendations about how a SPKI
	pinset based authentication mechanism should be combined with a		pinset based authentication mechanism should be combined with a
	domain based mechanism from an operator perspective. However it can		domain based mechanism from an operator perspective. However it can
	be envisaged that a DNS server operator may wish to make both an SPKI		be envisaged that a DNS server operator may wish to make both an SPKI
	pinset and a domain name available to allow clients to choose which		pinset and a domain name available to allow clients to choose which
	mechanism to use. Therefore, the following is guidance on how		mechanism to use. Therefore, the following is guidance on how
	clients ought to behave if they choose to configure both, as is		clients ought to behave if they choose to configure both, as is
	possible in HPKP [RFC7469].		possible in HPKP [RFC7469].
	A DNS client that is configured with both a domain name and a SPKI		A DNS client that is configured with both a domain name and a SPKI
	pinset for a DNS sever SHOULD match on both a valid credential for		pinset for a DNS server SHOULD match on both a valid credential for
	the domain name and a valid SPKI pinset when connecting to that DNS		the domain name and a valid SPKI pinset if both are available when
	server.		connecting to that DNS server.
	11. (D)TLS Protocol Profile		11. (D)TLS Protocol Profile
	This section defines the (D)TLS protocol profile of DNS-over-(D)TLS.		This section defines the (D)TLS protocol profile of DNS-over-(D)TLS.
	There are known attacks on (D)TLS, such as machine-in-the-middle and		There are known attacks on (D)TLS, such as machine-in-the-middle and
	protocol downgrade. These are general attacks on (D)TLS and not		protocol downgrade. These are general attacks on (D)TLS and not
	specific to DNS-over-TLS; please refer to the (D)TLS RFCs for		specific to DNS-over-TLS; please refer to the (D)TLS RFCs for
	discussion of these security issues. Clients and servers MUST adhere		discussion of these security issues. Clients and servers MUST adhere
	to the (D)TLS implementation recommendations and security		to the (D)TLS implementation recommendations and security
	skipping to change at page 15, line 8 ¶		skipping to change at page 15, line 8 ¶
	eliminates the need for the server to retain cryptographic state		eliminates the need for the server to retain cryptographic state
	for longer than necessary.		for longer than necessary.
	o Raw public keys [RFC7250] which reduce the size of the		o Raw public keys [RFC7250] which reduce the size of the
	ServerHello, and can be used by servers that cannot obtain		ServerHello, and can be used by servers that cannot obtain
	certificates (e.g., DNS servers on private networks).		certificates (e.g., DNS servers on private networks).
	Implementations compliant with this profile SHOULD implement all of		Implementations compliant with this profile SHOULD implement all of
	the following items:		the following items:
	o TLS False Start [I-D.ietf-tls-falsestart] which reduces round-		o TLS False Start [RFC7918] which reduces round-trips by allowing
	trips by allowing the TLS second flight of messages		the TLS second flight of messages (ChangeCipherSpec) to also
	(ChangeCipherSpec) to also contain the (encrypted) DNS query		contain the (encrypted) DNS query
	o Cached Information Extension [I-D.ietf-tls-cached-info] which
	avoids transmitting the server's certificate and certificate chain
	if the client has cached that information from a previous TLS
	handshake
	[NOTE: The references to (works in progress) should be upgraded to		o Cached Information Extension [RFC7924] which avoids transmitting
	MUST's if those references become RFC's prior to publication of this		the server's certificate and certificate chain if the client has
	document.]		cached that information from a previous TLS handshake
	Guidance specific to TLS is provided in [RFC7858] and that specific		Guidance specific to TLS is provided in [RFC7858] and that specific
	to DTLS it is provided in[I-D.ietf-dprive-dnsodtls].		to DTLS it is provided in[I-D.ietf-dprive-dnsodtls].
	12. IANA Considerations		12. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	13. Security Considerations		13. Security Considerations
	skipping to change at page 18, line 10 ¶		skipping to change at page 17, line 49 ¶
	15.2. Informative References		15.2. Informative References
	[CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", 2012.		[CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", 2012.
	[dnssec-trigger]		[dnssec-trigger]
	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-dprive-dnsodtls]		[I-D.ietf-dprive-dnsodtls]
	Reddy, T., Wing, D., and P. Patil, "DNS over DTLS		Reddy, T., Wing, D., and P. Patil, "Specification for DNS
	(DNSoD)", draft-ietf-dprive-dnsodtls-06 (work in		over Datagram Transport Layer Security (DTLS)", draft-
	progress), April 2016.		ietf-dprive-dnsodtls-12 (work in progress), September
			2016.
	[I-D.ietf-tls-cached-info]
	Santesson, S. and H. Tschofenig, "Transport Layer Security
	(TLS) Cached Information Extension", draft-ietf-tls-
	cached-info-23 (work in progress), May 2016.
	[I-D.ietf-tls-dnssec-chain-extension]		[I-D.ietf-tls-dnssec-chain-extension]
	Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE		Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE
	Record and DNSSEC Authentication Chain Extension for TLS",		Record and DNSSEC Authentication Chain Extension for TLS",
	draft-ietf-tls-dnssec-chain-extension-00 (work in		draft-ietf-tls-dnssec-chain-extension-01 (work in
	progress), June 2016.		progress), July 2016.
	[I-D.ietf-tls-falsestart]
	Langley, A., Modadugu, N., and B. Moeller, "Transport
	Layer Security (TLS) False Start", draft-ietf-tls-
	falsestart-02 (work in progress), May 2016.
	[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		[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic
	skipping to change at page 19, line 14 ¶		skipping to change at page 18, line 41 ¶
	[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>.
	[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.		[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
	Kumari, "Client Subnet in DNS Queries", RFC 7871,		Kumari, "Client Subnet in DNS Queries", RFC 7871,
	DOI 10.17487/RFC7871, May 2016,		DOI 10.17487/RFC7871, May 2016,
	<http://www.rfc-editor.org/info/rfc7871>.		<http://www.rfc-editor.org/info/rfc7871>.
			[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport
			Layer Security (TLS) False Start", RFC 7918,
			DOI 10.17487/RFC7918, August 2016,
			<http://www.rfc-editor.org/info/rfc7918>.
			[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
			(TLS) Cached Information Extension", RFC 7924,
			DOI 10.17487/RFC7924, July 2016,
			<http://www.rfc-editor.org/info/rfc7924>.
	Appendix A. Server capability probing and caching by DNS clients		Appendix A. Server capability probing and caching by DNS clients
	This section presents a non-normative discussion of how DNS clients		This section presents a non-normative discussion of how DNS clients
	might probe for and cache privacy capabilities of DNS servers.		might probe for and cache privacy capabilities of DNS servers.
	Deployment of both DNS-over-TLS and DNS-over-DTLS will be gradual.		Deployment of both DNS-over-TLS and DNS-over-DTLS will be gradual.
	Not all servers will support one or both of these protocols and the		Not all servers will support one or both of these protocols and the
	well-known port might be blocked by some middleboxes. Clients will		well-known port might be blocked by some middleboxes. Clients will
	be expected to keep track of servers that support DNS-over-TLS and/or		be expected to keep track of servers that support DNS-over-TLS and/or
	DNS-over-DTLS, and those that have been previously authenticated.		DNS-over-DTLS, and those that have been previously authenticated.
	skipping to change at page 19, line 41 ¶		skipping to change at page 19, line 32 ¶
	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. -03 version		B.1. -04 version
			Introduction: Add comment that DNS-over-DTLS draft is Experiments
			Update 2 I-D references to RFCs.
			B.2. -03 version
	Section 9: Update DANE section with better references to RFC7671 and		Section 9: Update DANE section with better references to RFC7671 and
	RFC7250		RFC7250
	B.2. -02 version		B.3. -02 version
	Introduction: Added paragraph on the background and scope of the		Introduction: Added paragraph on the background and scope of the
	document.		document.
	Introduction and Discussion: Added more information on what a Usage		Introduction and Discussion: Added more information on what a Usage
	profiles is (and is not) the the two presented here.		profiles is (and is not) the the two presented here.
	Introduction: Added paragraph to make a comparison with the Strict		Introduction: Added paragraph to make a comparison with the Strict
	profile in RFC7858 clearer.		profile in RFC7858 clearer.
	Section 4.2: Re-worked the description of Opportunistic and the		Section 4.2: Re-worked the description of Opportunistic and the
	table.		table.
	Section 8.3: Clarified statement about use of DHCP in Opportunistic		Section 8.3: Clarified statement about use of DHCP in Opportunistic
	profile		profile
	Title abbreviated.		Title abbreviated.
	B.3. -01 version		B.4. -01 version
	Section 4.2: Make clear that the Strict Privacy Profile can include		Section 4.2: Make clear that the Strict Privacy Profile can include
	meta queries performed using Opportunistic Privacy.		meta queries performed using Opportunistic Privacy.
	Section 4.2, Table 1: Update to clarify that Opportunistic Privacy		Section 4.2, Table 1: Update to clarify that Opportunistic Privacy
	does not guarantee protection against passive attack.		does not guarantee protection against passive attack.
	Section 4.2: Add sentence discussing client/provider trusted		Section 4.2: Add sentence discussing client/provider trusted
	relationships.		relationships.
	Section 5: Add more discussion of detection of active attacks when		Section 5: Add more discussion of detection of active attacks when
	using Opportunistic Privacy.		using Opportunistic Privacy.
	Section 8.2: Clarify description and example.		Section 8.2: Clarify description and example.
	B.4. draft-ietf-dprive-dtls-and-tls-profiles-00		B.5. 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. 19 change blocks.
	54 lines changed or deleted		58 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/