Hi all,
> If compression is so important to NNTP, they should add first-class
support. Period. They should not be relying on a poorly conceived
feature which has been repeatedly demonstrated to introduce
vulnerabilities in what is supposed to be a *security protocol* just
because they don't want to implement compression themselves.
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.
[Stephen]
Compression does have issues clearly, but it's not correct to
describe people wanting TLS to compress as lazy. They're rather
looking for the same features that TLS has offered for a couple of
decades.
The good news is that the "first-class" NNTP compression support will
soon be a reality. We've updated the draft of the COMPRESS command, and
we hope to publish it as an RFC:
https://tools.ietf.org/html/draft-murchison-nntp-compress-02
Interoperability is proven: both a news client (flnews) and a news
server (INN) have implemented it.
As far as security is concerned, authentication MUST be done *before*
activating the compression layer (in other words, AUTHINFO is no longer
valid after a successful use of COMPRESS).
Thanks again guys for having put us to work on that NNTP extension!
--
Julien ÉLIE
« Aequum est ut cuius participauit lucrum, participet et damnun. »
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
