[Standards] Deprecating XEP-0138: Stream Compression
mathieui at mathieui.net
Tue Aug 30 00:05:54 UTC 2016
On Mon, Aug 29, 2016 at 09:29:23AM +0200, Florian Schmaus wrote:
> 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.
> 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
I was reminded about the XEP while browsing PIFT , and while
wondering if I should implement/enable it, I had a faint memory about
security issues concerning compression. So, while searching my inbox for
clues, I found this thread which didn’t evolve since 2014.
I would be happy with a substantial update to the security
considerations as well. Actually, if 0138 implementations were limited
to the platforms described in the XEP introduction, it wouldn’t be an
issue at all, which is why I agree that deprecacting the XEP might be
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the Standards