On Tue, Aug 18, 2009 at 7:41 PM, Tobias Markmann<tmarkm...@googlemail.com> wrote: > Howdy, > First of all I wonder what's the reason to allow stream compression only > after SASL and before binding. XEP-0170 [1] says it's that way to prevent > certain denial of service attacks but doesn't clarify it any further. So I'm > asking myself what kind of attacks that are. Because some clients and > servers, which implemented stream compression before XEP-0170 was there do > compression only before SASL.
Compressing an encrypted stream is simply pointless: encryption maximizes entropy, so you can't have any gain but consuming resources. > Secondly, XEP-138 [2] says, >> >> Because negotiation of stream compression should not be completed after >> application of any encryption layers and because SASL negotiation (see RFC >> 3920) may involve application of an encryption layer, stream compression >> SHOULD be negotiated after SASL negotiation. For detailed recommendations >> regarding the order of stream feature negotiation, refer to Recommended >> Order of Stream Feature Negotiation [4]. > > in its Business Rules section. The first sentence contradicts the second > one. The first disallows the use of stream compression when an encryption > layer is present however the second, forwarding to XEP-170, precisely > describes when to allow stream compression even after TLS has be negotiated. > [1] http://xmpp.org/extensions/xep-0170.html#c2s-compress > [2] http://xmpp.org/extensions/xep-0138.html#bizrules If TLS starts, but if fails negotiating internal compression, the server may still offer compression, in order to compress the xml stream which is subsequently encrypted. bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
