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. 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.
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?
>> 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.
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.
anyway, i'm glad we agree on the outcome :)
--dkg
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
