[Standards] Deprecating XEP-0138: Stream Compression

Thijs Alkemade thijs at xnyhps.nl
Thu Oct 9 13:59:20 UTC 2014


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.

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

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

Thoughts? Comments?

Best regards,
Thijs Alkemade

[1] https://blog.thijsalkema.de/blog/2014/08/07/https-attacks-and-xmpp-2-crime-and-breach/
[2] https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-18#section-8.1.1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.jabber.org/pipermail/standards/attachments/20141009/e031c723/attachment.sig>


More information about the Standards mailing list