Re: [dns-privacy] Use of separate caches for plain and secure transports

On Fri, Dec 14, 2018 at 4:05 PM Christopher Wood <
christopherwood07@gmail.com> wrote:

> On Dec 14, 2018, 12:29 PM -0800, Daniel Kahn Gillmor <
> dkg@fifthhorseman.net>, wrote:
>
> On Fri 2018-12-14 11:47:58 -0800, Christopher Wood wrote:
>
> On Dec 14, 2018, 10:47 AM -0800, Wes Hardaker <wes@hardakers.net>, wrote:
>
> [And, no, we shouldn't go down the road of "privacy requires you disable
> the cache"]
>
>
> Would you mind elaborating on this comment? As you observe, caches are
> harmful to privacy. Refusal to disable the cache in any (?)
> circumstance therefore seems dismissive of user privacy. Perhaps you
> mean turning it off for every query is not a viable path forward?
>
>
> I hope Wes will answer this question on his own, but i wanted to note
> that privacy is not only harmed by caches. it can also be helped by
> caches.
>
> A query for any name will typically radiate *less* information into the
> world if it's answered from a cache, simply because the resolver in
> question doesn't create additional traffic.
>
> In particular, if the cache is already well-populated, and queries are
> padded appropriately, and the name is relatively likely to be in-cache,
> then the only parties that know what was looked up are the client and
> the resolver itself. No authoritative servers or network observers have
> any additional information to distinguish the query from any other
> cache-resolved query handled by the resolver.
>
> So i don't think caching itself offers a clear benefit or harm for
> privacy. One advantage of a resolver is that it effectively acts as a
> mixing/semi-anonymizing agent on behalf of its users. Assuming that the
> resolver itself is not compromised, it can buffer its users from the
> authoritative servers.
>
>
> Yes, of course, thanks for clarifying the other piece of this puzzle! This
> is indeed a benefit. However, I am not convinced this yields a greater net
> benefit than disabling caching. (I am not aware of any such study or
> analysis on this problem.) That said, all of this depends entirely upon the
> threat model, which can vary greatly.
>

If you disable the cache, and can see that there is an (encrypted) input
query and then immediately an (encrypted) output query to 208.80.154.238 (
ns0.wikimedia.org) you know with very high likelihood what input query was
for.
If you have a shared cache, there is a much higher likelihood that the
input query gets answered from cache (especially for higher popularity
names) and so there is no output query to correlate with. Techniques which
refresh the cache before the TTL has expired (al la HAMMER) further thwart
correlation attacks.

W

>
> Best,
> Chris
>
>
> --dkg
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf