The global community of Extensible Messaging and Presence Protocol (XMPP) instant-messaging users took a step toward improved security on May 19, with the operators of a large number of XMPP servers began enforcing a new, mandatory-encryption requirement. The move is one part of a larger effort to secure the global XMPP network; since that network is a federated collection of independent servers, the task is not easy. But whether it is ultimately successful or not, it increases the availability of end-to-end encryption for users, and those developing other Internet communication tools can learn by watching XMPP's example.

In October of 2013, XMPP creator Peter Saint-Andre first published a manifesto calling for ubiquitous encryption of the XMPP network. XMPP (or, as it was known beforehand, Jabber) has supported SSL/TLS encryption of communication channels since the beginning, but that encryption has always been optional. The manifesto argues that encryption should be mandatory "out of respect for the users of our software and services", and lays out a set of policy recommendations for server and client applications.

May 19, 2014 (deemed Open Discussion Day by the signatories) was the "flip the switch" date set out in the manifesto, after a series of four one-day tests earlier in the year. As of the switch-over itself, 70 XMPP server operators and client-application developers had signed the manifesto. The signatories include the administrators of a number of public XMPP services and the teams behind multiple open-source applications (for example, Jitsi, Gajim, Adium, Miranda NG, ejabberd, Prosody IM, and Tigase).

The main conditions of the manifesto were to support STARTTLS connection establishment (including the mandatory cipher suites and certification validation protocol of RFC 6125) and to require TLS encryption for all client-to-server and server-to-server channels. The hard requirement fell to XMPP service operators, who agreed to reject unencrypted XMPP connection requests. Clients, for backward-compatibility reasons, can continue to support unencrypted connections, but make encryption the default.

Several other details were optional: TLS 1.2 was preferred, but negotiation for TLS 1.1, TLS 1.0, and SSLv3 were to be supported, while support for SSLv2 was to be disabled entirely. Likewise, certificate-based authentication and forward-secrecy cipher options were to be available and preferred, but fallback to unauthenticated encryption and other cipher suites must also be supported. Finally, signatories agreed to provide user-configurable options for other security features, (such as cipher selection and forward-secrecy).

The manifesto also notes that "ideally" the implementers should present as much information as possible about the authentication and encryption status of the channel to the user, and that services should use certificates from well-known certificate authorities, although both of these conditions are described as aspirational goals, rather than as mandates.

In essence, then, the participating XMPP networks are requiring an encrypted channel for XMPP connections, supporting all of the recommended options, and making the strongest options the preference. Nevertheless, this set of requirements does not implement ubiquitous encryption, nor does it mandate every strong authentication option possible. The manifesto notes that these remaining requirements are still to come, and that Open Discussion Day event was merely step one.

In particular, running the XMPP connection over TLS is not the same as encrypting the XMPP messages themselves. For that, one would use the Off-the-Record Messaging (OTR) protocol. The use of TLS also does not guarantee channel binding (as in RFC 5056), which enables applications to verify that secure network-layer connections are not hijacked by other programs elsewhere in the protocol stack, nor does it mandate secure DNS or application-level server identity verification.

The XMPP community has invested some of its time in working on these other pieces of the secure-messaging puzzle, though. The IETF's XMPP Working Group has written a number of draft proposals in recent years, covering topics from DNSSEC for XMPP records to server identity verification. Some of these drafts have since expired (in IETF terminology), seemingly without an update or forward progress in several years. However, the argument in the Open Discussion Day community is that forcibly migrating the XMPP network to TLS encryption was a necessary first step; only with that in place it is possible to make meaningful progress on the remaining challenges.

As for the newly activated encryption requirement, though, it is already in effect. Since XMPP servers are federated (and since quite a few of the manifesto signatories run their own server), it is not easy to estimate how many users there are with accounts that will reject unencrypted connection requests. Unless a server advertises how many users it has, there is no way to know how many accounts each server represents—much as is the case with email providers. Fortunately, the IM Observatory site provides some tools for assessing the current state of many clients and servers.

The site provides a tool with which users can test any publicly reachable XMPP server for client-to-server and server-to-server encryption. Recent test results are published on a live-updated page, although only the past few hours are visible at any one time, and multiple test runs against the same server are not filtered out. Each server receives a grade from A (best) to F (worst), based on the same rubric used by SSL Labs' SSL Server Rating Guide. The guide takes into account connection protocol support (e.g., TLS 1.2 is better than TLS 1.1), key-exchange protocol support (e.g., ephemeral key exchange is better than non-ephemeral), and cipher strength (measured by key length).

The site also maintains statistics over the total set of test tested servers. As of today, 59.1% of the tested servers receive an A, while 7.7% receive an F. Most of those in between are skewed toward the A side of the graph. While that is certainly positive news, not all of the servers tested offer accounts to the general public. To that end, the site also provides a list of open-to-the-public XMPP servers that can be sorted by grade. Among these public servers, 59 out of 115 scored an A, or about 51.3%.

All in all, toggling the mandatory-encryption switch for XMPP is clearly a good move from a security standpoint, and the project seems to have implemented it with an admirable degree of success. One might be tempted to view it as a template that other development communities could emulate. In theory, for instance, it would be nice to see email providers make a concerted push for PGP or S/MIME.

But an uncomfortable caveat accompanies the Open Discussion Day success: the fact that XMPP is not nearly as widely deployed as email. There are some large-scale instant-messaging services (like Skype and Facebook) that offer some degree of XMPP compatibility, but the overall size of the XMPP network is small compared to the proprietary alternatives. In fact, Google deactivated its own XMPP compatibility for Google Talk in 2013.

There are still reportedly millions of XMPP users, but it would be considerably harder to implement a similar single-day switchover for other, more widely deployed services. In the early days of TCP/IP, for example, it was possible for all implementers to assemble in one room. But the transition from IPv4 to IPv6 has been many orders of magnitude slower.

Nevertheless, the activation of mandatory XMPP encryption does demonstrate that when like-minded service operators and application developers put their minds together, fixing a widespread security problem is possible. That potentially bodes well for a number of other Internet security issues, from the certificate-authority problem to Do Not Track. When concerned parties coordinate their efforts, they can indeed implement change.