[dnsext] Re: EDNS client IP should be opt-in (Was: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt

Carlo Contavalli <ccontavalli@google.com> Tue, 02 February 2010 11:59 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 072203A6936; Tue, 2 Feb 2010 03:59:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.94
X-Spam-Level:
X-Spam-Status: No, score=-105.94 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 9FEvi-MzAs4B; Tue, 2 Feb 2010 03:59:55 -0800 (PST)
Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 431CE3A6935; Tue, 2 Feb 2010 03:59:55 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1NcHLw-0004LQ-R0 for namedroppers-data0@psg.com; Tue, 02 Feb 2010 11:55:32 +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 1NcHLu-0004Ky-BU for namedroppers@ops.ietf.org; Tue, 02 Feb 2010 11:55:30 +0000
Received: from spaceape9.eur.corp.google.com (spaceape9.eur.corp.google.com [172.28.16.143]) by smtp-out.google.com with ESMTP id o12BtSEc024510 for <namedroppers@ops.ietf.org>; Tue, 2 Feb 2010 03:55:29 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265111729; bh=dq51F5Kn2qNHZ+zEH9oHFXcRW3Y=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=IpyJFbmZ0ILMEs32NWSi/gYKZla+7shdVyN9nv6GciMteG69GrlyDMBWd7Es2Ilpd pJXtQ5hHYAz3ngXYzI+eQ==
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:x-system-of-record; b=vR1HeSob1blAc4E/U5cR5COuoP7YN/eJY0J95X0QV7RfU7/p4NTaDxuloc0WLjTdk +rfaeCOWmsoCkZFwKWIHA==
Received: from pzk1 (pzk1.prod.google.com [10.243.19.129]) by spaceape9.eur.corp.google.com with ESMTP id o12BtQgN009063 for <namedroppers@ops.ietf.org>; Tue, 2 Feb 2010 03:55:27 -0800
Received: by pzk1 with SMTP id 1so238359pzk.16 for <namedroppers@ops.ietf.org>; Tue, 02 Feb 2010 03:55:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.25.22 with SMTP id c22mr445288wfj.195.1265111725151; Tue, 02 Feb 2010 03:55:25 -0800 (PST)
In-Reply-To: <20100202113421.GA31244@nic.fr>
References: <7c31c8cc1001271556w4918093er6e94e07cb92c4dc4@mail.gmail.com> <4B66E441.6090104@nic.cz> <4966825a1002010729m32b5ccfel94f7cb09d8b5e458@mail.gmail.com> <20100202113421.GA31244@nic.fr>
From: Carlo Contavalli <ccontavalli@google.com>
Date: Tue, 02 Feb 2010 11:55:05 +0000
Message-ID: <4966825a1002020355s41a182edvbc2fc8045af4a36e@mail.gmail.com>
Subject: [dnsext] Re: EDNS client IP should be opt-in (Was: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Cc: Ond??ej Surý <ondrej.sury@nic.cz>, namedroppers@ops.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
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 Tue, Feb 2, 2010 at 11:34 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
>> recursive resolvers do not have to implement edns-client-ip, and
>> they do not have to turn it on.
>
> Yes, they have to, if they want to keep the SAME level of privacy as
> today (not solve every privacy problem, just keep the CURRENT
> level). That's the biggest problem with the proposal.
I sincerely do not understand this comment.

If you don't enable the option, you keep the SAME level of privacy as
of today (eg, no client-ip information is forwarded to other name
servers).

If, as someone running a recursive resolver, you have a contract with
your users that allows you to do so and decide the "reduced privacy"
is worth the benefit for your users, you CAN enable the option if you
WANT to.

And again, this is more of a policy discussion. See my other email.

Carlo