On 8/18/09 11:41 AM, "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. I think the DoS potential was because starting up a compression instance might be resource-intensive. Allowing those resources to be consumed before authentication was deemed a bad idea. > 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 This could be clearer, perhaps by removing the first "not". The intent is that compression happens before any type of encryption, since compressing ciphertext is unlikely to be useful. If you do TLS, SASL, then Compression, this is always the case. -- Joe Hildebrand
