[Standards] Deprecating XEP-0138: Stream Compression

Florian Schmaus flo at geekplace.eu
Mon Aug 29 07:29:23 UTC 2016

On 29.08.2016 05:29, Sam Whited wrote:
> On Sun, Aug 28, 2016 at 2:53 PM, Mathieu Pasquet <mathieui at mathieui.net> wrote:
>> Two years late, but can we deprecate it XEP-0138 now, lest someones
>> comes along and implements/enables it in their client?
> Though I'm aware of the security risks, stream compression is still
> useful, and may even be necessary in some deployments. Maybe it would
> be better to just expand the security section to explain when stream
> compression might be a risk instead of deprecating the entire (still
> useful) XEP?

Exactly. I don't think that XEP-0138 as whole should be deprecated. Not
every compression mechanism may be vulnerable to the class of attacks.
Even zlib can very likely be made secure by using "full flush". I also
think that the worsened compression ratio by doing so, can be cushioned
by only performing a full flush, i.e. dropping the
dictionary/compression state, if the receiving entity changes.

So instead of

List<StreamElements> outgoingElements = ...

for (StreamElement e : outgoingElements) {
   // Drop compressor state.

we get

List<StreamElements> outgoingElements = ...
Jid lastTo = null;
for (StreamElement e : outgoingElements) {
   if (lastTo != e.getTo()) {
      // Drop compressor state.
   lastTo = e.getTo();

Of course, both entities of an XMPP connection would need to perform
this on their outgoing stream.

I don't think that we will reach consensus on deprecating XEP-0138. But
I think we all agree that the XEP should discuss the known security
issues in the "Security Considerations" section. So instead of focusing
on deprecating the XEP, I suggest we first add this information to the XEP.

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160829/b98737d8/attachment.sig>

More information about the Standards mailing list