STRINT Workshop Position Paper: Strengthening the Extensible Messaging and Presence Protocol (XMPP)
draft-saintandre-strint-workshop-xmpp-01

Abstract

This document describes existing and potential future efforts at strengthening the Extensible Messaging and Presence Protocol (XMPP), for discussion at the W3C/IAB workshop on Strengthening the Internet Against Pervasive Monitoring (STRINT).

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 27, 2014.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Discussion Venue
• 4. Per-Hop Encryption
• 5. End-to-End Encryption
• 6. IANA Considerations
• 7. Security Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Author's Address

1. Introduction

The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] (along with its precursor, the so-called "Jabber protocol") has been used since 1999 for instant messaging, presence, and other forms of near-real-time communication.

XMPP has a distributed client-server architecture, with one hop from a client to a server and one hop between any two servers, for a total of at most three hops on the communication path from a given client to another client. Although XMPP has supported per-hop channel encryption using Transport Layer Security (TLS) [RFC5246] since 2004 through a STARTTLS upgrade mechanism on the standard XMPP ports (with a hardcoded TLS-only port for the client-to-server hop since 1999), in practice TLS has not been universally deployed for operational reasons. In the last few months, operators of XMPP services have been working to deploy TLS more widely, and those efforts are summarized in this document.

Given the client-server architecture of XMPP, per-hop encryption using TLS does not protect messages inside the application servers that are used for routing. Therefore, various efforts have been made to provide end-to-end object encryption for the payloads of XMPP "stanzas". To put it mildly, these efforts have been less than completely successful. This document also summarizes the state of end-to-end encryption for XMPP.

2. Terminology

Various security-related terms are to be understood in the sense defined in [RFC4949].

3. Discussion Venue

The discussion venue for this document is the PERPASS mailing list, for which archives and subscription information can be found at https://www.ietf.org/mailman/listinfo/perpass.

4. Per-Hop Encryption

As mentioned, XMPP includes the ability to protect each hop in a communication path using Transport Layer Security (TLS) [RFC5246]. Although per-hop encryption does not protect XMPP payloads from attacks against XMPP servers (since absent end-to-end encryption the payloads would still be cleartext within the servers), it does protect against eavesdropping on the relevant XML streams. Because eavesdropping on unprotected XML streams would reveal personally identifying information such as a user's contact list (which in XMPP is stored on the server) and the intended recipients of a user's messages, protecting all the hops in a communication path is critically important for maintaining the privacy and security of XMPP-based interactions.

Until recently, client-to-server streams were widely protected on the XMPP network, but server-to-server streams were not. This state of affairs has had many causes:

• The lack of TLS protection was not as visible to end users or server administrators.
• Several major XMPP services did not offer or negotiate TLS over server-to-server streams.
• Deployment of proper certificates for authenticated encryption is operationally impossible in multi-tenanted environments.

The last item deserves some explanation. Many instant messaging clients "hardcode" the connection hosts for multi-tenanted domains. For example, if the XMPP service for example.com is serviced by hosting.example.net (and example.net is a large enough service provider), many IM clients will provide a "wizard" interface that enables the end user to choose "example.net" as a service type or provider when configuring an account. As a result, the client software will hide the security details of the connection to example.com and override identity mismatches of the kind otherwise forbidden by the security considerations of the core XMPP specification [RFC6120] and the "CertID" specification [RFC6125]. However, because these overrides are not applied on server-to-server streams, many existing implementations and deployements do not even attempt TLS negotiation for server-to-server streams.

Although a technology like DANE/DNSSEC (see [I-D.ietf-dane-srv]) or POSH/HTTPS (see [I-D.miller-posh] and [I-D.ietf-xmpp-dna]) would provide means to overcome the operational limitations of authenticated encryption, neither is yet widely deployed. Thus, in practice, when server-to-server streams are being protected often the technology used is unauthenticated encryption via TLS and the XMPP Server Dialback extension [XEP-0220].

In late 2013, a number of service operators in the XMPP community committed to mandating encryption on all hops under their control, and a number of software developers committed to supporting the features needed to make such encryption possible. The goal is to enable such encryption permanently on May 19, 2014. So far, one test day has been held (on January 4, 2014) and another test day will be held (on February 22, 2014) before the date of the STRINT workshop. The test day revealed bugs in several XMPP software implementations and prompted security improvements at a number of deployed services. Also helpful has been the "IM Observatory" site at xmpp.net, which enables end users and service administrators to test the security settings of any domain on the public XMPP network.

5. End-to-End Encryption

Over the years, the XMPP community has experimented with a significant number of end-to-end encryption technologies, including OpenPGP [XEP-0027], S/MIME [RFC3923], SIGMA [XEP-0116], end-to-end TLS [I-D.meyer-xmpp-e2e-encryption], XML encryption (never publicly documented), CMS with JOSE formats [I-D.miller-xmpp-e2e], and Off-the-Record (OTR) Messaging https://otr.cypherpunks.ca/. Unfortunately, none of these technologies has been widely deployed. It is likely that the most common of these is OTR, which is supported in several popular XMPP clients. Although OTR does not protect the entire XMPP stanza or all stanza types (since it protects only the <body/> child of the XMPP <message/> stanza type), it does provide some protection for instant messages. Note that a specification for OTR will probably be published as an Internet-Draft in the relatively near future, which might serve to increase the number of implementations and thus further encourage adoption by end users.

6. IANA Considerations

This document requests no actions of the IANA.

7. Security Considerations

As noted in "A Threat Model for Pervasive Passive Surveillance" [I-D.trammell-perpass-ppa]), the use of TLS can help limit the information available for correlation to the network and transport layer headers as opposed to the application layer. As typically deployed, XMPP technologies do not leave application-layer routing data (such as XMPP 'to' and 'from' addresses) at rest on intermediate systems, since there is only one hop between any two given XMPP servers. As a result, encrypting all hops (sending client to sender's server, sender's server to recipient's server, recipient's server to recipient's client) can help to limit the amount of "metadata" that might leak.

It is possible that XMPP servers themselves might be compromised. In that case, per-hop encryption would not protect XMPP communications, and even end-to-end encryption of (parts of) XMPP stanza payloads would leave addressing information and XMPP roster data in the clear. By the same token, it is possible that XMPP clients (or the end-user devices on which such clients are installed) could also be compromised, leaving users utterly at the mercy of an adversary.

This document, along with actions currently being taken to improve the security of the XMPP network, do not assume widespread compromise of XMPP servers and clients or their underlying operating systems or hardware. Thus it is assumed that ubiquitous use of per-hop TLS channel encryption and more significant deployment of end-to-end object encryption technologies will serve to protect XMPP communications to a measurable degree, compared to the alternatives.

8. References

8.1. Normative References

8.2. Informative References

Author's Address