Hi Tony,
Keeping compression in TLS endorses unsafe usage of a feature known
to introduce compression sidechannels.
Whether other protocols decide to introduce their own secondary
compression layer is their own prerogative. But an unsafe feature
shouldn't be kept in TLS just because some protocols want to do unsafe
things and are too lazy to implement their own compression.
What for protocols that aren't subject to unsafe usage and that were
relying on the compression facility provided by TLS?
Unconditionally removing TLS compression leads to a regression for them.
As others already mentioned in this list, even with NNTP we can use a
safe SASL mechanism to authenticate. No password sent in plain-text.
Regarding vulnerable protocols, clients (and/or servers) could very well
disable compression in TLS. And either never use compression or
implement their own compression, according to their needs.
It is what happened with BEAST: Firefox and Chrome disabled TLS
compression.
--
Julien ÉLIE
« Tant qu'il y a des marmites, il y a de l'espoir ! » (Astérix)
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
