On Tue, Apr 8, 2014 at 7:18 PM, Peter Saint-Andre <stpe...@stpeter.im>wrote:
> 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/ > I have a few minor disagreements with this. The spec is assuming implementation details here, and is enforcing based on that (with MUST-level statements). 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 servers?) 3. One interesting case where limits limited a useful stanza was the conference.jabber.org disco#items response -- Waqas Hussain
