[dnsext] Re: Privacy vs EDNS Client IP...

[Nicholas Weaver <[e-mail]>]

My last comments on this:

On Feb 2, 2010, at 4:19 PM, Ted Hardie wrote:
> With an opt-out only mechanism, we also have no way to judge how many of the
> customers would voluntarily give their data to get the better performance; it
> might be the overwhelming majority.  But you are treating opt-in as a complete
> non-starter; if you had not, you and I could be talking about how to create
> informed consent from the user to the authority instead.  As I said before,
> I would be fine with this as an opt-in; that enables the users to retain
> their current levels of privacy by default.


If opt-in is engineered in the PROTOCOL, it really is a non-starter, because opt-in in the protocol requires changing stub resolvers, and if we change stub resolvers, there are far better changes to make first.

My preferred one would be eliminating recursive resolvers entirely from the protocol's usage for anything that the stub resolver can't verify with DNSSEC with a chain of trust from a signed root: the recursive resolver is a proven security and privacy threat that should be eliminated from the architecture entirely. 



If opt-in is not assumed by an already made explicit choice of resolver when such a feature already complies with the existing terms of service, there is no benefit:  OpenDNS and Google Public DNS have gone out of their way to advertise particular "set your DNS here" addresses.  That goes out the window.  So why bother developing this further, since these are the parties who want it, and who have invested a large amount of time and effort into advertising these IP addresses?


Basically, neither of your opt-in choice can work.


So I think we can conclude there is a fundamental difference: 

You believe there are a significant number of users who

a)  Deliberately chose a third party resolver

b)  Chose the third party resolver to somehow prevent information leakage

and that if these can't be accomidated, you don't want the protocol.


I believe that

a)  Most users who chose a third party resolver did not do so for privacy reasons, and are already covered under a contractual relationship with the third party resolver which would enable this feature under the existing terms of service

b)  Those who did, even in the current infrastructure, made a very poor decision that does not significantly enhance their privacy and, if anything, significantly degrades their privacy protections.

And therefore the significant benefit to all the other users of third party resolvers, and the ability to make sure that third party resolvers both work with CDN-style DNS and don't have barriers to entry is far more useful than preserving what privacy protection may be lost.


>> And you seem to be missing my point:  For users of 1st party resolvers, this information or something semantically equivalent is already being leaked to ALL authorities.
>> 
> 
> We agree; it is possible to configure a system so that this does not leak,
> but those who use a resolver on their system or very close to it are leaking
> this data now.

Why do you think that using a third-party resolver is a good solution for privacy protection?  Any savings you get by having some requests cached and some requests through their resolver address are lost by giving your entire request stream to companies which specifically states it has the right to datamine the results in the terms of service.  

For at least one major provider, Google, the ability to datamine the query stream is the ONLY revenue source!


>> Such zone-transfer like mechanisms would undoubtedly be constrained by pairwise agreements between authorities and third-party resolvers, because there is BOTH secret sauce issues and load issues.
>> 
>> So do you really want to ingrain contractual-behavior affecting performance into DNS!?!?  Do you really want contractual barriers to entry for 3rd party DNS services?
>> 
>> 
> 
> You seem to want to rely on contractual language between 3rd party servers
> and their clients.  If 3rd party resolver X doesn't bother getting data from
> CDN Y, they are no worse off than now.  They can opt-in to it, just as they
> can opt-in to sending client IPs; the amount of data and work are different,
> but so is the customer experience.

I want to take advantage of existing contractual relationships between the client and third-party resolvers, yes.  Why create a new mechanism when existing mechanisms will suffice?  How much opt-in is enough?

I don't want to create an incentive for contractual relationships between CDNs and third party resolvers, because that will create barriers to entry for anyone else wanting to do "better DNS"

> The key question is who should be sending data to whom?  Does the CDN
> reveal data in bulk to interested resolvers?  Or does the resolver reveal
> data en masse to authorities?

No CDN, because of secret sauce concerns, will reveal the data to ALL interested resolvers:  This is saying "support zone transfers"-type logic to everyone.  Can you believe ANY CDN would do such a thing?  We've gone through years of advice of "disable zone transfers", and now you'd want the CDN's to enable-zone transfer equivelents?

Thus they would ONLY reveal data to pairwise agreements, which creates barriers to entry for other third party resolvers.

Do you really want to ensure that the only solution is anticompetitive?  

> I don't understand how your point about web analytics/scale relates to
> which problems
> the WG is chartered for.  But please don't worry about it; that
> particular tendril of
> fog doesn't need much blowing away.

Yes it does:  All costs are relative.  You don't go fretting about $1 budget items if you have $1M problems.  

The scale of the problem from APIs and analytics is so much greater than the information leakage you'd generate if you generated all requests through a resolver on your computer (which is far more leakage than you are worried about here).  For those who don't think its a problem, do a search in your cookie store for __utma.  Or run an IDS and look at all the "fetches" for images to google-analytics.  And content yourself with the fiction that google does not consider the IP address PII for the purpose of analytics...

Until you are running techniques to block analytics, APIs, etc, who cares about if DNS starts leaking the subnet you are on when you are using a third-party resolver, only to the authorities for the names you are query, and that already reserved the right to datamine "aggregate" query streams?