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

Stephane Bortzmeyer <bortzmeyer@nic.fr> Fri, 29 January 2010 11:43 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 921A63A687B; Fri, 29 Jan 2010 03:43:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level:
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 YXhcIOcGubZ9; Fri, 29 Jan 2010 03:43:57 -0800 (PST)
Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id CD4203A676A; Fri, 29 Jan 2010 03:43:57 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1NapB1-000JCk-Sr for namedroppers-data0@psg.com; Fri, 29 Jan 2010 11:38:15 +0000
Received: from [2001:660:3003:2::4:11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <bortzmeyer@nic.fr>) id 1NapAz-000JCD-NC for namedroppers@ops.ietf.org; Fri, 29 Jan 2010 11:38:13 +0000
Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 0A9861C0181; Fri, 29 Jan 2010 12:38:13 +0100 (CET)
Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 05DED1C0180; Fri, 29 Jan 2010 12:38:13 +0100 (CET)
Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 03D1F7B0034; Fri, 29 Jan 2010 12:38:13 +0100 (CET)
Date: Fri, 29 Jan 2010 12:38:13 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Alex Bligh <alex@alex.org.uk>
Cc: namedroppers@ops.ietf.org
Subject: [dnsext] Privacy in IP address indication (Was: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt
Message-ID: <20100129113813.GB32401@nic.fr>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <FDD5D1103B8EA4D13C4A2C4C@Ximines.local>
X-Operating-System: Debian GNU/Linux 5.0.3
X-Kernel: Linux 2.6.26-2-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.18 (2008-05-17)
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 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.

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.