headers
Eric Brunner-Williams | 1 Feb 2010 01:04
Favicon

Re: [dnsext] Privacy in IP address indication (Was: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt

in 8, there is a repetition of the choice (mistake in my opinion) that 
truncating a 32bit address to 24bits provided "privacy".

there are two issues.

first, what data is being collected by the server, independent of any 
assertions of preference by the address provisioning client?

i'm not suggesting that the server should signal the client what its 
data collection practices are, but it is a possibility, this is what 
the w3c's p3p work has made possible, and there is a dcp element (data 
collection policy) in epp.

the mistake made in the p3p spec group was to pick 24bits as providing 
"privacy". this choice was made without reference to the structure of 
any particular address allocation in which an address for which some 
"privacy" was desired, or to the temporal properties of addresses in 
the smallest block to which that address belong.

in short, for the purposes of geo-mumble, a purpose this draft appears 
to share, no use was made of information that may be sufficient to 
identify the geo property sufficient for the proposed service, e.g., 
is this user on mars, for some value of mars, and, there was no 
awareness that dynamically provisioned 32bit identifiers are "static" 
of significant periods of time, and other correlative tools are 
available for user profiling business (and non-business) models which 
have access to "masked" data and other sources of data.

second, there is the utility of the client, the address bits 
provisioning source, asserting what the provisioned bits are.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ondřej Surý | 1 Feb 2010 15:25
Picon
Favicon
Gravatar

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

I am replying to several mails at once, since some of them address my 
concerns after reading whole draft.

On 28.1.2010 00:56, Wilmer van der Gaast wrote:
> Hello everyone,
>
> I spoke to Olafur about this idea in Hiroshima last year. I'm afraid
> the deadline for Anaheim already passed, but we hope we can discuss it
> on-line in the meantime and decide if it should become a WG item in
> Maastricht later this year.
>
> To summarize the I-D: It specifies an EDNS0 option that carries IP
> address information (by default only the first 24 bits to preserve
> privacy) of the user that triggered a DNS resolution. This should
> allow authoritative nameservers that give geo-targeted responses to be
> more accurate, even in cases where the resolver and its users aren't
> close to each other. To preserve the ability to cache such responses
> efficiently, the option in the response can indicate which exact
> subnet it should be cached for.
>
> Comments are more than welcome.

#1: There should be a way how to ask recursive resolver if he has set 
edns-client-ip on query or not, so end client knows if authoritative 
server knows his IP or not. (let's call it stalk flag)

On 28.1.2010 20:02, Nicholas Weaver wrote:
 >> it's not worth a global upgrade to DNS in its current form.
 >
 > It can be done WITHOUT a global upgrade: you can do it with JUST
(Continue reading)

Permalink | Reply | 15 comments |
headers
Ondřej Surý | 1 Feb 2010 15:33
Picon
Favicon
Gravatar

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

On 28.1.2010 21:19, Nicholas Weaver wrote:
> The client has ALREADY given up the privacy to the third party DNS resolver, the additional privacy
leakage thereafter would be trivial.

I strongly disagree with this statement.  You can have all sorts of 
agreements with third party DNS resolver provider, including privacy 
agreement, etc.  This is one-to-one relationship.  On the other hand 
giving your IP address (or netblock) to random third party authoritative 
DNS providers is a different thing in my view, since you give your IP 
address/netblock to every-typo-you-make authoritative DNS server.

Ondrej
--

-- 
  Ondřej Surý
  vedoucí výzkumu/R&D manager
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:ondrej.sury <at> nic.cz    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------
Permalink | Reply | 3 comments |
headers
Martin Barry | 1 Feb 2010 15:57
Gravatar

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

$quoted_author = "Ondřej Surý" ;
> 
> On 28.1.2010 21:19, Nicholas Weaver wrote:
> >The client has ALREADY given up the privacy to the third party DNS
> >resolver, the additional privacy leakage thereafter would be trivial.
> 
> I strongly disagree with this statement.  You can have all sorts of
> agreements with third party DNS resolver provider, including privacy
> agreement, etc.  This is one-to-one relationship.  On the other hand
> giving your IP address (or netblock) to random third party
> authoritative DNS providers is a different thing in my view, since
> you give your IP address/netblock to every-typo-you-make
> authoritative DNS server.

I'm not sure I understand this concern. 

A DNS request is usually followed by a connection from an application.

Given that the edns-client-ip option in the draft would apply a netmask,
surely that is providing less information to the service operator than the
subsequent connection to their service.

cheers
Marty
Permalink | Reply | 2 comments |
headers
Stephane Bortzmeyer | 1 Feb 2010 16:17
Picon

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

On Tue, Feb 02, 2010 at 01:57:46AM +1100,
 Martin Barry <marty <at> supine.com> wrote 
 a message of 24 lines which said:

> I'm not sure I understand this concern. 

Then you did not read the whole thread:

From: Stephane Bortzmeyer <bortzmeyer <at> nic.fr>
To: Alex Bligh <alex <at> alex.org.uk>
Cc: namedroppers <at> ops.ietf.org
Date: Fri, 29 Jan 2010 12:38:13 +0100

This would lose a lot of privacy since the IP address of the "desktop"
client would be transmitted in full, not only to the HTTP server but
also to middlemen, the authoritative servers of the root, the TLD,
etc.

The draft has a provision for this (section 4.1) but it is just a MAY
and does not blend well with the general zone cut rules.

Also, the HTTP request may be through a proxy, too, so you cannot even
say that the HTTP server would know the address.
Permalink | Reply | 0 comments |
headers
Carlo Contavalli | 1 Feb 2010 16:29
Picon
Favicon

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

On Mon, Feb 1, 2010 at 2:25 PM, Ondřej Surý <ondrej.sury <at> nic.cz> wrote:
> On 28.1.2010 20:02, Nicholas Weaver wrote:
>>> it's not worth a global upgrade to DNS in its current form.
>>
>> It can be done WITHOUT a global upgrade: you can do it with JUST
>> upgrades to the recursive resolvers and authorities desiring such
>> behavior, see my note on fallbacks from the resolver point of view.
>
> No you can't.  Since all end users would loose privacy from day zero, since
> this proposal is opt-out, not opt-in.  Therefore you need to do a global
> upgrade.

Define "from day zero"? recursive resolvers do not have to implement
edns-client-ip, and they do not have to turn it on. They CAN, if they
want, and the hope is that they eventually WILL when it brings
advantages to their users. And it'll take time for each one of them to
eventually decide they want to enable the option.

It is opt-in from the recursive-resolver point of view. It is opt-out
from the end client point of view. But again, we are defining a
*protocol*, a means for two computers to exchange data with each
other, not a policy.

> opt-in (same as in the browser).  I would just hate if my resolver starts to
> send my IP address to authoritative DNS without asking me.
Eg, what's preventing recursive resolvers from forwarding your IP
address now? the lack of protocol support? or a contract/privacy
statement with their users? if IETF does not allow a protocol to do
so, will they NOT forward your IP address? and again, we're not even
talking about the full IP address, and in most cases you just connect
(Continue reading)

Permalink | Reply | 13 comments |
headers
Nicholas Weaver | 1 Feb 2010 16:36
Picon
Favicon

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


On Feb 1, 2010, at 6:25 AM, Ondřej Surý wrote:
> On 28.1.2010 00:56, Wilmer van der Gaast wrote:
>> Hello everyone,
>> 
>> I spoke to Olafur about this idea in Hiroshima last year. I'm afraid
>> the deadline for Anaheim already passed, but we hope we can discuss it
>> on-line in the meantime and decide if it should become a WG item in
>> Maastricht later this year.
>> 
>> To summarize the I-D: It specifies an EDNS0 option that carries IP
>> address information (by default only the first 24 bits to preserve
>> privacy) of the user that triggered a DNS resolution. This should
>> allow authoritative nameservers that give geo-targeted responses to be
>> more accurate, even in cases where the resolver and its users aren't
>> close to each other. To preserve the ability to cache such responses
>> efficiently, the option in the response can indicate which exact
>> subnet it should be cached for.
>> 
>> Comments are more than welcome.
> 
> #1: There should be a way how to ask recursive resolver if he has set edns-client-ip on query or not, so end
client knows if authoritative server knows his IP or not. (let's call it stalk flag)
> 
> 
> On 28.1.2010 20:02, Nicholas Weaver wrote:
> >> it's not worth a global upgrade to DNS in its current form.
> >
> > It can be done WITHOUT a global upgrade: you can do it with JUST
> > upgrades to the recursive resolvers and authorities desiring such
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Hoffman | 1 Feb 2010 17:04

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

At 1:57 AM +1100 2/2/10, Martin Barry wrote:
>$quoted_author = "OndÞej Sur˜" ;
>>
>> On 28.1.2010 21:19, Nicholas Weaver wrote:
>> >The client has ALREADY given up the privacy to the third party DNS
>> >resolver, the additional privacy leakage thereafter would be trivial.
>>
>> I strongly disagree with this statement.  You can have all sorts of
>> agreements with third party DNS resolver provider, including privacy
>> agreement, etc.  This is one-to-one relationship.  On the other hand
>> giving your IP address (or netblock) to random third party
>> authoritative DNS providers is a different thing in my view, since
>> you give your IP address/netblock to every-typo-you-make
>> authoritative DNS server.
>
>I'm not sure I understand this concern.
>
>A DNS request is usually followed by a connection from an application.
>
>Given that the edns-client-ip option in the draft would apply a netmask,
>surely that is providing less information to the service operator than the
>subsequent connection to their service.

This assumes that they system that is making the DNS request is the one that is about to make the connection.
That is the common, but not universal, case.

--Paul Hoffman, Director
--VPN Consortium
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicholas Weaver | 1 Feb 2010 17:39
Picon
Favicon

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


On Jan 29, 2010, at 7:51 AM, John Payne wrote:

> 
> On Jan 29, 2010, at 8:05 AM, Roy Arends wrote:
> 
>> Webserver now knows the clients IP address (10.0.0.2), issues a redirect
toB8AAAQ.localized.google.com 
> 
> For whatever reasons... that does not fly in the real world.   
> It's hard enough getting content providers[1] used to a redirect from http://example.com/ to http://www.example.com/

Additionally, in many contexts, such redirects may not be applicable:

a)  Not everything is HTTP or HTTPS and supports such clean redirections.

b)  Exporting user-visible URLs like that is ugly.  (we do it on Netalyzr for transparency & debugging, but
its ugly)

c)  HTTPs is very fussy on names in many cases.
Permalink | Reply | 40 comments |
headers
Ted Hardie | 1 Feb 2010 18:44
Picon

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

Howdy,

On Mon, Feb 1, 2010 at 8:39 AM, Nicholas Weaver
<nweaver <at> icsi.berkeley.edu> wrote:
>
> a)  Not everything is HTTP or HTTPS and supports such clean redirections.
>
And this is one of the clearest point in this whole debate:  CDNs serve one
sort of application, which has a host of other methods in play (redirects,
content negotiation, an UPGRADE mechanism to change the security characteristics
of the channel).   Many other applications do not have any of these or use
fundamentally different approaches (store-and-forward protocols, for example,
are pretty unlikely to use a redirect-style approach).

Are we expecting the client's interaction with the DNS to be different on an
application basis here?  Specifically, do we expect the DNS query to look
different when the browser makes a request than when the mail stack does?
How realistic is that, really, without the browser maintaining its own stack?
Isn't it more likely that this will be turned on or off globally?  If
it does vary, what
does that mean for intermediate caching?  Does
this create yet another pressure to reduce cache times?

On a slightly different point, I think Stephane's point on the prevalence of
tunnels in Mobile IP situations is being lost here--we not only have the case
of proxy/tunnels configured for specific applications, but the MIP tunnels which
may be in play here--and that hits a lot of mobile clients that I fear are not
captured in netalyzr data.

regards,
(Continue reading)

Permalink | Reply | 39 comments |

Gmane