[Standards] Stream Compression: When to advertise and allow compression? XEP unclear and clonflicting with itself.
joe.hildebrand at webex.com
Tue Aug 18 17:50:26 UTC 2009
On 8/18/09 11:41 AM, "Tobias Markmann" <tmarkmann at googlemail.com> wrote:
> First of all I wonder what's the reason to allow stream compression only
> after SASL and before binding. XEP-0170  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  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 .
> 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.
>  http://xmpp.org/extensions/xep-0170.html#c2s-compress
>  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.
More information about the Standards