[Standards] Deprecating XEP-0138: Stream Compression

Peter Saint-Andre - &yet peter at andyet.net
Thu Oct 9 15:06:46 UTC 2014

On 10/9/14, 7:59 AM, Thijs Alkemade wrote:
> Hello all,
> Stream compression is insecure, that was shown with CRIME and BREACH and the
> situation for XMPP isn't much different [1]. I think we should look at the
> easiest way to deprecate XEP-0138 and move to something better.
> Using a "full flush" (in zlib terms) after every stanza would solve the
> problem, as I can't find any realistic examples where an attacker could insert
> their own payload into the same stanza as something secret they want to know.
> However, clients and servers have no way to negotiate a mode like that, so
> it's not possible to reject connections that won't do a per-stanza full flush.
> Reading draft-ietf-hybi-permessage-compression-18, I was happy to see that this
> could be negotiated in WebSocket extension [2].
>  From my own (very small scale) tests with raw XMPP XML, it appears that full
> flushing after every stanza yields about the same compression ratio as
> compressing each stanza separately. Doing that would have a number of
> advantages:
> 1. Not relying on nothing leaking through the "full flush", which may be a
> concept that other compression algorithms than zlib don't have or don't do
> securely enough.
> 2. Practically no memory overhead in the server or client between messages.
> There's no context to keep around, each new message can be decompressed with a
> fresh new context. Memory overhead for compression is a real concern for
> servers: one of the reasons Prosody was pushing for XEP-0138 to replace TLS
> compression was that it's impossible configure the memory use of TLS
> compression to sane levels in OpenSSL.
> However, it also has downsides. It requires either:
> 1. That the concatenation of two compressed stanzas can be separated
> unambiguously.

Could you explain that a bit more? For example, are you talking about 
compressing two stanzas and sending them in the same TCP packet?

> 2. Or that we apply framing outside of compression (which I expect to be
> another can of worms).

Yes, I'd expect so. I recall debates about framing (or the lack thereof) 
for XMPP on this very list from over 10 years ago. ;-)

a> zlib has a header bit that indicates whether a block is the last 
block in a
> stream, but again, that might be zlib-specific.

Would it be worthwhile to investigate what the various compression 
algorithms support here?


Peter Saint-Andre

More information about the Standards mailing list