On 29.08.2016 05:29, Sam Whited wrote: > On Sun, Aug 28, 2016 at 2:53 PM, Mathieu Pasquet <mathi...@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.
Pseudocode:
-----------
So instead of
List<StreamElements> outgoingElements = ...
for (StreamElement e : outgoingElements) {
socket.write(e);
// Drop compressor state.
socket.fullFlush();
}
we get
List<StreamElements> outgoingElements = ...
Jid lastTo = null;
for (StreamElement e : outgoingElements) {
socket.write(e);
if (lastTo != e.getTo()) {
// Drop compressor state.
socket.fullFlush();
}
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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
