XEP-0368: SRV records for XMPP over TLS

NOTICE: This document is currently within Last Call or under consideration by the XMPP Council for advancement to the next stage in the XSF standards process. The Last Call ends on 2017-02-11. Please send your feedback to the standards@xmpp.org discussion list.

Table of Contents

1. Introduction

XMPP Core [1] specifies the use of xmpp-client/xmpp-server SRV records as the method of discovering how to connect to an XMPP server. This XEP extends that to include new xmpps-client/xmpps-server SRV records pointing to TLS ports and combine priorities and weights as if they were a single SRV record. Applied to both xmpps-client and xmpps-server SRV records, this provides the opportunity to connect to XMPP servers with at least equal and perhaps increased security and privacy over using STARTTLS. It also provides an easy way for clients to bypass restrictive firewalls that only allow HTTPS, and for servers to host multiple protocols/services on a single port.

2. Requirements

The following format for DNS SRV resource records is specified in RFC 2782 [2]:

    _service._proto.name. TTL class SRV priority weight port target.
    

XMPP Core defines SRV records only where 'service' is 'xmpp-client' and 'xmpp-server'. This document specifies to additionally look up records where 'service' is 'xmpps-client' and 'xmpps-server'. This document specifies that the following additional rules apply:

1. Treat both 'xmpp-' and 'xmpps-' records as the same record with regard to connection order as specified by RFC 2782, in that all priorities and weights are mixed. (so the server operator can decide if they would rather clients connect to tcp with STARTTLS or just with TLS directly)
2. Where 'service' starts with 'xmpps-' the client or server MUST connect with TLS enabled.
3. Where 'service' starts with 'xmpp-' the client or server MUST NOT connect with TLS enabled, connection method is unchanged from XMPP Core.
4. TLS certificates MUST be validated the same way as for STARTTLS. (i.e., as specified in XMPP Core).
5. STARTTLS MUST NOT be used over TLS connections.
6. Client or server SHOULD set SNI TLS extension to the JID's domain part.
7. Client or server SHOULD set the ALPN (RFC 7301 [3]) TLS extension.
8. When ALPN is used protocol MUST be 'xmpp-client' where 'xmpps-client' is the SRV 'service'.
9. When ALPN is used protocol MUST be 'xmpp-server' where 'xmpps-server' is the SRV 'service'.

3. Use Cases

For server operators, this provides a way to host multiple services on the same port, especially when SNI or ALPN extensions are used. Servers could even host xmpp-client and xmpp-server services on the same TLS port. For clients, this provides a virtually zero overhead way to bypass restrictive firewalls that only allow HTTP over port 80 and HTTPS over port 443, as xmpp-over-tls is indistinguishable from http-over-tls when ALPN is not used.

4. Implementation Notes

The only overhead is the single additional SRV lookup. All clients that support STARTTLS already have support for TLS-over-tcp.

Server operators should not expect multiplexing to work in all scenarios and therefore should provide additional SRV record(s) that do not require multiplexing (either standard STARTTLS or dedicated XMPP-over-TLS). This is a result of relying on ALPN for multiplexing, where ALPN might not be supported by all devices or may be disabled by a user due to privacy reasons.

5. Security Considerations

TLS provides AT LEAST the same level of security as STARTTLS, and more privacy without ALPN as using STARTTLS leaks that the underlying protocol is XMPP, while any TLS stream should be indistinguishable from any other TLS stream. TLS provides more security than STARTTLS if RFC 7590 [4] is not followed, as it isn't subject to STARTTLS stripping. All security setup and certificate validation code SHOULD be shared between the STARTTLS and TLS logic as well.

6. IANA Considerations

ALPN (RFC 7301) requires registration of the new Protocol IDs, 'xmpp-client' and 'xmpp-server', specified in this document. The registry is currently located here

7. XMPP Registrar Considerations

There are no XMPP Registrar Considerations.

Appendices

Appendix A: Document Information

Series: XEP
Number: 0368
Publisher: XMPP Standards Foundation
Status: Proposed
Type: Standards Track
Version: 0.1
Last Updated: 2015-12-15
Approving Body: XMPP Council
Dependencies: XMPP Core, RFC 2782
Supersedes: None
Superseded By: None
Short Name: NOT_YET_ASSIGNED
Source Control: HTML
This document in other formats: XML  PDF

Appendix B: Author Information

Appendix C: Legal Notices

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Given that this XMPP Extension Protocol normatively references IETF technologies, discussion on the <xsf-ietf@xmpp.org> list might also be appropriate.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

END