[Standards] Deprecating XEP-0138: Stream Compression

Dave Cridland dave at cridland.net
Mon Aug 29 11:12:48 UTC 2016

On 29 Aug 2016 04:30, "Sam Whited" <sam at samwhited.com> wrote:
> On Sun, Aug 28, 2016 at 2:53 PM, Mathieu Pasquet <mathieui at mathieui.net>
> > 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?

Very much agree. Where radio is used, for example, encryption can be
applied at the link layer, fully padded, which defeats all such attacks. In
other cases, the general approach of stimulating known traffic from a
particular entity can be used to gain information even in the absence of
compression. As examples, you can determine if a particular client is in a
chatroom by sending traffic to that chatroom, for example.

My understanding of the attacks is that they leak metadata, in XMPP, rather
than credentials as in HTTP - and they still require the ability to both
stimulate traffic and observe the full packet flow.

> —Sam
> --
> Sam Whited
> pub 4096R/54083AE104EA7AD3
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160829/c6d6bd8e/attachment.html>

More information about the Standards mailing list