[Standards] XEP-0138: security considerations

Peter Saint-Andre stpeter at stpeter.im
Tue Apr 8 23:18:09 UTC 2014

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 
   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 




More information about the Standards mailing list