On 22/09/15 19:32, Yoav Nir wrote: > >> On Sep 22, 2015, at 8:35 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> >> wrote: >> >> >> >> On 22/09/15 17:23, Tony Arcieri wrote: >>> 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. >> >> 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. So if there >> were a way to help them, that'd be good. And if not, the onus I think >> is on us in this WG to clearly explain why we're removing that feature >> in TLS1.3. >> >> That doesn't have to be text in the TLS1.3 specification but I would >> guess the question may keep coming up, so documenting the answer in >> some archival form (such as an RFC:-) might be a good plan. > > Doesn’t this count?
It does count, but doesn't cover TLS1.3. And it's when TLS1.3 hits the shelves that we'll maybe get more and more folks waking up to the fact that we've removed functionality. (That's not so different to what seems to be happening with HTTP/2 and client-auth maybe.) But yes, text along those lines is what'd be needed. Depending on the overall scope, one might want more self-contained text and less of a dependency on references, not sure. S. > > 3.3. Compression > > > In order to help prevent compression-related attacks (summarized in > Section 2.6 of [RFC7457]), implementations and deployments SHOULD > disable TLS-level compression (Section 6.2.2 of [RFC5246]), unless > the application protocol in question has been shown not to be open to > such attacks. > > Rationale: TLS compression has been subject to security attacks, such > as the CRIME attack. > > (From RFC 7525) > > Sure, we could leave compression in the spec, and recommend that HTTP MUST > NOT use it while NNTP MAY. > > A protocol for multiple use-cases can be either one size fits all, or else > have a bunch of knobs for the different uses. I prefer the one size fits all > approach. > > More specific to compression: people had been using TLS (and SSL) to encrypt > HTTP for over two decades before the CRIME attack. That’s how long it took to > realize that it is dangerous for HTTP. Are people that sure that a similar > issue doesn’t exist for the much less analyzed NNTP? > > Yoav > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
