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

["Chris Box (BT)" <[e-mail]>]

Hi Ted,

Thanks for responding. Let's take a look:

On Fri, 20 Mar 2020 at 21:24, Ted Hardie <[e-mail]> wrote:

>
> 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.
>

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.

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.
>

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.

>

> 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 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.

>
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.
>

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
> 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.
>

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