On 8/31/2018 7:22 AM, Brian Haberman wrote:
> All,
> The conversations around this topic have gone silent. Are there
> other perspectives that we need to understand?
>
> Tim and I are discussing an interim in September to get some
> focused discussion on requirements, issues, and gating factors. Please
> continue to raise items that you think warrant consideration for the
> recursive to authoritative privacy work item. Without content, it won't
> make much sense to hold an interim.
>
> Regards,
> Brian
>
> On 7/19/18 2:10 PM, Brian Haberman wrote:
>> All,
>> The chairs would like to get the WG discussion started on exploring
>> privacy solutions for recursive resolver to/from authoritative server
>> exchanges. To start, we want to focus on *use cases and requirements*.
>> In our view, the WG needs to consider the:
>>
>> - User perspective
>> - Implementer perspective
>> - 2nd-level server operator perspective
>> - Recursive resolver operator perspective
>>
>> For the time being, we would like to bypass the TLD server operator
>> perspective. While we are in this phase of discussion, the chairs would
>> like everyone to follow these guidelines:
>>
>> - Focus on *what* is needed.
>> - Avoid *how* to achieve it.
>> - Consider both ends of DNS the exchange.
>> - Scenarios will frame the discussion.
I am interested in the "no resolver" aspect. The privacy argument for
using encrypted to a recursive resolver is that the stub's queries get
mixed into an "anonymity set" of all the stubs using the same recursive
resolver. That's a fine argument, but it requires users to put a lot of
trust in the recursive resolvers. Clients would not be forced to trust
the recursive resolvers if they could do the entire recursion themselves.
Of course, running a recursive resolver from the client itself is not
currently a good privacy option. The client would end up sending lots of
clear text traffic to authoritative sites, traffic that could easily be
monitored. But if that traffic was encrypted, the "recursive client"
option would become significantly more attractive. Yes, the IP addresses
of the authoritative servers will be visible. But these servers have an
"anonymity set" of their own, as they often serve a large number of
domains. The adversaries will know that the user contacted a server, but
they will not know which domain on that server.
The recursive client option has the advantage of diluting the client's
requests over a multiplicity of servers. This makes the privacy of the
system significantly more robust. Recursive servers are interesting
targets, and adversaries can compel their cooperation through subpoena
or scarlet letters, or they can target them for hacking. With a
recursive client approach, the adversaries will have to gain cooperation
of a large number of servers, which may well be located in a variety of
jurisdictions. This could be much harder.
And because of that, I am quite interested in practical ways to encrypt
the traffic from clients to authoritative servers.
-- Christian Huitema
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
