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

[Ted Hardie <[e-mail]>]

Hi Chris,

Thanks for the review.  Replies in-line.

On Fri, Mar 20, 2020 at 11:22 AM Chris Box (BT) <[e-mail]>
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.
>
> 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.
>

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.


>
> 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 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
> 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 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'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).
>
> [image: Normal.png]
> 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:
> [image: With two resolvers.png]
> 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.
>
>
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.


> 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 again for the review,

Ted



> Thanks,
> Chris
>
>
>
> On Tue, 25 Feb 2020 at 18:01, Ted Hardie <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/add
>>
>