< draft-dkgjsal-dprive-unilateral-probing-01.txt		draft-dkgjsal-dprive-unilateral-probing-02.txt >
	dprive D.K. Gillmor		dprive D.K. Gillmor
	Internet-Draft ACLU		Internet-Draft ACLU
	Intended status: Informational J. Salazar		Intended status: Informational J. Salazar
	Expires: 12 June 2022 A19		Expires: 30 July 2022 A19
	9 December 2021		26 January 2022
	Unilateral Opportunistic Deployment of Encrypted Recursive-to-		Unilateral Opportunistic Deployment of Encrypted Recursive-to-
	Authoritative DNS		Authoritative DNS
	draft-dkgjsal-dprive-unilateral-probing-01		draft-dkgjsal-dprive-unilateral-probing-02
	Abstract		Abstract
	This draft sets out steps that DNS servers (recursive resolvers and		This draft sets out steps that DNS servers (recursive resolvers and
	authoritative servers) can take unilaterally (without any		authoritative servers) can take unilaterally (without any
	coordination with other peers) to defend DNS query privacy against a		coordination with other peers) to defend DNS query privacy against a
	passive network monitor. The steps in this draft can be defeated by		passive network monitor. The steps in this draft can be defeated by
	an active attacker, but should be simpler and less risky to deploy		an active attacker, but should be simpler and less risky to deploy
	than more powerful defenses. The draft also introduces (but does not		than more powerful defenses. The draft also introduces (but does not
	try to specify) the semantics of signalling that would permit defense		try to specify) the semantics of signalling that would permit defense
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 12 June 2022.		This Internet-Draft will expire on 30 July 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	skipping to change at page 2, line 45 ¶		skipping to change at page 2, line 45 ¶
	4.2. Recursive Resolver Requirements . . . . . . . . . . . . . 8		4.2. Recursive Resolver Requirements . . . . . . . . . . . . . 8
	4.3. Authoritative Server Encrypted Transport Connection		4.3. Authoritative Server Encrypted Transport Connection
	State . . . . . . . . . . . . . . . . . . . . . . . . . . 8		State . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.3.1. Separate State for Each of the Recursive Resolver's Own		4.3.1. Separate State for Each of the Recursive Resolver's Own
	IP Addresses . . . . . . . . . . . . . . . . . . . . 10		IP Addresses . . . . . . . . . . . . . . . . . . . . 10
	4.4. Maintaining Authoritative State by IP Address . . . . . . 10		4.4. Maintaining Authoritative State by IP Address . . . . . . 10
	4.5. Probing Policy . . . . . . . . . . . . . . . . . . . . . 11		4.5. Probing Policy . . . . . . . . . . . . . . . . . . . . . 11
	4.5.1. Sending a query over Do53 . . . . . . . . . . . . . . 11		4.5.1. Sending a query over Do53 . . . . . . . . . . . . . . 11
	4.5.2. Receiving a response over Do53 . . . . . . . . . . . 12		4.5.2. Receiving a response over Do53 . . . . . . . . . . . 12
	4.5.3. Initiating a connection over encrypted transport . . 12		4.5.3. Initiating a connection over encrypted transport . . 12
	4.5.4. Establishing an encrypted transport connection . . . 15		4.5.4. Establishing an encrypted transport connection . . . 14
	4.5.5. Failing to establish an encrypted transport		4.5.5. Failing to establish an encrypted transport
	connection . . . . . . . . . . . . . . . . . . . . . 15		connection . . . . . . . . . . . . . . . . . . . . . 15
	4.5.6. Encrypted transport failure . . . . . . . . . . . . . 16		4.5.6. Encrypted transport failure . . . . . . . . . . . . . 15
	4.5.7. Handling clean shutdown of encrypted transport		4.5.7. Handling clean shutdown of encrypted transport
	connection . . . . . . . . . . . . . . . . . . . . . 16		connection . . . . . . . . . . . . . . . . . . . . . 16
	4.5.8. Sending a query over encrypted transport . . . . . . 17		4.5.8. Sending a query over encrypted transport . . . . . . 17
	4.5.9. Receiving a response over encrypted transport . . . . 18		4.5.9. Receiving a response over encrypted transport . . . . 17
	4.5.10. Resource Exhaustion . . . . . . . . . . . . . . . . . 18		4.5.10. Resource Exhaustion . . . . . . . . . . . . . . . . . 18
	4.5.11. Maintaining connections . . . . . . . . . . . . . . . 19		4.5.11. Maintaining connections . . . . . . . . . . . . . . . 19
	5. Signalling for Stronger Defense . . . . . . . . . . . . . . . 19		5. Signalling for Stronger Defense . . . . . . . . . . . . . . . 19
	5.1. Combining Signals with Opportunistic Probing . . . . . . 20		5.1. Combining Signals with Opportunistic Probing . . . . . . 20
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20		7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
	7.1. Server Name Indication . . . . . . . . . . . . . . . . . 20		7.1. Server Name Indication . . . . . . . . . . . . . . . . . 20
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 20		8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
	10.1. Normative References . . . . . . . . . . . . . . . . . . 21		10.1. Normative References . . . . . . . . . . . . . . . . . . 21
	10.2. Informative References . . . . . . . . . . . . . . . . . 21		10.2. Informative References . . . . . . . . . . . . . . . . . 21
	Appendix A. Document Considerations . . . . . . . . . . . . . . 22		Appendix A. Document Considerations . . . . . . . . . . . . . . 22
	A.1. Document History . . . . . . . . . . . . . . . . . . . . 23		A.1. Document History . . . . . . . . . . . . . . . . . . . . 23
	A.1.1. Substantive changes from -00 to -01 . . . . . . . . . 23		A.1.1. Substantive changes from -01 to -02 . . . . . . . . . 23
			A.1.2. Substantive changes from -00 to -01 . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 ([RFC2119] and [RFC8174]) when, and only when, they appear in all		14 ([RFC2119] and [RFC8174]) when, and only when, they appear in all
	skipping to change at page 5, line 33 ¶		skipping to change at page 5, line 33 ¶
	interacts with such a pool likely does not know that it is a pool.		interacts with such a pool likely does not know that it is a pool.
	If some members of the pool are updated to follow this guidance while		If some members of the pool are updated to follow this guidance while
	others are not, the recursive client might see the pool as a single		others are not, the recursive client might see the pool as a single
	authoritative server that sometimes offers and sometimes refuses		authoritative server that sometimes offers and sometimes refuses
	encrypted transport.		encrypted transport.
	To avoid incurring additional minor timeouts for such a recursive		To avoid incurring additional minor timeouts for such a recursive
	resolver, the pool operator SHOULD either:		resolver, the pool operator SHOULD either:
	* ensure that all members of the pool enable the same encrypted		* ensure that all members of the pool enable the same encrypted
	transport(s) simultaneously, or		transport(s) within the span of a few seconds, or
	* ensure that the load balancer maps client requests to pool members		* ensure that the load balancer maps client requests to pool members
	based on client IP addresses.		based on client IP addresses.
	Similar concerns apply to authoritative servers responding from an		Similar concerns apply to authoritative servers responding from an
	anycast IP address. As long as the pool of servers is in a		anycast IP address. As long as the pool of servers is in a
	heterogenous state, any flapping route that switches a given client		heterogenous state, any flapping route that switches a given client
	IP address to a different responder risks incurring an additional		IP address to a different responder risks incurring an additional
	timeout. Frequent changes of routing for anycast listening IP		timeout. Frequent changes of routing for anycast listening IP
	addresses are also likely to cause problems for TLS, TCP, or QUIC		addresses are also likely to cause problems for TLS, TCP, or QUIC
	skipping to change at page 6, line 24 ¶		skipping to change at page 6, line 24 ¶
	authoritative server		authoritative server
	* DANE authentication (potentially including the TLS handshake)		* DANE authentication (potentially including the TLS handshake)
	3.3. Server Name Indication		3.3. Server Name Indication
	An authoritative DNS server that wants to handle unilateral queries		An authoritative DNS server that wants to handle unilateral queries
	MAY rely on Server Name Indication (SNI) to select alternate server		MAY rely on Server Name Indication (SNI) to select alternate server
	credentials. However, such a server MUST NOT serve resource records		credentials. However, such a server MUST NOT serve resource records
	that differ based on SNI (or on the lack of SNI) provided by the		that differ based on SNI (or on the lack of SNI) provided by the
	client.		client, as a probing recursive resolver that offers SNI might or
			might not have used the right server name to get the records it's
			looking for.
	3.4. Resource Exhaustion		3.4. Resource Exhaustion
	A well-behaved recursive resolver may keep an encrypted connection		A well-behaved recursive resolver may keep an encrypted connection
	open to an authoritative server, to amortize the costs of connection		open to an authoritative server, to amortize the costs of connection
	setup for both parties.		setup for both parties.
	However, some authoritative servers may have insufficient resources		However, some authoritative servers may have insufficient resources
	available to keep many connections open concurrently.		available to keep many connections open concurrently.
	An authoritative server facing resource exhaustion SHOULD cleanly		To keep resources under control, authoritative servers should
	close open connections from recursive resolvers based on the		proactively manage their encrypted connections. Section 6.5 of
			[I-D.ietf-dprive-dnsoquic] ("Connection Handling") offers useful
			guidance for servers managing DoQ connections. Section 3.4 of
			[RFC7858] offers useful guidance for servers managing DoT
			connections.
			An authoritative server facing unforseen resource exhaustion SHOULD
			cleanly close open connections from recursive resolvers based on the
	authoritative's preferred prioritization.		authoritative's preferred prioritization.
	A reasonable prioritization scheme would be to close connections in		In the case of unanticipated resource exhaustion, a reasonable
	this order, until resources are back in control:		prioritization scheme would be to close connections in this order,
			until resources are back in control:
	* connections with no outstanding queries, ordered by idle time		* connections with no outstanding queries, ordered by idle time
	(longest idle time gets closed first)		(longest idle time gets closed first)
	* connections with outstanding queries, ordered by age of		* connections with outstanding queries, ordered by age of
	outstanding query (oldest outstanding query gets closed first)		outstanding query (oldest outstanding query gets closed first)
	When resources are especially tight, the authoritative server may		When resources are especially tight, the authoritative server may
	also decline to accept new connections over encrypted transport.		also decline to accept new connections over encrypted transport.
	skipping to change at page 14, line 29 ¶		skipping to change at page 14, line 29 ¶
	on the wire to a passive adversary. This potentially reveals		on the wire to a passive adversary. This potentially reveals
	additional information about which query is being made, based on		additional information about which query is being made, based on
	the NS of the query itself.		the NS of the query itself.
	To avoid additional leakage and complexity, a recursive resolver		To avoid additional leakage and complexity, a recursive resolver
	following this guidance SHOULD NOT send SNI to the authoritative when		following this guidance SHOULD NOT send SNI to the authoritative when
	attempting encrypted transport.		attempting encrypted transport.
	If the recursive resolver needs to send SNI to the authoritative for		If the recursive resolver needs to send SNI to the authoritative for
	some reason not found in this document, it is RECOMMENDED that it		some reason not found in this document, it is RECOMMENDED that it
	implements Encrypted Client Hello ([I-D.ietf-tls-esni] to reduce		implements Encrypted Client Hello ([I-D.ietf-tls-esni]) to reduce
	leakage.		leakage.
	4.5.3.4. Authoritative Server Authentication		4.5.3.4. Authoritative Server Authentication
	A recursive resolver following this guidance MAY attempt to verify		A recursive resolver following this guidance MAY attempt to verify
	the server's identity by X.509 certificate or DANE. When doing so,		the server's identity by X.509 certificate or DANE. When doing so,
	the identity would presumably be based on the NS name used for a		the identity would presumably be based on the NS name used for a
	given query.		given query.
	However, since this probing policy is unilateral and opportunistic,		However, since this probing policy is unilateral and opportunistic,
	the client SHOULD NOT consider it a failure if an encrypted transport		the client connecting under this policy MUST accept any certificate
	handshake that does not authenticate to any particular expected name.		presented by the server. If the client cannot verify the server's
			identity, it MAY use that information for reporting, logging, or
	To avoid the complexity of authoritative servers with multiple		other analysis purposes. But it MUST NOT reject the connection due
	simultaneous names, or multiple names over time, this draft does not		to the authentication failure, as the result would be falling back to
	attempt to describe what name a recursive resolver should use when		cleartext, which would leak the content of the session to a passive
	validating an authoritative server, or what the recursive resolver		network monitor.
	should do with an authentication success.
	4.5.4. Establishing an encrypted transport connection		4.5.4. Establishing an encrypted transport connection
	When an encrypted transport connection actually completes (e.g., the		When an encrypted transport connection actually completes (e.g., the
	TLS handshake completes) at time T1, the resolver sets E-completed[X]		TLS handshake completes) at time T1, the resolver sets E-completed[X]
	to T1 and does the following:		to T1 and does the following:
	If the handshake completed successfully:		If the handshake completed successfully:
	* update E-session[X] so that it is in state established		* update E-session[X] so that it is in state established
	skipping to change at page 18, line 40 ¶		skipping to change at page 18, line 28 ¶
	* Otherwise (R is unsuccessful, e.g., SERVFAIL):		* Otherwise (R is unsuccessful, e.g., SERVFAIL):
	- If Q is not in Do53-queries[X] or any other *-queries[X]:		- If Q is not in Do53-queries[X] or any other *-queries[X]:
	o Return SERVFAIL to the requesting client FIXME: What		o Return SERVFAIL to the requesting client FIXME: What
	response should be sent to the clients in the case that		response should be sent to the clients in the case that
	extended DNS errors are used in an authoritative's response?		extended DNS errors are used in an authoritative's response?
	4.5.10. Resource Exhaustion		4.5.10. Resource Exhaustion
	Over time, a recursive resolver following this policy may find that		To keep resources under control, a recursive resolver should
	it is limited in resources, and may prefer to close some outstanding		proactively manage outstanding encrypted connections. Section 6.5 of
			[I-D.ietf-dprive-dnsoquic] ("Connection Handling") offers useful
			guidance for clients managing DoQ connections. Section 3.4 of
			[RFC7858] offers useful guidance for clients managing DoT
	connections.		connections.
	This could be done by checking available/consumed resources on a		Even with sensible connection managment, a recursive resolver doing
	fixed schedule, by having a policy of only keeping a fixed number of		unilateral probing may find resources unexpectedly scarce, and may
	connections open, by checking resources when activity occurs, or by		need to close some outstanding connections.
	some other cadence.
	When existing connections should be closed, the recursive resolver		In such a situation, the recursive resolver SHOULD use a reasonable
	should use a reasonable prioritization scheme to close outstanding		prioritization scheme to close outstanding connections.
	connections.
	One reasonable prioritization scheme would be:		One reasonable prioritization scheme would be:
	* close outstanding established sessions based on E-last-activity[X]		* close outstanding established sessions based on E-last-activity[X]
	(oldest timestamp gets closed first)		(oldest timestamp gets closed first)
	Note that when resources are limited, a recursive resolver following		Note that when resources are limited, a recursive resolver following
	this guidance may also choose not to initiate new connections for		this guidance may also choose not to initiate new connections for
	encrypted transport.		encrypted transport.
	skipping to change at page 21, line 28 ¶		skipping to change at page 21, line 20 ¶
	This guidance is only one part of operating a privacy-preserving DNS		This guidance is only one part of operating a privacy-preserving DNS
	ecosystem. A privacy-preserving recursive resolver should adopt		ecosystem. A privacy-preserving recursive resolver should adopt
	other practices as well, such as QNAME minimization, local root zone,		other practices as well, such as QNAME minimization, local root zone,
	etc, to reduce the overall leakage of query information that could		etc, to reduce the overall leakage of query information that could
	infringe on the client's privacy.		infringe on the client's privacy.
	9. Acknowledgements		9. Acknowledgements
	Many people contributed to the development of this draft beyond the		Many people contributed to the development of this draft beyond the
	authors, including Brian Dickson, Christian Huitema, Eric Nygren, Jim		authors, including Brian Dickson, Christian Huitema, Eric Nygren, Jim
	Reid, Kris Shrishak, Paul Hoffman, Ralf Weber, and the DPRIVE working		Reid, Kris Shrishak, Paul Hoffman, Ralf Weber, Robert Evans, and the
	group.		DPRIVE working group.
	10. References		10. References
	10.1. Normative References		10.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,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 22, line 4 ¶		skipping to change at page 21, line 45 ¶
	10.2. Informative References		10.2. Informative References
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
	November 1987, <https://www.rfc-editor.org/info/rfc1035>.		November 1987, <https://www.rfc-editor.org/info/rfc1035>.
	[I-D.ietf-dprive-dnsoquic]		[I-D.ietf-dprive-dnsoquic]
	Huitema, C., Dickinson, S., and A. Mankin, "DNS over		Huitema, C., Dickinson, S., and A. Mankin, "DNS over
	Dedicated QUIC Connections", Work in Progress, Internet-		Dedicated QUIC Connections", Work in Progress, Internet-
	Draft, draft-ietf-dprive-dnsoquic-07, 1 December 2021,		Draft, draft-ietf-dprive-dnsoquic-08, 11 January 2022,
	<https://www.ietf.org/archive/id/draft-ietf-dprive-		<https://www.ietf.org/archive/id/draft-ietf-dprive-
	dnsoquic-07.txt>.		dnsoquic-08.txt>.
	[I-D.ietf-tls-esni]		[I-D.ietf-tls-esni]
	Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS		Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
	Encrypted Client Hello", Work in Progress, Internet-Draft,		Encrypted Client Hello", Work in Progress, Internet-Draft,
	draft-ietf-tls-esni-13, 12 August 2021,		draft-ietf-tls-esni-13, 12 August 2021,
	<https://www.ietf.org/archive/id/draft-ietf-tls-esni-		<https://www.ietf.org/archive/id/draft-ietf-tls-esni-
	13.txt>.		13.txt>.
	[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,
	skipping to change at page 23, line 4 ¶		skipping to change at page 22, line 44 ¶
	Appendix A. Document Considerations		Appendix A. Document Considerations
	[ RFC Editor: please remove this section before publication ]		[ RFC Editor: please remove this section before publication ]
	This document is currently edited as markdown. Minor editorial		This document is currently edited as markdown. Minor editorial
	changes can be suggested via merge requests at		changes can be suggested via merge requests at
	https://gitlab.com/dkg/dprive-unilateral-probing or by e-mail to the		https://gitlab.com/dkg/dprive-unilateral-probing or by e-mail to the
	editor. Please direct all significant commentary to the public IETF		editor. Please direct all significant commentary to the public IETF
	DPRIVE mailing list: dprive@ietf.org		DPRIVE mailing list: dprive@ietf.org
	The authors' latest draft can be read online in html		The authors' latest draft can be read online in html
	(https://dkg.gitlab.io/dprive-unilateral-probing/) or pdf		(https://dkg.gitlab.io/dprive-unilateral-probing/) or pdf
	(https://dkg.gitlab.io/dprive-unilateral-probing/unilateral-		(https://dkg.gitlab.io/dprive-unilateral-probing/unilateral-
	probing.pdf) or text (https://dkg.gitlab.io/dprive-unilateral-		probing.pdf) or text (https://dkg.gitlab.io/dprive-unilateral-
	probing/unilateral-probing.txt) formats.		probing/unilateral-probing.txt) formats.
	A.1. Document History		A.1. Document History
	A.1.1. Substantive changes from -00 to -01		A.1.1. Substantive changes from -01 to -02
			* Clarify that deployment to a pool does not need to be strictly
			simultaneous
			* Explain why authoritatives need to serve the same records
			regardless of SNI
			* Defer to external, protocol-specific references for resource
			management
			* Clarify that probed connections must not fail due to
			authentication failure
			A.1.2. Substantive changes from -00 to -01
	* Fallback to cleartext when encrypted transport fails.		* Fallback to cleartext when encrypted transport fails.
	* Reduce default timeout to 4s		* Reduce default timeout to 4s
	* Clarify SNI guidance: OK for selecting server credentials, not OK		* Clarify SNI guidance: OK for selecting server credentials, not OK
	for changing answers		for changing answers
	* Document ALPN and port numbers		* Document ALPN and port numbers
End of changes. 22 change blocks.
	38 lines changed or deleted		64 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/