[Standards] XEP-0138: security considerations

Dave Cridland dave at cridland.net
Sun Apr 27 09:25:35 UTC 2014

(The activity on this thread woke me up)

On 9 April 2014 00:18, Peter Saint-Andre <stpeter at stpeter.im> wrote:

> Several attacks against TLS-layer and application-layer compression have
> been found, including the CRIME and BEAST attacks (see
> draft-sheffer-uta-tls-attacks [7]). Mitigation for the CRIME attack
> involves disabling TLS-layer compression. At the time of this writing
> (early 2014), there are no general mitigations against the BEAST attack.
> However, the following safeguards are appropriate:
By BEAST, do you mean BREACH? BEAST seems to be relating to predictable IV.

So both the BREACH class, and the TIME/CRIME attacks, are framed as purely
HTTP cases. This is complicating the issue, because I think while they do
affect XMPP, they do so in radically different ways.

An attacker in HTTP can control the traffic between a browser and a web
server essentially only via javascript injection. In XMPP, an attacker
could simply send messages to the attack target. However, there'll be
complications because to have value, an attacker needs to inject their
messages within a "flowing" stream of traffic, yet also identify which are
their messages and which are the target data. I suspect this is hard, and
though it might be possible, the level of fine control these attacks
actually need will be very difficult to obtain.

>   1. A server implementation MUST NOT turn on compression by default;
> instead, it MUST enable a server administrator to turn on compression if
> desired.

The second MUST here seems odd. If a server supports compression, it
absolutely has to allow it to be enabled?

Perhaps "A server implementation MUST NOT enable compression by default,
only enabling it by explicit configuration".

I'm not convinced this is actually a MUST here - as I say above, I suspect
the attacks are very different within XMPP and the effectiveness will be

>   2. A server implementation MUST enable a server administrator to limit
> the size of stanzas it will accept from a connected client or peer server,
> and also MUST set a reasonable default limit of at least 10,000 bytes. In
> general, it is reasonable for the maximum stanza size to be the same as the
> size of the buffer passed to zlib when storing uncompressed data.

I think this has walked too far from its remit. I think this is trying to
protect against "xmppbomb", but this seems unlikely to be quite right. I
think what it wants is to say that when compression is enabled, the
decompression buffers MUST have a hard limit; though MUST is too strong
here - there are other ways of protecting against this.

>   3. A server implementation MUST enable a server administrator to limit
> the amount of bandwidth it will allow a connected client or peer server to
> use in a given time period.
I think this is flat-out wrong. It is one mitigation against an attack (or,
actually, abuse pattern) that is not referenced in the security
considerations as proposed, nor related to compression in any way I can

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140427/25573005/attachment.html>

More information about the Standards mailing list