< draft-ietf-xmpp-dna-09.txt		draft-ietf-xmpp-dna-10.txt >
	Network Working Group P. Saint-Andre		Network Working Group P. Saint-Andre
	Internet-Draft &yet		Internet-Draft &yet
	Intended status: Standards Track M. Miller		Intended status: Standards Track M. Miller
	Expires: August 20, 2015 Cisco Systems, Inc.		Expires: September 25, 2015 Cisco Systems, Inc.
	P. Hancke		P. Hancke
	&yet		&yet
	February 16, 2015		March 24, 2015
	Domain Name Associations (DNA) in the Extensible Messaging and Presence		Domain Name Associations (DNA) in the Extensible Messaging and Presence
	Protocol (XMPP)		Protocol (XMPP)
	draft-ietf-xmpp-dna-09		draft-ietf-xmpp-dna-10
	Abstract		Abstract
	This document improves the security of the Extensible Messaging and		This document improves the security of the Extensible Messaging and
	Presence Protocol (XMPP) in two ways. First, it specifies how to		Presence Protocol (XMPP) in two ways. First, it specifies how to
	establish a strong association between a domain name and an XML		establish a strong association between a domain name and an XML
	stream, using the concept of "prooftypes". Second, it describes how		stream, using the concept of "prooftypes". Second, it describes how
	to securely delegate a service domain name (e.g., example.com) to a		to securely delegate a service domain name (e.g., example.com) to a
	target server host name (e.g., hosting.example.net), which is		target server host name (e.g., hosting.example.net), which is
	especially important in multi-tenanted environments where the same		especially important in multi-tenanted environments where the same
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 20, 2015.		This Internet-Draft will expire on September 25, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Client-to-Server (C2S) DNA . . . . . . . . . . . . . . . . . 3		3. Client-to-Server (C2S) DNA . . . . . . . . . . . . . . . . . 3
	3.1. C2S Flow . . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. C2S Flow . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. C2S Description . . . . . . . . . . . . . . . . . . . . . 4		3.2. C2S Description . . . . . . . . . . . . . . . . . . . . . 4
	4. Server-to-Server (S2S) DNA . . . . . . . . . . . . . . . . . 5		4. Server-to-Server (S2S) DNA . . . . . . . . . . . . . . . . . 5
	4.1. S2S Flow . . . . . . . . . . . . . . . . . . . . . . . . 5		4.1. S2S Flow . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.2. A Simple S2S Scenario . . . . . . . . . . . . . . . . . . 8		4.2. A Simple S2S Scenario . . . . . . . . . . . . . . . . . . 8
	4.3. One-Way Authentication . . . . . . . . . . . . . . . . . 9		4.3. No Mutual PKIX Authentication . . . . . . . . . . . . . . 10
	4.4. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 11		4.4. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 11
	4.4.1. Assertion . . . . . . . . . . . . . . . . . . . . . . 11		4.4.1. Assertion . . . . . . . . . . . . . . . . . . . . . . 11
	4.4.2. Supposition . . . . . . . . . . . . . . . . . . . . . 12		4.4.2. Supposition . . . . . . . . . . . . . . . . . . . . . 12
	5. Alternative Prooftypes . . . . . . . . . . . . . . . . . . . 13		5. Alternative Prooftypes . . . . . . . . . . . . . . . . . . . 13
	5.1. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 14		5.1. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	5.2. POSH . . . . . . . . . . . . . . . . . . . . . . . . . . 14		5.2. POSH . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	6. Secure Delegation and Multi-Tenancy . . . . . . . . . . . . . 15		6. Secure Delegation and Multi-Tenancy . . . . . . . . . . . . . 15
	7. Prooftype Model . . . . . . . . . . . . . . . . . . . . . . . 16		7. Prooftype Model . . . . . . . . . . . . . . . . . . . . . . . 16
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	8.1. Well-Known URI for xmpp-client Service . . . . . . . . . 17		8.1. Well-Known URI for xmpp-client Service . . . . . . . . . 17
	8.2. Well-Known URI for xmpp-server Service . . . . . . . . . 17		8.2. Well-Known URI for xmpp-server Service . . . . . . . . . 17
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 17		9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	10.1. Normative References . . . . . . . . . . . . . . . . . . 18		10.1. Normative References . . . . . . . . . . . . . . . . . . 17
	10.2. Informative References . . . . . . . . . . . . . . . . . 19		10.2. Informative References . . . . . . . . . . . . . . . . . 19
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	In systems that use the Extensible Messaging and Presence Protocol		In systems that use the Extensible Messaging and Presence Protocol
	(XMPP) [RFC6120], it is important to establish a strong association		(XMPP) [RFC6120], it is important to establish a strong association
	between the DNS domain name of an XMPP service (e.g., example.com)		between the DNS domain name of an XMPP service (e.g., example.com)
	and the XML stream that a client or peer server initiates with that		and the XML stream that a client or peer server initiates with that
	service. In other words, the client or peer server needs to verify		service. In other words, the client or peer server needs to verify
	the identity of the server to which it connects. Additionally,		the identity of the server to which it connects. Additionally,
	skipping to change at page 5, line 29 ¶		skipping to change at page 5, line 29 ¶
	another example, the server might present a self-signed certificate,		another example, the server might present a self-signed certificate,
	which requires the client to apply either the fallback process		which requires the client to apply either the fallback process
	described in section 6.6.4 of [RFC6125] or prompt the user to accept		described in section 6.6.4 of [RFC6125] or prompt the user to accept
	an unauthenticated connection as described in [I-D.ietf-uta-xmpp].		an unauthenticated connection as described in [I-D.ietf-uta-xmpp].
	4. Server-to-Server (S2S) DNA		4. Server-to-Server (S2S) DNA
	The server-to-server case is significantly more complex than the		The server-to-server case is significantly more complex than the
	client-to-server case, and involves checking of domain name		client-to-server case, and involves checking of domain name
	associations in both directions along with other "wrinkles" described		associations in both directions along with other "wrinkles" described
	in the following sections.		in the following sections. The Server Dialback protocol is defined
			in [XEP-0220]. See [XEP-0344] for considerations when using it
			together with TLS and DNSSEC. Also, [XEP-0288] provides a way to use
			the server-to-server connections for bidirectional exchange of XML
			stanzas which reduces the complexity of some of the processes
			involved.
	4.1. S2S Flow		4.1. S2S Flow
	The following flow chart illustrates the protocol flow for		The following flow chart illustrates the protocol flow for
	establishing domain name associations between Server A (the		establishing domain name associations between Server A (the
	initiating entity) and Server B (the receiving entity), as described		initiating entity) and Server B (the receiving entity), as described
	in the remaining sections of this document.		in the remaining sections of this document.
	|		|
	(A Simple S2S Scenario)		(A Simple S2S Scenario)
	skipping to change at page 6, line 37 ¶		skipping to change at page 6, line 42 ¶
	|		|
	+----------DIALBACK IDENTITY ASSERTION----------+		+----------DIALBACK IDENTITY ASSERTION----------+
	| |		| |
	| A: <db:result from='a.example' |		| A: <db:result from='a.example' |
	| to='b.example'> |		| to='b.example'> |
	| some-dialback-key |		| some-dialback-key |
	| </db:result> |		| </db:result> |
	| |		| |
	+-----------------------------------------------+		+-----------------------------------------------+
	|		|
	(Section 4.3: One-Way Authentication)		(Section 4.3: No Mutual PKIX authentication)
	|		|
	DNS RESOLUTION ETC.		DNS RESOLUTION ETC.
	|		|
	+-------------STREAM HEADERS--------------------+		+-------------STREAM HEADERS--------------------+
	| |		| |
	| B: <stream from='b.example' to='a.example'> |		| B: <stream from='b.example' to='a.example'> |
	| |		| |
	| A: <stream from='a.example' to='b.example'> |		| A: <stream from='a.example' to='b.example'> |
	| |		| |
	+-----------------------------------------------+		+-----------------------------------------------+
	skipping to change at page 9, line 45 ¶		skipping to change at page 10, line 5 ¶
	issued by a widely-accepted certificate authority (CA) in the		issued by a widely-accepted certificate authority (CA) in the
	first place.		first place.
	o The server administrators are running their own XMPP servers,		o The server administrators are running their own XMPP servers,
	rather than using hosting services.		rather than using hosting services.
	Let's consider each of these "wrinkles" in turn. Since Server A is		Let's consider each of these "wrinkles" in turn. Since Server A is
	acting as a S2S client the behaviour is same as in the C2S case		acting as a S2S client the behaviour is same as in the C2S case
	described in Section 3.2.		described in Section 3.2.
	4.3. One-Way Authentication		4.3. No Mutual PKIX Authentication
	If the PKIX certificate presented by Server A during TLS negotiation		If the PKIX certificate presented by Server A during TLS negotiation
	is not trusted by Server B, Server B is unable to mutually		is not trusted by Server B, Server B is unable to mutually
	authenticate Server A. Therefore, Server B needs to verify the		authenticate Server A. Therefore, Server B needs to verify the
	asserted identity of Server A by other means.		asserted identity of Server A by other means.
	1. Server A asserts it is a.example using the Server Dialback		1. Server A asserts it is a.example using the Server Dialback
	protocol:		protocol:
	<db:result from='a.example' to='b.example' id='...'>some-		<db:result from='a.example' to='b.example' id='...'>some-
	dialback-key</db:result>		dialback-key</db:result>
	2. Server B resolves via DNS the service _xmpp-		2. Server B resolves via DNS the service _xmpp-
	server._tcp.a.example.		server._tcp.a.example.
	skipping to change at page 10, line 32 ¶		skipping to change at page 10, line 39 ¶
	that it is a.example:		that it is a.example:
	<stream:stream from='a.example' to='b.example'>		<stream:stream from='a.example' to='b.example'>
	6. The servers attempt TLS negotiation, during which Server A		6. The servers attempt TLS negotiation, during which Server A
	(acting as a TLS server) presents a PKIX certificate proving that		(acting as a TLS server) presents a PKIX certificate proving that
	it is a.example.		it is a.example.
	7. Server B checks the PKIX certificate that Server A provided.		7. Server B checks the PKIX certificate that Server A provided.
	This might be the same certificate presented by Server A as a		This might be the same certificate presented by Server A as a
	client certificate in the initial connection. Even if this		client certificate in the initial connection. See [XEP-0344] for
	certificate is not signed by a trusted CA (for example it could		further discussion about skipping the subsequent steps.
	be self-signed) Server B can verify that there is an association
	between the incoming connection and the domain name a.example.
	Note that this may be insecure unless DNSSEC [RFC4033] is used.
	8. If the certificate provided by Server A is different from the one		8. Server B proceeds with Server Dialback in order to establish the
	presented in the initial connection, Server B proceeds with		domain name association. In order to do this it sends a request
	Server Dialback in order to establish the domain name		for verification as described in [XEP-0220]:
	association. In order to do this it sends a request for
	verification as described in [XEP-0220]:
	<db:verify from='b.example' to='a.example' id='...'>some-		<db:verify from='b.example' to='a.example' id='...'>some-
	dialback-key</db:verify>		dialback-key</db:verify>
	9. Server A responds to this:		9. Server A responds to this:
	<db:verify from='a.example' to='b.example' id='...' type='valid/>		<db:verify from='a.example' to='b.example' id='...' type='valid/>
	allowing Server B to establish the domain name association.		allowing Server B to establish the domain name association.
	At this point the servers are using two TCP connections instead of
	one, which is somewhat wasteful. However, there are ways to tie the
	authentication achieved on the second TCP connection to the first TCP
	connection; see [XEP-0288] for further discussion.
	4.4. Piggybacking		4.4. Piggybacking
	4.4.1. Assertion		4.4.1. Assertion
	Consider the common scenario in which Server B hosts not only		Consider the common scenario in which Server B hosts not only
	b.example but also a second domain c.example (often called a "multi-		b.example but also a second domain c.example (often called a "multi-
	tenanted" environment). If a user of Server B associated with		tenanted" environment). If a user of Server B associated with
	c.example wishes to communicate with a friend at a.example, Server B		c.example wishes to communicate with a friend at a.example, Server B
	needs to send XMPP stanzas from the domain c.example rather than		needs to send XMPP stanzas from the domain c.example rather than
	b.example. Although Server B could open a new TCP connection and		b.example. Although Server B could open a new TCP connection and
	skipping to change at page 14, line 10 ¶		skipping to change at page 14, line 4 ¶
	o A hosting provider such as hosting.example.net might not want to		o A hosting provider such as hosting.example.net might not want to
	take on the liability of holding the certificate and private key		take on the liability of holding the certificate and private key
	for a tenant such as example.com (or the tenant might not want the		for a tenant such as example.com (or the tenant might not want the
	hosting provider to hold its certificate and private key).		hosting provider to hold its certificate and private key).
	o Even if PKIX certificates for each tenant can be obtained, the		o Even if PKIX certificates for each tenant can be obtained, the
	management of so many certificates can introduce a large		management of so many certificates can introduce a large
	administrative load.		administrative load.
	(Additional discussion can be found in [I-D.ietf-xmpp-posh].)		(Additional discussion can be found in [I-D.ietf-xmpp-posh].)
	In these circumstances, prooftypes other than PKIX are desirable or		In these circumstances, prooftypes other than PKIX are desirable or
	necessary. As described below, two alternatives have been defined so		necessary. As described below, two alternatives have been defined so
	far: DNS-Based Authentication of Named Entities (DANE) and PKIX Over		far: DNS-Based Authentication of Named Entities (DANE) and PKIX Over
	Secure HTTP (POSH).		Secure HTTP (POSH).
	5.1. DANE		5.1. DANE
	The DANE prooftype can be defined as follows:		The DANE prooftype can be defined as follows:
	1. The server's proof consists of either a service certificate or		1. The server's proof consists of either a service certificate or
	domain-issued certificate (TLSA usage PKIX-EE or DANE-EE, see		domain-issued certificate (TLSA usage PKIX-EE or DANE-EE, see
	[RFC6698] and [RFC7218]).		[RFC6698] and [RFC7218]).
	2. The proof is checked by verifying an exact match or a hash of		2. The proof is checked by verifying an exact match or a hash of
	either the SubjectPublicKeyInfo or the full certificate.		either the SubjectPublicKeyInfo or the full certificate.
	3. The client's verification material is obtained via secure DNS as		3. The client's verification material is obtained via secure DNS
	described in [I-D.ietf-dane-srv].		[RFC4033] as described in [I-D.ietf-dane-srv].
	4. Secure DNS is necessary in order to effectively establish an		4. Secure DNS is necessary in order to effectively establish an
	alternative chain of trust from the service certificate or		alternative chain of trust from the service certificate or
	domain-issued certificate to the DNS root.		domain-issued certificate to the DNS root.
	The DANE prooftype makes use of the DNS-Based Authentication of Named		The DANE prooftype makes use of the DNS-Based Authentication of Named
	Entities [RFC6698], specifically the use of DANE with DNS SRV records		Entities [RFC6698], specifically the use of DANE with DNS SRV records
	[I-D.ietf-dane-srv]. For XMPP purposes, the following rules apply:		[I-D.ietf-dane-srv]. For XMPP purposes, the following rules apply:
	o If there is no SRV resource record, pursue the fallback methods		o If there is no SRV resource record, pursue the fallback methods
	skipping to change at page 15, line 51 ¶		skipping to change at page 15, line 44 ¶
	hosting.example.net:		hosting.example.net:
	_xmpp-server._tcp.example.com. 0 IN SRV 0 0 5269 hosting.example.net		_xmpp-server._tcp.example.com. 0 IN SRV 0 0 5269 hosting.example.net
	Secure connections with multi-tenancy can work using the PKIX		Secure connections with multi-tenancy can work using the PKIX
	prooftype on a small scale if the provider itself wishes to host		prooftype on a small scale if the provider itself wishes to host
	several domains (e.g., related domains such as jabber-de.example and		several domains (e.g., related domains such as jabber-de.example and
	jabber-ch.example). However, in practice the security of multi-		jabber-ch.example). However, in practice the security of multi-
	tenancy has been found to be unwieldy when the provider hosts large		tenancy has been found to be unwieldy when the provider hosts large
	numbers of XMPP services on behalf of multiple tenants (see		numbers of XMPP services on behalf of multiple tenants (see
	[I-D.ietf-xmpp-posh] for a detailed description). Typically there		[I-D.ietf-xmpp-posh] for a detailed description). As a result,
	are two main reasons for this state of affairs: the service provider
	(say, hosting.example.net) wishes to limit its liability and
	therefore does not wish to hold the certificate and private key for
	the tenant (say, example.com) and the tenant wishes to improve the
	security of the service and therefore does not wish to share its
	certificate and private key with the service provider. As a result,
	server-to-server communications to example.com go unencrypted or the		server-to-server communications to example.com go unencrypted or the
	communications are TLS-encrypted but the certificates are not checked		communications are TLS-encrypted but the certificates are not checked
	(which is functionally equivalent to a connection using an anonymous		(which is functionally equivalent to a connection using an anonymous
	key exchange). This is also true of client-to-server communications,		key exchange). This is also true of client-to-server communications,
	forcing end users to override certificate warnings or configure their		forcing end users to override certificate warnings or configure their
	clients to accept or "pin" certificates for hosting.example.net		clients to accept or "pin" certificates for hosting.example.net
	instead of example.com. The fundamental problem here is that if		instead of example.com. The fundamental problem here is that if
	DNSSEC is not used then the act of delegation via DNS SRV records is		DNSSEC is not used then the act of delegation via DNS SRV records is
	inherently insecure.		inherently insecure.
	skipping to change at page 16, line 38 ¶		skipping to change at page 16, line 26 ¶
	following definition:		following definition:
	prooftype: A mechanism for proving an association between a domain		prooftype: A mechanism for proving an association between a domain
	name and an XML stream, where the mechanism defines (1) the nature		name and an XML stream, where the mechanism defines (1) the nature
	of the server's proof, (2) the matching rules for comparing the		of the server's proof, (2) the matching rules for comparing the
	client's verification material against the server's proof, (3) how		client's verification material against the server's proof, (3) how
	the client obtains its verification material, and (4) whether the		the client obtains its verification material, and (4) whether the
	mechanism depends on secure DNS.		mechanism depends on secure DNS.
	The PKIX, DANE, and POSH prooftypes adhere to this model. (Some		The PKIX, DANE, and POSH prooftypes adhere to this model. (Some
	prooftypes depend on, or are enhanced by, secure DNS and thus also		prooftypes depend on, or are enhanced by, secure DNS [RFC4033] and
	need to describe how they ensure secure delegation.)		thus also need to describe how they ensure secure delegation.)
	Other prooftypes are possible; examples might include TLS with PGP		Other prooftypes are possible; examples might include TLS with PGP
	keys [RFC6091], a token mechanism such as Kerberos [RFC4120] or OAuth		keys [RFC6091], a token mechanism such as Kerberos [RFC4120] or OAuth
	[RFC6749], and Server Dialback keys [XEP-0220].		[RFC6749], and Server Dialback keys [XEP-0220].
	Although the PKIX prooftype reuses the syntax of the XMPP Server		Although the PKIX prooftype reuses the syntax of the XMPP Server
	Dialback protocol [XEP-0220] for signalling between servers, this		Dialback protocol [XEP-0220] for signalling between servers, this
	framework document does not define how the generation and validation		framework document does not define how the generation and validation
	of Server Dialback keys (also specified in [XEP-0220]) is a DNA		of Server Dialback keys (also specified in [XEP-0220]) is a DNA
	prooftype. However, nothing in this document prevents the continued		prooftype. However, nothing in this document prevents the continued
	skipping to change at page 18, line 4 ¶		skipping to change at page 17, line 39 ¶
	With regard to the PKIX prooftype, this document supplements but does		With regard to the PKIX prooftype, this document supplements but does
	not supersede the security considerations of [RFC6120] and [RFC6125].		not supersede the security considerations of [RFC6120] and [RFC6125].
	With regard to the DANE and PKIX prooftypes, the reader is referred		With regard to the DANE and PKIX prooftypes, the reader is referred
	to [I-D.ietf-dane-srv] and [I-D.ietf-xmpp-posh], respectively.		to [I-D.ietf-dane-srv] and [I-D.ietf-xmpp-posh], respectively.
	Any future prooftypes need to thoroughly describe how they conform to		Any future prooftypes need to thoroughly describe how they conform to
	the prooftype model specified in Section 7 of this document.		the prooftype model specified in Section 7 of this document.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-dane-srv]		[I-D.ietf-dane-srv]
	Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-		Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
	Based Authentication of Named Entities (DANE) TLSA Records		Based Authentication of Named Entities (DANE) TLSA Records
	with SRV Records", draft-ietf-dane-srv-06 (work in		with SRV Records", draft-ietf-dane-srv-12 (work in
	progress), June 2014.		progress), March 2015.
	[I-D.ietf-xmpp-posh]		[I-D.ietf-xmpp-posh]
	Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP		Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP
	(POSH)", draft-ietf-xmpp-posh-03 (work in progress),		(POSH)", draft-ietf-xmpp-posh-04 (work in progress),
	January 2015.		February 2015.
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, November 1987.		STD 13, RFC 1034, November 1987.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, November 1987.		specification", STD 13, RFC 1035, November 1987.
	[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for		[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
	specifying the location of services (DNS SRV)", RFC 2782,		specifying the location of services (DNS SRV)", RFC 2782,
	February 2000.		February 2000.
	skipping to change at page 20, line 5 ¶		skipping to change at page 19, line 41 ¶
	6749, October 2012.		6749, October 2012.
	[XEP-0045]		[XEP-0045]
	Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February		Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February
	2012.		2012.
	[XEP-0288]		[XEP-0288]
	Hancke, P. and D. Cridland, "Bidirectional Server-to-		Hancke, P. and D. Cridland, "Bidirectional Server-to-
	Server Connections", XSF XEP 0288, September 2013.		Server Connections", XSF XEP 0288, September 2013.
			[XEP-0344]
			Hancke, P. and D. Cridland, "Impact of TLS and DNSSEC on
			Dialback", XSF XEP 0344, March 2015.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	Thanks to Richard Barnes, Stephen Farrell, and Jonas Lindberg for		Thanks to Richard Barnes, Stephen Farrell, and Jonas Lindberg for
	contributing to earlier versions of this document.		contributing to earlier versions of this document.
	Authors' Addresses		Authors' Addresses
	Peter Saint-Andre		Peter Saint-Andre
	&yet		&yet
End of changes. 24 change blocks.
	44 lines changed or deleted		36 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/