Network Working Group P. Saint-Andre
Internet-Draft XMPP Standards Foundation
Intended status: Standards Track January 15, 2014
Expires: July 19, 2014
STRINT Workshop Position Paper: Strengthening the Extensible Messaging
and Presence Protocol (XMPP)
draft-saintandre-strint-workshop-xmpp-00
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 19, 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.
Saint-Andre Expires July 19, 2014 [Page 1]
Internet-Draft STRINT XMPP January 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 3
4. Per-Hop Encryption . . . . . . . . . . . . . . . . . . . . . . 3
5. End-to-End Encryption . . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Saint-Andre Expires July 19, 2014 [Page 2]
Internet-Draft STRINT XMPP January 2014
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). 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
Saint-Andre Expires July 19, 2014 [Page 3]
Internet-Draft STRINT XMPP January 2014
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:
o The lack of TLS protection was not as visible to end users or
server administrators.
o Several major XMPP services did not offer or negotiate TLS over
server-to-server streams.
o 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
Saint-Andre Expires July 19, 2014 [Page 4]
Internet-Draft STRINT XMPP January 2014
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
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 formalized through
a standards development organization. However OTR is the most widely
implemented.
6. IANA Considerations
This document requests no actions of the IANA.
7. Security Considerations
This entire document discusses security.
8. References
8.1. Normative References
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Saint-Andre Expires July 19, 2014 [Page 5]
Internet-Draft STRINT XMPP January 2014
Security (TLS)", RFC 6125, March 2011.
8.2. Informative References
[I-D.ietf-dane-srv]
Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
Based Authentication of Named Entities (DANE) TLSA records
with SRV and MX records.", draft-ietf-dane-srv-03 (work in
progress), December 2013.
[I-D.ietf-xmpp-dna]
Saint-Andre, P. and M. Miller, "Domain Name Associations
(DNA) in the Extensible Messaging and Presence Protocol
(XMPP)", draft-ietf-xmpp-dna-04 (work in progress),
October 2013.
[I-D.meyer-xmpp-e2e-encryption]
Meyer, D. and P. Saint-Andre, "XTLS: End-to-End Encryption
for the Extensible Messaging and Presence Protocol (XMPP)
Using Transport Layer Security (TLS)",
draft-meyer-xmpp-e2e-encryption-02 (work in progress),
June 2009.
[I-D.miller-posh]
Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP
(POSH)", draft-miller-posh-03 (work in progress),
November 2013.
[I-D.miller-xmpp-e2e]
Miller, M., "End-to-End Object Encryption and Signatures
for the Extensible Messaging and Presence Protocol
(XMPP)", draft-miller-xmpp-e2e-06 (work in progress),
June 2013.
[RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption
for the Extensible Messaging and Presence Protocol
(XMPP)", RFC 3923, October 2004.
[XEP-0027]
Muldowney, T., "Current Jabber OpenPGP Usage", XSF
XEP 0027, November 2006.
[XEP-0116]
Paterson, I., Saint-Andre, P., and D. Smith, "Encrypted
Session Negotiation", XSF XEP 0116, May 2007.
[XEP-0220]
Miller, J., Saint-Andre, P., and P. Hancke, "Server
Saint-Andre Expires July 19, 2014 [Page 6]
Internet-Draft STRINT XMPP January 2014
Dialback", XSF XEP 0220, September 2013.
Author's Address
Peter Saint-Andre
XMPP Standards Foundation
Email: ietf@stpeter.im
Saint-Andre Expires July 19, 2014 [Page 7]