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

[Ted Hardie <[e-mail]>]

Comments in-line.

On Mon, Feb 1, 2010 at 6:51 PM, Nicholas Weaver
<[e-mail]> wrote:
>
> 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.
>

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.


>
>>> 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.
>

As I was trying to say in a previous message, there may be ways to get
sufficient
data from authorities to interested recursive resolver without there being
any privacy-related disclosure.  I don't know yet how practical they are, but
the problem statement:

"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.


> 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.

Agreed, and that's why I said fixing it by encouraging redeployment rather
than localization was the appropriate remedy here.

>
>> 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....
>

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.


> 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.
>

And puts the onus on clients to opt-out of disclosure without knowing whether or
not that disclosure is going on upstream of them.

>
>>> 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.
>

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.

>>
>>> 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?
>

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.

Things in MIP-land are a little more complicated yet (service selection options
and so on), but this gives you an idea of why the DNS might exit someplace
other than the traffic in the presence of a tunnel.


>
>
> 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) *or* that is actually a network mapping that doesn't disclose
which IP address or subnet generated the request for the mapping.  I could
achieve that steganographically by putting the "real" request in a flood of
requests related to other subnets, but that would be a colossal waste of
resources.


>
> 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.


>
>
>> 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.
>
>
We disagree on this point.

>
> 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.
>
>

regards,

Ted Hardie