Re: [perpass] DNS confidentiality

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 30 September 2013 00:44 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4110921F81FF for <perpass@ietfa.amsl.com>; Sun, 29 Sep 2013 17:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Level:
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtLjJpZqFDJY for <perpass@ietfa.amsl.com>; Sun, 29 Sep 2013 17:43:59 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 821BC21F9E98 for <perpass@ietf.org>; Sun, 29 Sep 2013 17:43:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 648F7BE60; Mon, 30 Sep 2013 01:43:57 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDHxdDvPVYQa; Mon, 30 Sep 2013 01:43:56 +0100 (IST)
Received: from [10.87.48.11] (unknown [86.42.27.255]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 29013BE5B; Mon, 30 Sep 2013 01:43:56 +0100 (IST)
Message-ID: <5248C94B.2010100@cs.tcd.ie>
Date: Mon, 30 Sep 2013 01:43:55 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <006a01ceb96a$335c1df0$9a1459d0$@rozanak.com> <1380137874.48631.YahooMailNeo@web125502.mail.ne1.yahoo.com> <005901ceba2a$f854c1a0$e8fe44e0$@rozanak.com> <1380218914.85280.YahooMailNeo@web125502.mail.ne1.yahoo.com> <003901cebba5$b2762c10$17628430$@rozanak.com> <1380307285.91976.YahooMailNeo@web125501.mail.ne1.yahoo.com> <20130929182804.GA20577@sources.org>
In-Reply-To: <20130929182804.GA20577@sources.org>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: 'perpass' <perpass@ietf.org>
Subject: Re: [perpass] DNS confidentiality
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Sep 2013 00:44:07 -0000

Stephane,

On 09/29/2013 07:28 PM, Stephane Bortzmeyer wrote:
> On Fri, Sep 27, 2013 at 11:41:25AM -0700,
>  Karl Malbrain <malbrain@yahoo.com> wrote 
>  a message of 138 lines which said:
> 
>> I'm concerned about three DNS security problems:
> 
> You're not concerned about the fact that DNS servers (your resolver,
> and the authoritative name servers) get a lot of data and can misuse
> it? It seems to be that it is one of the main weaknesses of DNS, when
> it comes to confidentiality. A big public resolver, like OpenDNS or
> Google Public DNS (both located in PRISMland) can learn a lot of
> things about its users (this has been used often to detect malware,
> only from its DNS requests, but it could be used for more sinister
> purposes). A big TLD (say, for example, .com, also located in
> PRISMland) can also learn a lot.
> 
> And no amount of cryptographe between the client and this server will
> help.

Does that mean that there's scope for a BCP on ways of deploying
DNS that are more (or less) privacy friendly? While I guess a bunch
of n/w operators might not care, I'm pretty sure some would. (And
could perhaps get some competetive benefit from demonstrably caring
via following such a BCP.)

Additionally, if you're arguing that there's no useful role at all
for confidentiality in DNS then I think I'd argue that confidentiality
could well be useful, but that it won't by itself be sufficiently
useful to be worth deploying and so is only worthwhile in conjunction
with some already privacy-friendly deployment of DNS servers. Sound
wrong? Or right? If right, then maybe there's scope for some
experimental RFC(s) to go with that BCP.

Volunteers very welcome as usual:-) If you're one, just go write the
internet-draft and we'll catch up with you after you've posted a
link here.

Cheers,
S.


>