Subject: Re: [Add] draft-arkko-abcd-distributed-resolver-selection

From: "Chris Box (BT)" <[email-masked]>
Date: Fri, 20 Mar 2020 18:22:06 +0000

Ted, Jari, Martin,

In preparation for the first presentation on Tuesday, I've had another look
through your draft and it's raised some questions in my mind.

Section 3 introduces the premise that the client selects a set of trusted
resolvers, excluding all less trusted ones. It doesn’t really say this, but
I think each resolver in the set needs to be operated by a different party,
otherwise the activity seems to be pointless. Do you agree?

If you do, the premise implies the set must include at least one resolver
NOT operated by the provider of the local network.

We then get onto the problem briefly mentioned in section 6.2, namely
   different resolvers might have different policies with
   respect to blocking or filtering of queries that lead to clients
   receiving inconsistent answers

If I compare the above to the set of perspectives outlined in ICANN SAC109,
my expectation is that the resulting net change in the ability to meet
their needs is as follows:

4.1 (Parents):  Negative
4.2 (Enterprise Network Managers):  Negative
4.3 (Dissidents, Protesters and Others):  Positive
4.4 (Internet Service Providers):  Negative

Would you agree with this assessment? Or have I missed something crucial?

I'm normally optimistic so let's assume there is a way to mitigate the
negatives. Let’s now focus on whether the impact to privacy is always
positive. I think there is a case where it may be weaker than the status
quo.

Imagine a normal residential home. This one has five different wifi
clients, with a single recursive resolver (A) outside the home, on the
internet. This is shown below (apologies to anyone reading the plain text
version).

Resolver A sees the merged traffic of all 5 clients, coming from a single
IP address.

With the client-based selection mode (section 4.1), and two resolvers
chosen (A and B), those resolvers can learn more data about the specific
clients:
Of course A can individually separate clients 1, 3 and 5, because even
though they share an IP address, they've all set up separate TLS sessions.

Is this is a legitimate privacy issue?

I would be grateful for your thoughts, either on the list or during the
presentation on Tuesday. And if anyone on the list has a view, particularly
if there is a way to modify the text such that negative impacts can be
reduced, that would be most valuable.

Thanks,
Chris

On Tue, 25 Feb 2020 at 18:01, Ted Hardie <[email-masked]> wrote:

> Howdy,
>
> Jari, Martin, and I put together
> draft-arkko-abcd-distributed-resolver-selection
> <https://datatracker.ietf.org/doc/draft-arkko-abcd-distributed-resolver-selection/?include_text=1> to
> start a discussion on whether DNS clients can improve their privacy through
> the use of a set of multiple recursive resolver services.  We think it
> might be in scope for ADD, since the charter says the group "will focus on
> discovery and selection of DNS resolvers" and this discusses the impact of
> selecting more than one.
>
> Do the chairs and the working group agree?  If so, can we ask for agenda
> time at IETF 107 to present?
>
> thanks,
>
> Ted
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 20 Mar 2020 14:23:37 -0700

Hi Chris,

Thanks for the review.  Replies in-line.

On Fri, Mar 20, 2020 at 11:22 AM Chris Box (BT) <[email-masked]>
wrote:

> Ted, Jari, Martin,
>
> In preparation for the first presentation on Tuesday, I've had another
> look through your draft and it's raised some questions in my mind.
>
> NOT operated by the provider of the local network.

If you look at section 4.1, you'll see that one of the strategies is "to
distribute each different client to a different resolver."  If the client's
trusted set includes the local network resolver, it might well be
associated with that network.    Because this strategy is focused on the
aggregate distribution of DNS queries, there are a lot of cases where the
local network being trusted means the current association methods don't
actually change for some clients.

>    receiving inconsistent answers
If you put resolvers with different policies into the trusted set, that can
happen.  If the resolvers are transparent about their policies, this seems
less likely to happen, because you will put resolvers into the set only
when you are both confident of their privacy-preserving behavior and that
their policies match your desires.

> If I compare the above to the set of perspectives outlined in ICANN
> SAC109, my expectation is that the resulting net change in the ability to
> meet their needs is as follows:
>
> 4.1 (Parents):  Negative
I'm not familiar enough with SAC 109 to comment, so I'll leave that to
others.  My personal belief is that the ability to choose what resolvers
belong in the set is important enough that it should map to the client's
controller (which might be an individual, the parent of child, the
enterprise owner of an employee device).

> though they share an IP address, they've all set up separate TLS sessions.
I find your graphic a bit confusing, because you are not treating the stub
resolver in the home router as if it were a part of the calculus here.  If
I understand things correctly, if those clients were actively choosing to
use a resolver here (rather than taking one by association), they would be
choosing the home router, rather than A (let's call the home router
resolver H).  They presumably believe H has policies that match the ones
they prefer; A is opaque to them.  But H sees the traffic of all five
clients; that's the common trade-off there.

> Is this is a legitimate privacy issue?
As I said, there are trade-offs here.  In any case where your query traffic
goes to a recursive resolver, the number of clients sharing that resolver
increases the anonymity set for traffic analyzed upstream of that
resolver.  In your first example, because your A is upstream of H, H's
clients get an anonymity set size of 5 with respect to A.  In your example
two, for traffic analyzed upstream of A or B, the anonymity set size is
likely to be much higher, but the tradeoff is that that A (or B) has a more
direct view of a larger number of clients.

> reduced, that would be most valuable.
thanks again for the review,

Ted

---

From: Rob Sayre <[email-masked]>
Date: Fri, 20 Mar 2020 20:11:40 -0700

> though they share an IP address, they've all set up separate TLS sessions.

Is this detailed enough? I'm not sure what you mean by "client", since each
client could be one computer with multiple resolvers. For example, Firefox
could be pointed at Cloudflare, while the system uses whatever DHCP says.
That is certainly what my MacBook does.

More subtly, the second diagram avoids all sorts of security problems along
the path to the resolvers. A very common one is compromised home routers.

thanks,
Rob

---

From: "Chris Box (BT)" <[email-masked]>
Date: Sat, 21 Mar 2020 16:31:55 +0000

Hi Ted,

Thanks for responding. Let's take a look:

> actually change for some clients.

To clarify, we're talking here about the case where the client's trusted
set consists of these two:
* The local resolver
* A more distant resolver

These two are operated by different parties. I agree that in strategy 4.1,
sometimes it will exclusively use the local resolver, and this means no
change in behaviour. Other times it will not.  In the general case, clients
use a mixture of the two.

> their policies match your desires.

Given that the resolvers within the set are operated by different parties,
I would say it's extremely likely that their privacy policies will have
non-identical wording, and consequently different semantics. As a user it's
already hard enough to read one privacy policy and satisfy yourself it's
ok. To have to do this more than once is quite a (human) challenge.

> enterprise owner of an employee device).

I will suggest it’s worth a read, as the issues are complex enough that
they can’t be solved by requiring administrative control of the client.

> clients; that's the common trade-off there.

Yes H could be part of the set, but since this draft is about using
multiple resolvers it would not be the only one. There must be at least one
remote resolver.

I had drawn it using two remotes (A & B), but if instead it was one remote
(H & A), the same issue applies. Resolver A can individually discriminate
between all the clients who are contacting it. Compare this with the status
quo, where H is the sole intermediary, and remote recursive resolvers do
not obtain that fine-grained client identification.

> As I said, there are trade-offs here.  In any case where your query
> traffic goes to a recursive resolver, the number of clients sharing that
> resolver increases the anonymity set for traffic analyzed upstream of that

Yes, we agree with the more direct view of the clients. I wasn't really
thinking about upstream of the recursives, but yes on that side, the larger
the number of clients using A, the more anonymity. For a large ISP, this
can be well into the millions.

Thanks,
Chris

---

From: Rob Sayre <[email-masked]>
Date: Sat, 21 Mar 2020 22:12:04 -0700

> 4.2 (Enterprise Network Managers):  Negative

Items 4.1 and 4.2 are pretend security.  Just take a Google Pixel phone and
turn on the built-in VPN.

I know some people will jump in and say "but the regulators!". That is both
off-topic for this list, and ultimately contemptuous of whomever they think
will buy that line.

> 4.3 (Dissidents, Protesters and Others):  Positive

I would say neutral, since they probably don't rely on clear text DNS.

> 4.4 (Internet Service Providers):  Negative

Why would that be?

thanks,
Rob

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 23 Mar 2020 12:29:11 +0100 (CET)

>     Il 20/03/2020 22:23 Ted Hardie <[email-masked]> ha scritto:
> 
> 
>         > > 
>     If you put resolvers with different policies into the trusted set, that can happen.  If the resolvers are transparent about their policies, this seems less likely to happen, because you will put resolvers into the set only when you are both confident of their privacy-preserving behavior and that their policies match your desires.
> 
Assuming that "you" in your sentence is the end-user and not the client, it is hard to think that this approach can work in practice for the ordinary user; as a minimum, as suggested by other drafts, there should be an automated, standardized way for resolvers to describe their policies and for clients to retrieve them and match them against the user's preferences, without requiring the user to go through legalese terms & conditions every time they want to add/accept a new resolver into the set (though there might be a legal requirement that they do anyway).

In the absence of that, it would be likely that the user only went through the hassle of vetting and adding a new resolver for two or three times, which could easily frustrate the privacy properties of the concept and in fact bring forth more centralization and more opportunities for user tracking.

(By the way, the draft seems to lack a proper "Privacy Considerations" section, is it still in the making? That could be a place to record this discussion.)

In addition, the above approach does not work for adversarial filtering, i.e. the one done according to legal/policy requirements without the consent of the user, or that the user would even actively try to circumvent. Of course there are radically different views on whether that practice is good or bad and we should not reopen that discussion, but "inconsistent answers" is a side effect, not the key issue that would derive from a widespread adoption of the model discussed in the draft; so the draft should mention those issues too. The assessment in section 6 should be expanded to make it clear what the effects of the proposed model would be on currently common use cases for the DNS, like legally mandated filtering or security filtering by ISP/corporate networks.

--

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

---

From: Andrew Campling <[email-masked]>
Date: Mon, 23 Mar 2020 21:09:30 +0000

On Fri, Sun 22, 2020 at 05:12 Rob Sayre <[email-masked]> wrote:

> Items 4.1 and 4.2 are pretend security.  Just take a Google Pixel phone and turn on the built-in VPN.

I’m curious why you believe parents and enterprise network managers are “pretend security”?  Are you, for example, suggesting that there is currently no security on home or enterprise networks, or did you mean something else?

Andrew

---

From: Rob Sayre <[email-masked]>
Date: Mon, 23 Mar 2020 14:19:40 -0700

On Mon, Mar 23, 2020 at 2:09 PM Andrew Campling
<[email-masked]> wrote:

> I’m curious why you believe parents and enterprise network managers are
> “pretend security”?  Are you, for example, suggesting that there is
> currently no security on home or enterprise networks, or did you mean
> something else?
>

They aren't, but DNS-based measures (without installed Parental Control
Software or Enterprise Admin access) are. Chris Box wrote:

"the issues are complex enough that they can’t be solved by requiring
administrative control of the client."

But I think that solutions that don't require administrative control are
ineffective. My example was a Google Pixel phone: mine ships with a VPN
on-by-default for open WiFi, and the option to turn it on for all
connections.

thanks,
Rob

---

From: Jari Arkko <[email-masked]>
Date: Mon, 23 Mar 2020 23:55:34 +0200

Ted, Chris,

> If I compare the above to the set of perspectives outlined in ICANN SAC109, my expectation is that the resulting net change in the ability to meet their needs is as follows:
> 
> 4.1 (Parents):  Negative
> I'm not familiar enough with SAC 109 to comment, so I'll leave that to others.  My personal belief is that the ability to choose what resolvers belong in the set is important enough that it should map to the client's controller (which might be an individual, the parent of child, the enterprise owner of an employee device).  

I agree with Ted of course. I’d actually suggest also that there are different perspectives on what one considers trustworthy*. We did not want to discuss that under this draft. Rather, our goal was to discuss whether using multiple resolvers would provide a privacy benefit, not whether you trust a particular entity or a particular type of an entity. Why we mentioned something about different policies in Section 6.2 was not because we wanted to take a position, but rather the fact *if* you use multiple servers, then *if* their policies are very different this may result in unexpected results.

Jari

*) Including whether one is concerned about accuracy vs. privacy and whose control you are worried about.