[dnsext] Privacy vs EDNS Client IP...

[Nicholas Weaver <[e-mail]>]

On Feb 1, 2010, at 4:40 PM, Ted Hardie wrote:
>> You could consider an automatic opt-in from all clients using third party DNS servers, since they opted in to THAT in the first place.
>> 
> 
> Except that it wasn't in place when they configured them.  So that's a
> post-facto
> opt-in, which doesn't seem much like an opt-in at all.

Have you read a terms of service that hasn't said "we can do whatever we want whenever we want in the future?"

You use a third party DNS service, you've already agreed to things like

> New Features.
> 
> OpenDNS may, in the future, offer new services and/or features through the Service (including, the release of new tools and resources). Such new features and/or services shall be subject to these Terms of Use. Your continued use of the Service after the introduction of new features and/or services constitutes your acceptance of the Terms of Use.


>> But if you want to require manual opt-in, you're saying "Kill this proposal" just in kinder language.
>> 
> 
> Notice that I'm not saying "Don't work on this problem", though.
> If the client included a bit that said "feel free to pass my details on"
> (what GEOPRIV used to call "setting the ravish-me bit") then I
> would have no privacy concern.

IF the client has to notify that its OK, you are saying kill the proposal.

Any change which requires client-change as well as resolver/authority change is a non-starter.  Look at things like Barwood's EDNS0 ping:  It would help against the out-of-path attacker, but because it requires changes to ALL resolvers and ALL authorities its useless.  Now add in changes to clients into the mix?.



> 
>> And here's why a national ISP wouldn't bother with this:  You are going to do a separate DNS zone for each regional zone, as having everybody go to a central cache, even heirarchically, is going to hurt performance.  If you want the net to "feel snappy" to customers, you don't add 100ms to DNS lookups by having all DNS eventually go to one place, rather you distribute caching recursive resolvers throughout the country
>> 
> 
> I'm aware of large scale enterprises that do bubble up to a single
> cluster per region,
> where region is at a continental scale.  If use my local DNS
> infrastructure, for example,
> the queries will come from New Jersey.  I am three time zones away.

Then the enterprise is being stupid unless all traffic funnels through the same gateway: Not only is it hurting CDN performance, but it is hurting ALL performance, for no real benefit.

DNS doesn't work well when your cache is 200ms or more away...

> 
> No.  If a recursive resolver turns this on globally, it will offer the option to
> every authoritative server (see section 4.1 of the draft) and it will pass
> the FAMILY and ADDRESS fields.  That information will get passed to
> every authoritative server, whether that server is localizing or not.  That's
> the wasted bits/data leakage issue I mentioned.

But what I am saying is that for 1st party resolvers, BECAUSE the CDN tricks work already, this information is already effectively available for all authorities, this would just give comparable information for the OpenDNS users rather than the Comcast users, or Napanet users, or corporate customers, or....

If this information leakage wasn't already there for the 1st party resolvers, the CDN tricks would never have been developed.  This formalizes the information leakage for 3rd party resolvers.


>> c:  Where they don't route the DNS requests through the proxy
>> 
> 
> Not all proxy deployments permit the DNS request to be routed through
> the proxy.

SOCKS does, IIRC, its part of the protocol.  That firefox doesn't actually do this by default is IMO, a firefox bug.

> 
>> d:  Somehow care about privacy despite using a 3rd party DNS service which they explicitly opted-into using in the first place!
>> 
>> We can tell A and B, we can't tell C, or D
>> 
>> For B: Use a proxy that is in their web browser setting (rather than forced by the network) + use OpenDNS: .77%.  Yes, shockingly high, but OpenDNS really is overrepresented in our dataset.
>> 
>> A will take a fair bit more work to answer, I need to start thinking on this.
>> 
> 
> You still seem to be missing the mobile IP case, where there is a long-lived
> tunnel to a home network but a portion of the traffic is originated from a local
> IP.

Route your DNS through the same portal as your tunnel:

If you're tunneling your web traffic, tunnel the associated DNS.  Puts them on the same privacy footing.

If you aren't tunneling your web traffic, why in god's name are you tunneling your DNS?

>> 
> 
> You are equating the terms of use for a service provider with the protocol
> mechanics; someone could deploy a 3rd party service with an explicit statement
> that the query logs were kept in /dev/null.  Presumably such a service
> would never
> use this option, but there might well be other solutions which met the
> authoritative
> servers need and they would be willing to use.  Anything in which the server
> was willing to provide the mapping information of networks to responders (along
> with a TTL) would have no privacy implication for the individual and would
> additionally pre-populate the cache of exactly the data this would provide.

Assuming you believe them to implement this policy.  If you want privacy, you need to build systems that create this policy REGARDLESS of the behavior of the remote services.

TOR is a system which enforces privacy.  You could build a DNS system which enforces privacy using TOR.  


But current DNS leaks it all over the place, in many cases you already see down to individual institution or small ISP as the authorities & path to authorities.  Using your institution or ISP's recursive resolver already sprays this level of information that we are talking about all over.  And third-party DNS really makes it worse in aggregate, because although the authorities see less due to aggregation, the third party sees all.


And the problem is, ANY "network mapping of requestor" will probably violate your privacy scruples:  Its not possible, the search space is too small for hashing and the like tricks to work, and it needs to be clear to both the final authority AND all authorities on the query path (due to the DNS nature) unless you want to add RTTs in an operation designed to minimize RTT latency.

You can talk about ideals all you want, but the application to be solved can NOT be solved within existing DNS without this or a near equivalent privacy leakage.



The only OTHER option would be to have the authority's response contain netmask rules and force the CDN processing onto the recursive resolver, which would be a huge shift in burden.



> Someone once called  protocol development as an exercise at deciding whose
> ox gets gored.  Goring the privacy of someone who doesn't get to be a party to
> the protocol exchange in which the data is distributed doesn't strike me as a
> good idea.  Since you've already called me delusional on this point, I doubt
> my own ideas convince you.  But I point you to the work of GEOPRIV as an
> existence proof that the IETF as a whole at least once cared about a similar
> issue (and given the services which correlate IP to location, one which is
> a lot closer than the proposal on the table admits).

You are trying to "protect" the privacy of those who have explicitly and willingly given it up already to a major third party.  They have already been a party to willingly giving up their privacy, so if you are going to gore anyone, it should be them.



And if you are really concerned about privacy, I'd look at web analytics, that is far far FAR FAR more evil in spraying information around and there IS no opt-out other than technical countermeasures!  You are worried about a paper cut (subnet of requester in a DNS message using third party DNS infrastructures) when there is arterial bleeding going on.