I think there is a compression extension for NNTP: http://tools.ietf.org/id/draft-murchison-nntp-compress-01.html
it doesn't seem too hard. My 2c: even if this were not the case, optimizing NNTP in a backwards compatible way does seem like a more important goal than making transport security as secure as possible by default. On Tue, Sep 22, 2015 at 12:44 PM, Yoav Nir <ynir.i...@gmail.com> wrote: > > > On Sep 22, 2015, at 9:40 PM, Salz, Rich <rs...@akamai.com> wrote: > > > > The security community thinks that compression is risky, error-prone, > and that a security/auth layer is the wrong place to put it. > > > > So far, the only counter-argument has been "if TLS 1.2 has a flaw, I > want to move to TLS 1.3 without losing data compression." > > > > Is this accurate? > > I think the other counter-argument is that modifying NNTP to have a > compression feature is hard, whereas updating the TLS library is something > that implementations are likely to do. > > I have to wonder if it’s worth it. In the last decade bandwidth has > increased and prices for networking have gone down much faster than CPU > speeds. 10 years ago having 1 Mbps at home was the highest-end broadband > you could get. Now you routinely get 100x that. CPU has increased, but > nowhere near that. This makes compression less desirable, to the point that > people did not complain much when browser vendors removed compression > following the CRIME attacks. True, the rise of mobile brought back limited > bandwidth, but is this really an issue? > > Yoav > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
