[Standards] Stream Compression: When to advertise and allow compression? XEP unclear and clonflicting with itself.
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:
> 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.
Compressing an encrypted stream is simply pointless: encryption
maximizes entropy, so you can't have any gain but consuming resources.
> 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
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.
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com
More information about the Standards