Subject: [hrpc] cases - XMPP

From: Will Scott <[email-masked]>
Date: Wed, 7 Oct 2015 08:42:48 -0700

Hi all,

Here are initial thoughts on analysis of XMPP.
If there are additional aspects you want to flag as potentials for harm,
specific citations you'd like to see, or items here you'd take issue with,
I'd appreciate the feedback.

--Will

XMPP
=====
The Extensible Messaging and Presence Protocol (XMPP), specified in RFC
3920, provides a standard for interactive chat messaging, and has evolved
to encompass interoperable text, voice, and video chat. The protocol is
structured as a federated network of servers, similar to email, where users
register with a local server which acts one their behalf to cache and relay
messages. This protocol design has many advantages, allowing servers to
shield clients from denial of service and other forms of retribution for
their expression, and designed to avoid central entities which could
control the ability to communicate or assemble using the protocol.

None-the-less, there are plenty of aspects of the protocol design of XMPP
which shape the ability for users to communicate freely, and to assembly
through the protocol. In addition to issues of user registration and a lack
of protocol specification of the registration policy, the protocol also has
facets that may stifle speech as users self-censor for fear of
surveillance, or find themselves unable to express themselves naturally.

User Identification
------
The XMPP specification specifies that clients are identified with a
resource (<node@domain/home> / <node@domain/work>) to distinguish the
conversations to specific devices. This has the side effect of enabling
tracking of user behavior by a remote friend or server, who are able to
track presence not only of the user, but of each individual device. This
has proven to be misleading to many users, since many clients only expose
user level rather than device level presence. Likewise, user invisibility
so that communication can occur while users don’t notify all buddies and
other servers of their availability is not part of the formal protocol, and
has only been added as an extension within the XML stream rather than
enforced by the protocol.

Documentation of this form of harm:
[1] https://developer.pidgin.im/ticket/4322

Character Encoding
-----
Localization is a source of frustration in many protocols, and appears in
some forms of XMPP. The XMPP protocol specifies a requirement for UTF-8 and
UTF-16 support [1], though documentation admits that many implementations
may not support UTF-16 [2]. In practice, this leads to cases where text
encoded outside of a standard english language ascii encoding will fail to
render on all clients, limiting the ability of users to communicate in
their native languages. Some examples are failure of XMPP servers to handle
non-ascii passwords [3], and gateways which simply strip all non-ascii from
the conversation stream.

At the protocol level, XMPP only defines the conversation as an XML block,
and leaves the implementation of character sets to the XMPP parsers of each
individual client and server. While there have been attempts to define
UTF-16 support as part of the protocol specification, the lack of actual
implementation of the more extensible character set by all clients has
shaped the protocol to harm the full range of expression users may desire.

Documentation of this form of harm:
[1] http://mail.jabber.org/pipermail/xmppwg/2003-August/001460.html
[2]
http://xmpp.org/rfcs/rfc6120.html#streams-error-conditions-unsupported-encoding
[3] https://support.process-one.net/browse/EJAB-476
[4] https://wiki.bitlbee.org/HowtoFacebookXMPP

Surveillance of Communication
-----
The XMPP protocol specifies the standard by which communication of channels
may be encrypted, but it does not provide visibility to clients of whether
their communications are encrypted on each link. In particular, even when
both clients ensure that they have an encrypted connection to their XMPP
server to ensure that their local network is unable to read or disrupt the
messages they send, the protocol does not provide visibility into the
encryption status between the two servers. As such, clients may be subject
to selective disruption of communications by an intermediate network which
disrupts communications based on keywords found through Deep Packet
Inspection.

In particular, section 13.14 of the protocol specification [2] explicitly
acknowledges the existence of a downgrade attack where an adversary
controlling an intermediate network can force the inter domain federation
between servers to revert to a non-encrypted protocol were selective
messages can then be disrupted.

Documentation of this form of harm:
[1] https://raw.githubusercontent.com/stpeter/manifesto/master/manifesto.txt
[2] https://www.ietf.org/rfc/rfc6120.txt

Group Chat Limitations
-----
Group chat in the XMPP protocol is defined as an extension within the XML
specification of the XMPP protocol [1]. However, it is not encoded or
required at a protocol level, and not uniformly implemented by clients.

The design of multi-user chat in the XMPP protocol suffers from extending a
protocol that was not designed with assembly of many users in mind. In
particular, in the federated protocol provided by XMPP, multi-user
communities are implemented with a distinguished ‘owner’, who is granted
control over the participants and structure of the conversation.

Multi-user chat rooms are identified by a name specified on a specific
server, so that while the overall protocol may be federated, the ability
for users to assemble in a given community is moderated by a single server.
That server may block the room and prevent assembly unilaterally, even
between two users neither of whom trust or use that server directly.

[1] http://xmpp.org/extensions/xep-0045.html

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 12 Oct 2015 13:37:39 +0200

On Wed, Oct 07, 2015 at 08:42:48AM -0700,
 Will Scott <[email-masked]> wrote 
 a message of 241 lines which said:

> 3920,

No, 6120.

> a lack of protocol specification of the registration policy,

It is a feature, not a bug: every server has its own policy (from "no
registration allowed" on IETF XMPP server, to very lax).

> resource (<node@domain/home> / <node@domain/work>) to distinguish
> the conversations to specific devices. This has the side effect of
> enabling tracking of user behavior

Nothing mandates that the resource is a location, or that it is
understandable from the outide (the relevant RFC is RFC 7622, section
3.4). It is true that resources like "home" or "work" appear often in
the documentations and even in some RFC. A possible improvment would
be a privacy considerations section in the successor of RFC 7622,
warning of this risk.

> In practice, this leads to cases where text encoded outside of a
> standard english language ascii encoding will fail to render on all
> clients,

I do not see the relationship between this problem and the UTF-8
vs. UTF-16 issue.

> Some examples are failure of XMPP servers to handle non-ascii
> passwords [3],

Certainly, the users want to communicate in their own script (not
language: IETF protocols don't know languages). But it is less evident
that they want passwords in Unicode (see RFC 7613). I would say it is
a problem but a much less severe one.

> and gateways which simply strip all non-ascii from the conversation
> stream.

Gateways between protocols are notorious for mangling. It is unfair to
blame it on XMPP.

> the lack of actual implementation of the more extensible character
> set by all clients has shaped the protocol to harm the full range of
> expression users may desire.

I'm not sure I understand this sentence (UTF-16 is certainly not "more
extensible"). If I do, it makes no sense to me, since UTF-8 and UTF-16
can encode exactly the same character set (Unicode).

> The XMPP protocol specifies the standard by which communication of
> channels may be encrypted, but it does not provide visibility to
> clients of whether their communications are encrypted on each link.

This, and the fact that there is no standard end-to-end encryption,
meaning that a rogue server knows the conversation.

This could be a place to mention OTR (and to note it is poorly
integrated in XMPP).

---

From: Niels ten Oever <[email-masked]>
Date: Mon, 12 Oct 2015 14:00:33 +0200

> This, and the fact that there is no standard end-to-end
> encryption, meaning that a rogue server knows the conversation.
> 

As well as the lack of the opportunity for secure multi party
encryption / messaging  with XMPP + OTR.

https://www.ietf.org/blog/tag/otr/

Best,

Niels