Encrypted but unauthenticated connections (e.g., anonymous Diffie-Hellman, self-signed certificates, or Server Dialback with XEP-0220) are considered better than plaintext connections in scenarios where PKIX certificate deployment is infeasible, analogous to 'better-than-nothing security' for IPsec (RFC 5386).

tls, security

In multi-tenanted environments, obtaining PKIX certificates with correct Subject Alternative Names is extremely difficult, motivating alternative server authentication mechanisms such as DANE (DANE-SRV), POSH (PKIX-POSH), and the DNA framework (XMPP-DNA).

tls, pkix, security

The document neither encourages nor discourages XMPP-layer compression (XEP-0138) over TLS-layer compression; XMPP-layer compression may have slightly stronger security properties because it is enabled only after SASL authentication.

tls, security

TLS SNI (RFC 6066) is not necessary for XMPP because the 'to' attribute of the initial XMPP stream header already conveys the target domain, serving the same virtual-hosting disambiguation function as SNI.

tls

Server Dialback keys (XEP-0220) can be used together with encrypted but unauthenticated TLS server-to-server connections; Dialback alone provides only weak identity verification, strengthened somewhat by DNSSEC, but at minimum enables encryption of s2s links.

tls, security

The Domain Name Associations (DNA) framework provides alternative XMPP server authentication methods including DANE (DNS-Based Authentication of Named Entities with TLSA records) and PKIX over Secure HTTP (POSH), intended as substitutes when standard PKIX certificate deployment is not feasible.

tls, pkix, dns, security

Implementations MUST follow the recommendations in RFC 7525 regarding TLS-layer session resumption, whether or not XEP-0198 application-layer session resumption is also in use.

tls, security

The initiating XMPP entity MUST NOT be deterred from attempting TLS negotiation even if the receiving entity does not advertise the <starttls/> stream feature, since an attacker may have stripped it.

tls, security

When the <starttls/> feature is absent or stripped, the initiating entity SHOULD (based on local policy) proceed with stream negotiation and attempt to negotiate TLS regardless.

tls, security

XMPP clients MUST authenticate servers using PKIX certificates or equivalent mechanisms as specified in RFC 6120 and RFC 6125.

tls, security, pkix

XMPP implementations and deployments MUST follow the best current practices documented in RFC 7525 ('Recommendations for Secure Use of TLS and DTLS'), covering protocol versions, fallback, compression, session resumption, cipher suites, public key lengths, and forward secrecy.

tls, security

XMPP servers MUST authenticate clients, consistent with the requirements in the core XMPP specification RFC 6120.

tls, security

XMPP servers SHOULD authenticate other (peer) servers; while this is strongly preferred, the document does not mandate it given the difficulty of deploying PKIX certificates in multi-tenanted environments.

tls, security, pkix

Human-facing interfaces for XMPP clients and server administration SHOULD expose TLS status, version, authentication method, cipher suite, server certificate, and warnings on certificate change to allow users and admins to verify security properties of each stream.

tls, security

The XMPP STARTTLS stream feature is signalled by the element <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>, with an optional <required/> child element indicating that TLS negotiation is mandatory for that stream.

tls

XMPP implementations SHOULD support TLS-layer session resumption (per RFC 7525) in addition to any XEP-0198 application-layer stream resumption, to optimize re-establishment of XMPP sessions after connection loss.

tls

An attacker performing a STARTTLS-stripping attack can remove the <starttls/> stream feature or its <required/> child from the server's stream features advertisement, misleading the initiating entity into thinking TLS is unavailable or optional; implementors must not rely solely on the advertised feature.

tls, security

If XMPP servers themselves are compromised, per-hop TLS encryption does not protect communications; even end-to-end payload encryption would leave addressing and roster data exposed. The document's recommendations assume servers and clients have not been subject to widespread compromise.

tls, security

This document covers only XMPP network communications and does not address security considerations for gateways to non-XMPP networks such as SIP; those are covered in RFC 7247 and RFC 7572.

tls, security

TLS per-hop encryption limits correlation between the XMPP application layer and the underlying network/transport layers, and because XMPP has only one hop between servers, encrypting all hops (client-to-server, server-to-server, server-to-client) helps limit metadata leakage.

tls, security, privacy