Before we released the security note about application-layer compression
last week [1] (which now seems to have been overshadowed by the
heartbleed bug in OpenSSL), I started to work on some updates to
XEP-0138. Here is my proposed text for the Security Considerations section:
###
7. Security Considerations
Stream encryption via TLS (as defined in RFC 6120) and stream
compression (as defined herein) are not mutually exclusive. However, if
both are used then TLS-layer encryption MUST be negotiated before
negotiation of application-layer compression, so that the stream is
secured first.
Many of the security considerations related to TLS compression (see
Section 6 of RFC 3749) also apply to stream compression.
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:
1. A server implementation MUST NOT turn on compression by default;
instead, it MUST enable a server administrator to turn on compression if
desired.
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.
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.
The last two requirements are consistent with but stronger than
recommendations provided in Section 13.2 of RFC 6120. Failure to provide
such protections opens an implementation denial of service attacks.
###
Your feedback is welcome.
(I have cc'd Giancarlo Pellegrino, who reported the "xmppbomb"
vulnerability; please reply to all so that he can be included in the
conversation.)
Thanks!
Peter
[1]
http://xmpp.org/resources/security-notices/uncontrolled-resource-consumption-with-highly-compressed-xmpp-stanzas/
