IETF Logo Mail Archive

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

bmanning@vacation.karoshi.com Sun, 31 January 2010 20:36 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 C565B3A6950; Sun, 31 Jan 2010 12:36:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 hK-ssvgB7E4Y; Sun, 31 Jan 2010 12:36:30 -0800 (PST)
Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 095DF3A68E4; Sun, 31 Jan 2010 12:36:30 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1NbgTN-000LcN-E3 for namedroppers-data0@psg.com; Sun, 31 Jan 2010 20:32:45 +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 1NbgTL-000LPN-FW for namedroppers@ops.ietf.org; Sun, 31 Jan 2010 20:32:43 +0000
Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o0VKUttv007649; Sun, 31 Jan 2010 20:30:55 GMT
Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o0VKUtbq007648; Sun, 31 Jan 2010 20:30:55 GMT
Date: Sun, 31 Jan 2010 20:30:55 +0000
From: bmanning@vacation.karoshi.com
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Cc: Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org
Subject: Re: [dnsext] Privacy in IP address indication (Was: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt
Message-ID: <20100131203055.GB7279@vacation.karoshi.com.>
References: <7c31c8cc1001271556w4918093er6e94e07cb92c4dc4@mail.gmail.com> <6184.1264657589@nsa.vix.com> <4966825a1001280807i768a33ccs98f809366bce33d8@mail.gmail.com> <48894.1264695230@nsa.vix.com> <50A91B20-5AC1-4819-91ED-E5141F068D48@wiggum.com> <52065.1264699087@nsa.vix.com> <FDD5D1103B8EA4D13C4A2C4C@Ximines.local> <20100129113813.GB32401@nic.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20100129113813.GB32401@nic.fr>
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 Fri, Jan 29, 2010 at 12:38:13PM +0100, Stephane Bortzmeyer wrote:
> On Thu, Jan 28, 2010 at 06:10:09PM +0000,
>  Alex Bligh <alex@alex.org.uk> wrote 
>  a message of 64 lines which said:
> 
> > I have read the draft.
> 
> Me too, otherwise I wouldn't comment.
> 
> >  Given people make DNS queries in general so they can communicate
> >  with the (e.g.)  A record given, and the (e.g.) http server on that
> >  IP address can log connections, what privacy is lost by
> >  transmitting the address given in full?
> 
> 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.

	well - it sort of seems unfair to have the client know the
	address(s) of the authoritative server(s), but the authoritative
	servers have no means of knowing the address(s) of the clients.

> 
> 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.
> 
> >  You leave this choice to the recursive resolver, I think, not the
> >  client, and require that at least some bits are cleared.
> 
> The biggest privacy problem with the current draft is that, for the
> "desktop" client, the use of the new extension is opt-out, not opt-in
> (section 8.1) which disturbs me a lot.


	it is a change in legacy behaviours.

--bill

v2.23.0 | Report a Bug | By Email