Subject: [Add] Not looking at DNS privacy in isolation

From: Christian Huitema <[email-masked]>
Date: Mon, 25 Nov 2019 10:01:50 +0800

I would like to make a plea here to not only look at DNS privacy in
isolation, but to consider the combined information disclosure of both
the DNS transactions and the Application transactions, typically a web
transaction.

Consider the typical HTTPS web request starting on a local network, and
resulting in a connection to a web server. Let's assume that the
transaction is using TLS 1.3 and Encrypted SNI. If we do not assume
that, all information would be available to all observers on path, and
there is little advantage using anything but the local resolver.

We can consider three actors: the local network provider, the DNS
resolver, and the web hoster.and that the Each of them will receive some
information about the transaction:

* The local network will see the IP addresses of server and client, and
the name of the fronting server in the "public" SNI. (The same
information is available to all on path observers.)

* The web hoster will see the IP addresses of server and client, as well
as both the public SNI and the hidden SNI, since the web hoster has to
redirect the HTTP request to the selected server.

* The DNS provider will see the IP addresses of the client in the
queries, the name of the fronting server in the A/AAAA request, and the
name of the hidden server in the HTTPSRV request.

If we did not consider the application traffic, we may assume that
selecting a "trusted" DNS resolver is an improvement in DNS privacy. But
if we consider the entire chain, the response may be very different. The
minimal disclosure is achieved if both the A/AAAA requests and the
HTTPSRV request are served by the DNS resolver associated with the web
hoster, because doing so does not leak any information that the web
hoster would not also obtain from the application traffic.

If the resolver of the web hoster is not available or unknown, the
minimal disclosure is obtained by splitting the A/AAAA request and the
HTTPSRV request, because they disclose different information. The A/AAAA
request for the fronting server discloses exactly the information that
is always available to on path observers, and thus minimal disclosure is
achieved by resolving it through the local DNS server. On the other
hand, the HTTPSRV request discloses information that is not visible to
the local network, and thus better privacy is achieved by resolving it
through a "trusted" resolver.

The best result is achieved if in addition to splitting the A/AAAA and
HTTPSRV requests, the client caches the result of the HTTPSRV request,
including the name of the fronting server. That means that the "trusted"
resolver will not know the exact time at which the client establishes
the application connection. Also, the name of the fronting server can be
used to identify the web hoster and the associated DNS resolver, and
thus direct future transactions to that resolver.

So, clearly, we need to not just reason about DNS queries in isolation,
but we should consider both DNS queries and application traffic.

-- Christian Huitema

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 25 Nov 2019 16:52:43 +0100 (CET)

> Il 25 novembre 2019 03:01 Christian Huitema <[email-masked]> ha scritto:
> 

First of all, the "DNS resolver associated with the web hoster" already exists, it is called the "authoritative name server" for the destination domain. So what you have found is that less information is circulated if the user does not adopt any resolver and just does the entire resolution process directly, something which is well known.

But this does not necessarily mean that doing name resolution directly provides more privacy, because by adding a resolver in the middle two things happen:
- the user's request is merged with the requests by many other users, so tracking is much harder than with direct requests (and if the resolver is local to the user's access network, there is no need to add client subnet or other information that might help tracking the specific user);
- in most cases, the user's request will be cached and no information at all will be circulated beyond the local resolver - something that also speeds up the process considerably.

IMHO, the proposals to have each website reply to DNS requests for "its own" domains seem to ignore all the operational wisdom developed by the DNS community in the last thirty years. Possibly they should also explain why that wisdom is not valid any more.

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Christian Huitema <[email-masked]>
Date: Tue, 26 Nov 2019 14:30:48 +0800

> First of all, the "DNS resolver associated with the web hoster" already exists, it is called the "authoritative name server" for the destination domain. So what you have found is that less informat…
Maybe, maybe not. There are many cases in which the CDN, for example,
also acts as authoritative DNS server for the domains. But there are
exceptions.
> - in most cases, the user's request will be cached and no information at all will be circulated beyond the local resolver - something that also speeds up the process considerably.

The privacy issue is two-folds. One side is what can third parties learn
by observing traffic, which is why we really want encrypted DNS
transport, and some of your arguments apply -- although if you consider
both DNS traffic and application traffic you may get a different
picture. The other side is the aggregation of data at the resolver. You
assert that "no information will be circulated beyond the initial
resolver", but that assumes that nobody accesses the resolver logs. The
best privacy posture is achieved when the data is not in the resolver
logs in the first place. The second best is achieved when the
information in the resolver logs provides no additional knowledge over
logs of network traffic. This is why we need to consider both DNS
traffic and application traffic.

> IMHO, the proposals to have each website reply to DNS requests for "its own" domains seem to ignore all the operational wisdom developed by the DNS community in the last thirty years. Possibly they…

You are making an argument about DNS server load and practicality of
some strategies. Yes, overwhelming under-provisioned servers would be
bad. But there are examples where this is not a concern. Cloudflare, for
example, seems happy to serve as DNS resolver for anyone who asks. They
would probably be ready to serve DNS requests for all of the web sites
in the Cloudlflare CDN.

-- Christian Huitema

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 26 Nov 2019 16:45:05 +0000

[JL] As you note parenthetically this is true of any network along the end to end path between the client and the server. From a threat assessment standpoint those non-local network providers may be a greater risk (bumps in the wire), particularly as they are likely unknown to end users (such as transit networks or submarine link providers). So I would recommend you not focus on just a local network but more broadly to any network on the E2E path.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 26 Nov 2019 14:01:19 -0500

otoh the local network is probably responsible for the IP assignment and,
especially when known to the end user, is capable of mapping that directly
to real-life identity and other bits of profile linked to that identity.
This gives them a somewhat unique threat attribute to be considered.

-P

On Tue, Nov 26, 2019 at 11:45 AM Livingood, Jason <
[email-masked]> wrote:

> On 11/24/19, 9:03 PM, "Add on behalf of Christian Huitema" <
> [email-masked] on behalf of [email-masked]> wrote:
> [JL] As you note parenthetically this is true of any network along the end
> to end path between the client and the server. From a threat assessment
> standpoint those non-local network providers may be a greater risk (bumps
> in the wire), particularly as they are likely unknown to end users (such as
> transit networks or submarine link providers). So I would recommend you not
> focus on just a local network but more broadly to any network on the E2E
> path.
>
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 27 Nov 2019 04:59:10 +0800

> [JL] As you note parenthetically this is true of any network along the end to end path between the client and the server. From a threat assessment standpoint those non-local network providers may b…

Jason, my point was really about comparing the additional information
obtained by resolvers at different locations when processing different
kinds of DNS requests. I consider three kinds of resolvers: local
(typically managed by ISP), off path (like the various x.x.x.x), and
near the server (e.g. a Cloudflare server when processing requests for
domains served by Cloudflare's CDN). I also consider two kinds of
requests: A or AAAA, and HTTPSRV used to obtain ESNI data.

For A/AAAA queries, the results are:

1) Local resolvers do not gain any additional information that is not
available on-path already

2) Off-path resolvers gain information that IP address X is querying
fronting server F at time T

3) Server side resolvers do not gain any additional information that is
not available from the servers already.

For HTTPSRV queries, the results are:

1) Local resolvers do gain information that IP address X may be
interested in hidden server H, and can correlate that with later traffic
to fronting server F

2) Off path resolvers do gain information that IP address X may be
interested in hidden server H, but cannot correlate that with later
traffic if they do not also process the later A/AAAA queries

3) Server side resolvers do not gain any additional information that is
not available from the fronting servers already.

As Patrick wrote, local resolvers typically have information correlating
the IP address with the user's identity. Off path resolvers and server
side resolvers may or may not have that information. Off path resolvers
could obtain it if they correlate their logs with tracking data from
advertisement systems. Server side resolvers could obtain that
information from the locally served web sites.

-- Christian Huitema