On Mon, Oct 20, 2014 at 6:10 PM, Paul Vixie <[email protected]> wrote:

>
>  query minimization i see no benefit or need for secrecy since dns is a
> publication system -- if you don't want people to see your information,
> don't put it into the dns. cache miss transactions (#2 above) expose only
> server IP addresses, not end-user IP addresses, and no re-use events. as
> such it has always been my position that there is no PII and no privacy
> impact from having these recorded and analyzed. i would not like to see the
> IETF work in that area.ld be classified into:
>

At the STRINT workshop, we discussed the extent to which combining queries
at a proxy provides protection against analysis by a monitor.  It is
certainly the case that it provides some benefit, but we there are limits,
especially when the resolver serves a relatively small number of users.

To take an example:  Joe belongs a club, example.org, and is using their
network to look up a sensitiveblog.journal.example.  example.org hosts it
own DNS resolver, but few users connect to journal.example (having mostly
moved to face-example.org), so when Joe makes his look up, it's a cache
miss.  A surveillance entity will therefore see
sensitiveblog.journal.example as a target of the DNS query if it has a tap
on path between example.org and journal.example, and it now knows that the
traffic between example.org and journal.example is for the senstiveblog.

Note that it would not necessarily have known that otherwise.  Because
journal.example uses the HOST header to disambiguate traffic to different
hosted journals, thus consuming a very small number of IP addresses, the
connection itself would not have identified which blog was at issue. [There
are other potential sources of leaks, here, such as the unencrypted SNI in
TLS, but that has to be worked elsewhere.  I do not personally accept the
idea that we can't fix information leakage piece by piece, just because
other leaks are possible].

Clearly, had Joe used OpenDNS, Google's DNS, or a large ISP DNS service
which aggregates many more users, the chance of a cache miss would be lower
and the correlation would be much, much harder even in the case of a cache
miss.   But the DNS protocol cannot presume that sort of deployment, and
they have other consequences in terms of trust between users and large
services.

As long as the DNS continues to support deployment of recursive resolvers
in topologies that cannot effectively provide aggregation as a mitigation,
I believe that the recursive to authoritative problem should stay on the
table.  It is a lower priority, but it is a valuable piece of work.  I
personally also think that it is a substantially different problem from the
stub to recursive resolver problem, so we should treat them independently.

My two cents, in any case.

Ted Hardie
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy

Reply via email to