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

Carlo Contavalli <ccontavalli@google.com> Mon, 01 February 2010 15:37 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A11B28C0F8; Mon, 1 Feb 2010 07:37:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.827
X-Spam-Level:
X-Spam-Status: No, score=-105.827 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Axjf4ieYgoqv; Mon, 1 Feb 2010 07:37:00 -0800 (PST)
Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 60EDA3A6826; Mon, 1 Feb 2010 07:37:00 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1NbyEI-000JxI-Uw for namedroppers-data0@psg.com; Mon, 01 Feb 2010 15:30:23 +0000
Received: from [216.239.44.51] (helo=smtp-out.google.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <ccontavalli@google.com>) id 1NbyEC-000JwV-K0 for namedroppers@ops.ietf.org; Mon, 01 Feb 2010 15:30:16 +0000
Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id o11FUFUJ001748 for <namedroppers@ops.ietf.org>; Mon, 1 Feb 2010 07:30:15 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265038215; bh=7FcnsuDKwufyjiR+RrbLIRJPvr4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=I+T1JXHHgRK2LdAOO9n0qgTD/a3FQi1TP0GdjI7RGcOIwpWxzZyV40DI1DwKmJQb8 JDwouOAiGtEEVxmwhoD5w==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=ML7mp7tgfESrsTSJF5OnBJ3U1Mh4iG8EmNZBlFb2+c3w/FqzzozALBXvyX6bvh7Yj dcyKN8dwWBBz/nlY6vsRQ==
Received: from pxi3 (pxi3.prod.google.com [10.243.27.3]) by kpbe11.cbf.corp.google.com with ESMTP id o11FTbfH015520 for <namedroppers@ops.ietf.org>; Mon, 1 Feb 2010 09:30:07 -0600
Received: by pxi3 with SMTP id 3so87576pxi.16 for <namedroppers@ops.ietf.org>; Mon, 01 Feb 2010 07:29:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.26.16 with SMTP id d16mr3109785wfj.287.1265038199156; Mon, 01 Feb 2010 07:29:59 -0800 (PST)
In-Reply-To: <4B66E441.6090104@nic.cz>
References: <7c31c8cc1001271556w4918093er6e94e07cb92c4dc4@mail.gmail.com> <4B66E441.6090104@nic.cz>
From: Carlo Contavalli <ccontavalli@google.com>
Date: Mon, 01 Feb 2010 15:29:39 +0000
Message-ID: <4966825a1002010729m32b5ccfel94f7cb09d8b5e458@mail.gmail.com>
Subject: Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt
To: Ondřej Surý <ondrej.sury@nic.cz>
Cc: namedroppers@ops.ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

On Mon, Feb 1, 2010 at 2:25 PM, Ondřej Surý <ondrej.sury@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
to the server right after doing the lookup.

It's similar to when you use a proxy: will it include a
X-Forwarded-For header? or not? how do you know it is? how do you know
it won't include the header in the future? how do you know they are
not forwarding your data by some other means? is this ground to say
that X-Forwarded-For should not exist? is this a problem at the
protocol layer?

Carlo