Hiya, On 16/11/15 21:05, Daniel Kahn Gillmor wrote: > On Mon 2015-11-16 11:32:57 -0500, Shane Kerr wrote: >> Probably a paragraph saying "turn off TLS compression" is a better >> approach than trying to figure out how to defeat the compression? > > yes, please. The consensus of the TLS WG is that compression simply > does not belong at the TLS layer, that it was a mistake to put it there > in the first place, and that it will not be supported in the future.
I agree that that is clearly the opinion in the TLS WG today. I'm less sure I agree that's correct - my fear is that it's being driven maybe too much by browsers and the web, where the conclusion is valid. > > Any attempt at compression needs to happen at the application layer > itself with full knowledge of the risks and tradeoffs. FWIW, I don't agree with the above, I think it's generalising too much from the browser use-case. > This implies that > if DNS cares about compression, it needs to write DNS-specific > compression rules, and those rules themselves need to clearly grapple > with what to do with packet padding when DNS-specific compression is > used. > > I'm not proposaing that the DNS community do any sort of work on > compression right now. We just need a simple statement that padding is > only expected to be useful against traffic analysis under encrypted > and non-compressed connections. I agree with the above though, so we end up in the same place:-) I think for DPRIVE it could perhaps be enough to say that any padding ought only be done after compression, if compression is done at all. And of course padding is only of use if the data is encrypted before transmission. Cheers, S. > > --dkg > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy > _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
