(The activity on this thread woke me up) On 9 April 2014 00:18, Peter Saint-Andre <stpe...@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 lowered. > 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 follow. Dave.
