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

bmanning@vacation.karoshi.com Wed, 03 February 2010 03:17 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 C8F3B3A6A16; Tue, 2 Feb 2010 19:17:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 q1rlM1RlVHLy; Tue, 2 Feb 2010 19:17:26 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D2AE33A69F3; Tue, 2 Feb 2010 19:17:24 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1NcVfC-000M1Y-Ma for namedroppers-data0@psg.com; Wed, 03 Feb 2010 03:12:22 +0000
Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <bmanning@karoshi.com>) id 1NcVfA-000LqZ-D4 for namedroppers@ops.ietf.org; Wed, 03 Feb 2010 03:12:20 +0000
Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o133Ajtv002429; Wed, 3 Feb 2010 03:10:45 GMT
Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o133AgJs002428; Wed, 3 Feb 2010 03:10:42 GMT
Date: Wed, 03 Feb 2010 03:10:42 +0000
From: bmanning@vacation.karoshi.com
To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Cc: Ted Hardie <ted.ietf@gmail.com>, John Payne <john@sackheads.org>, Roy Arends <roy@nominet.org.uk>, Wilmer van der Gaast <wilmer@google.com>, namedroppers@ops.ietf.org
Subject: Re: [dnsext] Re: Privacy vs EDNS Client IP...
Message-ID: <20100203031042.GE1374@vacation.karoshi.com.>
References: <6e04e83a1002010944q7abfabc6h892ce4cbb1bddcbf@mail.gmail.com> <973B1F15-E822-491E-89BF-F09FC7E67509@ICSI.Berkeley.EDU> <6e04e83a1002011109u1cd55c99k8b584648184cdc73@mail.gmail.com> <162E0DB1-EC86-4206-AB36-6FEFA786B24C@ICSI.Berkeley.EDU> <6e04e83a1002011402u395f599g74180d28fdbe5707@mail.gmail.com> <D8848FB8-3523-4580-A93F-764494531788@ICSI.Berkeley.EDU> <6e04e83a1002011640t1b637e30gd7d0150eeb0fae8d@mail.gmail.com> <E9A13A5C-73A7-4F66-9617-482551A9BA84@ICSI.Berkeley.EDU> <6e04e83a1002021155kcb908b1v71d362e03e7c4002@mail.gmail.com> <AB78D628-8A01-4742-B32A-90FC6806201E@ICSI.Berkeley.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <AB78D628-8A01-4742-B32A-90FC6806201E@ICSI.Berkeley.EDU>
User-Agent: Mutt/1.4.1i
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 02, 2010 at 12:45:20PM -0800, Nicholas Weaver wrote:
> 
> On Feb 2, 2010, at 11:55 AM, Ted Hardie wrote:
> > 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.
> 
> No, I am saying that the cases where this would be used, the users have already opted-in to the usage of a system like this, and extensions like this are already covered in the terms of service.
> 
> Do you NOT consider explicit selection of a third-party resolver a significant opt-in action?
> 

	hum... this leaps out.  being in a situation where your choice is:

	a) leave the computer off and read a book  
	or
	b) use the DHCP server in the hotel and get forced into using the DNS resolvers 
	   they hand you...  while never knowing if their resolvers have set the "ravish-me" bit.

	what other opt-in choice would you have?  DHCP is not tolerant of nodes that want to
	order DHCP offered services "al-cart".

--bill