On 17/11/15 01:43, Daniel Kahn Gillmor wrote: > On Mon 2015-11-16 16:20:21 -0500, Stephen Farrell wrote: >> 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. > > Well, certainly for a system-wide (or application-wide) arbitrary DNS > client it's the same risk.
Similar but not quite the same. Cookies are the main likely target of CRIME but a DPRIVE equivalent can only target the (non-inserted) QNAME (or is there more?), which hasn't quite got the same kind of sensitivity. > We have no way of knowing how many avenues > there are for attackers to be able to make the user make certain DNS > requests to their preferred privacy-preserving resolver. Sure. I would guess the introduction of DPRIVE will change the attack surface and new attacks will be discovered. (Timing may well prove a fertile ground I would guess.) > And since we expect (D)TLS channels to be kept open and reused, that > attacker-controlled data will be touching the same deflate dictionary > that the ostensibly private queries are using. This is the same > scenario as CRIME and BREACH, no? Depends. It is unclear to me why padding doesn't help here, if applied after compression. (Mind you, at that point I don't know why one is bothering with compressing;-) > >>> 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. > > The point here is that if you don't know how the application layer mixes > attacker-controlled data with data that needs to be confidential, TLS > can't possibly do compression safely. But what is the application layer for a system wide stub resolver? Your argument would also imply DNS/DPRIVE can't do compression either. > So while i agree with you that there could be (non-browser) applications > that clearly never mix any attacker-controlled data with > sensitive/private data on the same TLS channel, the only way to know > whether you're in such a state is by reasoning about it *at the > application layer*, which is why that's where the decisions about > compression need to be made. We don't agree about that. I don't think I've seen a convincing argument that's the *only* way to know. (E.g. always emitting fixed size packets in a single write and sending some cover traffic now and then when there's any compression in play would also seem to help, no?) But that's off topic for this list I guess, and may get too complicated before it'd get useful enough. > > anyway, i'm glad we agree on the outcome :) Yep - isn't the entire discussion of compression for DNS pretty moot anyway? It's not clear to me what compressible plaintext there is where compression would be a real benefit. 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
