Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Peter Saint-Andre
Last updated 2014-01-23
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-saintandre-strint-workshop-xmpp-01
Network Working Group                                     P. Saint-Andre
Internet-Draft                                 XMPP Standards Foundation
Intended status: Standards Track                        January 23, 2014
Expires: July 27, 2014

 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.

Saint-Andre               Expires July 27, 2014                 [Page 1]
Internet-Draft                 STRINT XMPP                  January 2014

Table of Contents

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

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

Saint-Andre               Expires July 27, 2014                 [Page 2]
Internet-Draft                 STRINT XMPP                  January 2014

   The discussion venue for this document is the PERPASS mailing list,
   for which archives and subscription information can be found at [1].

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:

   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

Saint-Andre               Expires July 27, 2014                 [Page 3]
Internet-Draft                 STRINT XMPP                  January 2014

   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 [2].  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

Saint-Andre               Expires July 27, 2014                 [Page 4]
Internet-Draft                 STRINT XMPP                  January 2014

   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

   [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
              Security (TLS)", RFC 6125, March 2011.

8.2.  Informative References

   [I-D.ietf-dane-srv]

Saint-Andre               Expires July 27, 2014                 [Page 5]
Internet-Draft                 STRINT XMPP                  January 2014

              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.

   [I-D.trammell-perpass-ppa]
              Trammell, B., Borkmann, D., and C. Huitema, "A Threat
              Model for Pervasive Passive Surveillance", draft-trammell-
              perpass-ppa-01 (work in progress), November 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
              Dialback", XSF XEP 0220, September 2013.

Saint-Andre               Expires July 27, 2014                 [Page 6]
Internet-Draft                 STRINT XMPP                  January 2014

Author's Address

   Peter Saint-Andre
   XMPP Standards Foundation

   Email: ietf@stpeter.im

Saint-Andre               Expires July 27, 2014                 [Page 7]