Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt

[Ted Hardie <[e-mail]>]

In-line.  Probably also worth splitting discussion onto other threads
in any case, as
others have done.

On Mon, Feb 1, 2010 at 3:30 PM, Nicholas Weaver
<[e-mail]> wrote:
>
> On Feb 1, 2010, at 2:02 PM, Ted Hardie wrote:
>>
>>>
>>> And thus the only systems which would need changing are third party resolvers and authorities which desire the ability to act on this information.  No other changes are needed.
>>>
>>
>> This presumes that the clients do not have to opt-in to this and so no
>> changes are needed from them.
>
> 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.

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

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

But fixing that by having the enterprise understand the issue and
re-deploy requires
no protocol changes and saves latency in other ways besides.

> Looking at their resolver list, eg, it appears Comcast, for example, uses 12 such clusters.  And for localizing comcast customers for low latency, good bandwidth, etc, knowing "he's a comcast customer, his DNS resolver is X" is good enough.
>
> Whats needed is to get third party resolvers on the same footing.
>
>>> ANd I chose IMAP rather than SMTP and IMAP is more important for this than SMTP for DNS games: its a user-interactive application (unlike SMTP which is bulk delivery so latency doesn't matter so much), thats not HTTP and does not support HTTP style redirects, showing how these DNS tricks are
>>>
>>> a)  Used across more applications than just web traffic
>>>
>>> b)  Used in ways where web-style redirects can't work
>>>
>>
>> The point is, though, that there are applications which don't need this;
>> if you default to leaving it on for all applications, you're passing bits
>> that are at best not needed and at worst a privacy concern.
>
> But even your example of apps that DON'T need it (bulk SMTP) turn out to use it
>
> This is "near universal" functionality at this point for those deploying internet-scale stuff.
>

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.

<snipped a lot of discussion where there seems to be no basis for
discussion, since we've both stated positions>
>
>
> Actually, my figure is far less, because 3% is just one of the conditions: use a proxy for HTTP thorugh the browser. Its actually only 1% when you exclude those sessions who's non-browser traffic goes through the proxy.
>
>
> So of the 1% we see, the ones who would be affected are:
>
> a:  Those who's proxies are significantly different than their non HTTP traffic in terms of network location.
>
> b:  Who use a third party DNS service
>
> 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.

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


>
>
>> You may think privacy is a delusion, but you haven't convinced me that
>> it is worth
>> leaving it out of the design constraints here.  Geolocation and other
>> constraints
>> would be worse, I grant you, but this one is not trivial in my mind.
>
> The problem is, for those who care about DNS privacy, there exist GOOD opt-in solutions independent of this approach: route your DNS through the same proxy you use for your traffic.
>
> Rather those who this would affect are those who have implicitly stated they do NOT CARE about DNS privacy, because they are taking the privacy destroying action of using a third party resolver infrastructure.  Once you give Google the details of all the DNS requests you make, why should you care if Verisign sees your subnet on the rare requests where there is no cache for the nameserver entries?
>

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.

Of course that has the downside of information leaking the other way, as
well as a need to specify what query delivers the goods, but it is obviously
possible to divorce the optimization from the privacy issue.

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

regards,

Ted Hardie