[Standards] Stream Compression: When to advertise and allow compression? XEP unclear and clonflicting with itself.

Fabio Forno fabio.forno at gmail.com
Tue Aug 18 19:09:55 UTC 2009


On Tue, Aug 18, 2009 at 7:41 PM, Tobias
Markmann<tmarkmann at 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: ff at jabber.bluendo.com



More information about the Standards mailing list