Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)
Extracted elements (24)
Piggybacking (both assertion and supposition variants) was designed to allow multi-tenanted servers to establish additional domain name associations on an existing TCP connection rather than opening one connection per domain pair, which would be wasteful when a server hosts a large number of domains.
POSH was introduced to handle multi-tenant hosting without requiring DNSSEC: a hosting provider need not hold the tenant's private key, and the service domain's web server can publish certificate hashes over HTTPS, achieving secure delegation via the existing PKI chain of trust without changes to DNS infrastructure.
RFC 7712 generalizes the XMPP domain name association model beyond the single PKIX prooftype to allow alternatives such as DANE and POSH. This is motivated by scenarios where administrators cannot obtain PKIX certificates for all hosted domains — subsidiary services unable to receive CA verification email, hosting providers unwilling to hold tenants' private keys, and the operational overhead of managing large numbers of per-tenant certificates.
The prooftype framework intentionally does not define Server Dialback keys (XEP-0220) as a DNA prooftype, because XEP-0220 reuses dialback protocol syntax for inter-server signaling rather than defining it as a formal proof mechanism. Nothing prevents continued use of dialback for signaling; a future specification could define a Dialback DNA prooftype consistent with this framework.
After establishing DNA in one direction, S2S peers can use SASL EXTERNAL with a valid client certificate to achieve mutual authentication and establish DNA in both directions on the same connection. If this succeeds, no Server Dialback or second connection is needed for the reverse direction.
Both the DANE and POSH prooftypes specify that the 'to' address of the initial stream header (not TLS SNI) must be used to determine the TLS client's reference identifier, because use of TLS SNI (RFC 6066) is purely discretionary in XMPP as noted in RFC 6120.
When the Authoritative Server in Server Dialback presents the same certificate as the Originating Server, some XMPP implementations skip the <db:verify> exchange (steps 8 and 9 of Section 4.3). These optimization cases are governed by XEP-0344 'Impact of TLS and DNSSEC on Dialback'.
During C2S TLS negotiation, if the PKIX certificate provided by the server is consistent with the XMPP profile of the matching rules from RFC 6125 and is otherwise valid according to RFC 5280, the client accepts that there is a strong domain name association between its stream and the DNS domain name of the XMPP service.
For the DANE prooftype, secure DNS (DNSSEC) is necessary to establish the alternative chain of trust from the service certificate to the DNS root. If no SRV resource record is found, the fallback methods from RFC 6120 must be pursued.
POSH well-known URIs for XMPP are '/.well-known/posh/xmpp-client.json' for client-to-server connections and '/.well-known/posh/xmpp-server.json' for server-to-server connections. If no verification material is found via POSH, fallback methods from RFC 6120 must be pursued.
A DNA prooftype is a mechanism for proving an association between a domain name and an XML stream. It must define: (1) the nature of the server's proof, (2) matching rules for comparing the client's verification material against the proof, (3) how the client obtains verification material, and (4) whether the mechanism depends on secure DNS.
DANE prooftype for XMPP: the server's proof is a service certificate or domain-issued certificate with TLSA usage PKIX-EE or DANE-EE (RFC 6698/RFC 7218), verified by exact match or hash of SubjectPublicKeyInfo or full certificate, with verification material obtained via secure DNS per RFC 7673.
Piggybacking assertion: a server hosting multiple domains (e.g., b.example and c.example) asserts an additional domain identity on an existing stream by sending <db:result from='c.example' to='a.example'> over the existing connection, avoiding the need to open a new TCP connection per domain pair.
Piggybacking supposition: when a server determines that a sub-domain (e.g., rooms.a.example) resolves to an already-connected IP/port and the existing PKIX certificate is also valid for that sub-domain, it can add the additional domain pair to the existing stream using <db:result> without opening a new connection.
POSH prooftype for XMPP: the server's proof is a PKIX certificate checked per RFC 6120 and RFC 6125; the client's verification material is a hash of the certificate retrieved over HTTPS at a well-known URI (RFC 5785). Secure DNS is not required because the HTTPS retrieval relies on the PKI chain of trust.
The Server Dialback <db:result> element functions as a server's assertion of its identity for a domain pair. It carries 'from' and 'to' attributes identifying the asserting and receiving domains, and contains a dialback key as text content; a <db:result type='valid'/> response from the verifying server confirms the association.
The Server Dialback <db:verify> element is used to verify a previously asserted dialback key. It carries 'from', 'to', and 'id' attributes along with the dialback key; the authoritative server responds with type='valid' or type='invalid' to allow or deny the domain name association.
RFC 7712 registers two entries in the 'POSH Service Names' registry (established by RFC 7711 for use with well-known URIs per RFC 5785): 'xmpp-client', enabling clients to verify server identity for C2S streams; and 'xmpp-server', enabling servers to verify peer server identity for S2S streams.
Any future DNA prooftypes must thoroughly describe how they conform to the prooftype model of Section 7, including the server's proof, matching rules, how the client obtains verification material, and dependency on secure DNS. Prooftypes that rely on or are enhanced by secure DNS must also describe how they ensure secure delegation.
For the PKIX prooftype, RFC 7712 supplements but does not supersede the security considerations of RFC 6120 and RFC 6125. For the DANE and POSH prooftypes, the security considerations of RFC 7673 and RFC 7711 apply respectively.
If DNSSEC is not used, DNS SRV delegation from a service domain (e.g., example.com) to a target hostname (e.g., hosting.example.net) is inherently insecure: S2S communications will either be unencrypted or TLS-encrypted with unchecked certificates, the latter being functionally equivalent to anonymous key exchange.
C2S DNA flow: client resolves _xmpp-client._tcp DNS SRV, opens TCP, sends stream header with 'to' attribute naming the service domain, server responds asserting its domain via 'from', TLS is negotiated with the server presenting a PKIX certificate, and the client establishes DNA by checking that certificate per RFC 6125 matching rules and RFC 5280 validity.
Simple S2S DNA flow: Server 1 resolves _xmpp-server._tcp SRV, opens TCP, both sides exchange stream headers asserting their respective domains, mutual TLS is negotiated with each presenting a PKIX client or server certificate, and each server checks the other's certificate per RFC 6125 and RFC 5280 to achieve bidirectional DNA establishment.
When mutual PKIX authentication fails (Server 1's client certificate is unacceptable to Server 2), Server 2 falls back to Server Dialback: Server 1 sends <db:result from='a.example' to='b.example'> with a dialback key, Server 2 opens a new back-connection to Server 1, Server 1 presents its certificate, and Server 2 sends <db:verify> to which Server 1 responds with type='valid', completing the DNA for that direction.