[Standards] XEP-0138: security considerations
waqas20 at gmail.com
Mon Apr 14 16:48:28 UTC 2014
On Tue, Apr 8, 2014 at 7:18 PM, Peter Saint-Andre <stpeter at stpeter.im>wrote:
> Before we released the security note about application-layer compression
> last week  (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 ). 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
>  http://xmpp.org/resources/security-notices/uncontrolled-
I have a few minor disagreements with this. The spec is assuming
implementation details here, and is enforcing based on that (with
Consider CRIME, BEAST and similar attacks:
1. The spec is about DoS attacks, which these are not
2. 'MUST NOT enable compression by default' doesn't do anything useful in
particular here, unless we also add "MUST educate admin on BEAST and CRIME
before allowing them to enable". In general, admins frequently go through
server configs enabling things which make sense. Compression makes sense to
most of them. Whether they should or shouldn't do this is a separate
question, but that's what a /lot/ of new admins do.
3. We are kind of assuming that because clients can't be trusted to get
this sort of thing right, servers MUST do this. Why exactly is this not a
recommendation for clients as well?
Consider xmppbomb and other flooding/DoS attacks
1. A server doing anything interesting (e.g., smart dynamic limits based on
currently available resources) shouldn't be disallowed from using resources
that are available and unused. If a server has 100GB of free RAM, no CPU
usage, a client sends a 100MB gzipped payload, which expands into a 1GB
stanza, and is directed to e.g., the client itself, the server should be
allowed to accept it if it deems it reasonable. A better thing to do is to
require mitigation of attacks, but only make suggestions on how to do it.
We shouldn't require specific ways of doing it, not with a MUST. Specs
shouldn't dictate implementation details.
2. To protect clients, a better limit would be on what the server sends on
behalf of users, not on what the server receives, with the goal of
protecting other clients (remember how conference.jabber.org's disco#items
response used to be too large, and got dropped by a lot of federated
3. One interesting case where limits limited a useful stanza was the
conference.jabber.org disco#items response
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards