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

[Nicholas Weaver <[e-mail]>]

On Feb 2, 2010, at 11:55 AM, Ted Hardie wrote:
> Again, I think you're conflating the terms of service for a particular
> actor with the protocol semantics here.  You may be right that some
> 3rd party agreements allow one of the parties to set the ravish-me bit,
> but that doesn't make it okay to assume that all DNS users have agreed
> to the disclosure of this data.  This wasn't possible before and they
> have not opted-in.  You and I may disagree about whether or not they
> should, but let's at least be cleared that they have not.
> 
> Separately, I agree with Stephane's comments on the method for opting out
> in the draft requiring work and having potential deployment difficulties.

No, I am saying that the cases where this would be used, the users have already opted-in to the usage of a system like this, and extensions like this are already covered in the terms of service.

Do you NOT consider explicit selection of a third-party resolver a significant opt-in action?

Should DNS be the only real protocol with an opt-in privacy ability?  HTTP sure doesn't....

> "Authoritative servers wish to provide localized results based on network
> proximity.  What is the best way for interested recursive resolvers and
> authoritative servers to manage information about these mappings?"
> 
> does not automatically imply this solution nor any solution that requires
> divulging which client subnets originated specific queries.

Actually, it does, here's why:

Network proximity, with any decent quality, be it AS number, hash of AS number, subnet mask, truncated AS path, magic-pixie-number, etc, will leak similar amounts of information.  It has to, because it always has to say "the user is in this part of the network space", its just a matter of how to say it and with what precision: be it subnet, most specific AS number, or pixie-dust: they all say "where you are".  

And, like GeoIP, or Wifi Mac address -> location, or whatever, there will be databases made to unify them all, so we might as well call them roughly equivalent to start with and save us the headache of every alternate form getting the same objections from different people.


Hashing type tricks don't help either, because the search space is way too small.  With a network describable by 10K-100K+ points of locality, there simply isn't enough search space to make hashing tricks work.

QED:  Network proximity is privacy sensitive by your definition, in any form, because they are all roughly equivalent with the only difference being degrees of precision.  

IP subnet just happens to be a very convenient one, because the CDNs are already optimized around that as the metric.  But most specific AS or AS-path fragment would be effectively equivalent in information leakage.



> We seem to be talking at cross purposes here.  Let me try again.  This proposal
> would have the option be present whenever a recursive resolver talks to an
> authoritative server if it is globally set.  That means that this
> information passes
> to every authoritative server, whether the authoritative server is
> localizing information
> or not.  That means the universe of leaked data is not "Users of 3rd party DNS
> requesting info about  localized servers" but potentially "users of 3rd party
> DNS requesting info from anyone".  We don't disagree about whether someone
> running their own recursive resolver or using a local one is already disclosing
> (at least I don't think we do).
> 
> If this is not set globally, then the recursive resolver has to
> maintain a table or
> set of rules that notes when it should be sent and when it should not.  I'm not
> sure how it gets knowledge of which services are localized, so it is
> my expectation
> that anyone who turned it on would leave it on for all queries to authoritative
> servers.  I could be wrong, of course, and some other pattern might easily
> emerge.

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.  

Just because only a few authorities are USING CDN-like tricks doesn't mean that all authorities aren't already receiving the same network locality information, they just are not bothering to infer anything about it. 

> 
> SOCKS 4 did not; SOCKS 5 added support for it, but in many installations
> it requires explicitly directing the DNS traffic through the tunnel.  SOCKS
> can leak DNS in cases where the tunnel is set up per application and DNS/UDP is
> not explicitly redirected.  Some other forms of proxy don't handle UDP at all.

That does not mean we should work around bugs in proxies that can't handle UDP.  Heck, tunnel your DNS over TCP then, if your proxy doesn't support UDP, to pick the route you want your DNS queries to take.

> Think of it in VPN terms for a moment.  The VPN set-up directs certain
> IP subnets through the tunnel interface, which can have effects from pointing
> default through the tunnel to setting up a small number of networks which
> are routed through the tunnel but leaving all others to be routed outside the
> tunnel.  The resources available through the tunnel can include
> local file servers, smtp servers, and other services which are not available
> from outside because of firewall restrictions.  The client needs to
> pass at least the
> DNS traffic related to those services through the tunnel because of split
> DNS.  It is easier to pass *all* DNS through that tunnel if the set of resources
> the client is interested is {globally available services, private
> services available
> through the tunnel}.  When it includes {globally available services,
> private services
> available through the tunnel, and private services available locally but not
> globally} I have to actually associate which domains are served where,
> and the default can go either to local or tunnel, depending on configuration.

And if you do so, how does this draft really affect you?  

Unless your VPN'ing institution also uses a third party managed DNS service rather than its own DNS resolver, the information all leaks out anyway to the authorities.

And if your institution does not want this information to leak out, why is it leaking it en masse to the third party provider which explicitly says its allowed to use aggregates of that information?

And no matter what, you're CDN performance will be painful since your data IP and query IP are very different, but thats just the limitation of DNS-based CDNs no matter the information.



>> And the problem is, ANY "network mapping of requestor" will probably violate your privacy scruples:
> 
> No, I'm fine with any mapping that the requester agrees to (a non-starter in
> your option)

You don't seem to consider "the user specified this non-default resolver" as agreement, however.


> *or* that is actually a network mapping that doesn't disclose
> which IP address or subnet generated the request for the mapping.  

See above, that's impossible short of noise injection, and noise injection would be pointless: you're trying to hide things from the authorities of sites you want to talk to!

Else why are you looking up the names at all?

The "This option is not exported to the TLD servers" part means only the authorities YOU are going to talk to receive this information at all.


>> 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.
>> 
> 
> Is the real problem here a shift in burden of, presumably, processing power
> (since the network traffic might actually be less) or of CDN secret sauce?
> Because if a zone transfer-like mechanism of mapping info can accomplish
> this there is zero privacy implication to my mind, and I would be interested
> to see which of the recursive server operators would say yes to using it.

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?



>> 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.
>> 
> And this is unrelated to the work going on here.

If your objection to something that would greatly improve the ability of people to use DNS service providers other than those of the ISP only comes down to protecting privacy, scale matters.  So it is related.