Re: [perpass] DNS confidentiality

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 13 November 2013 03:04 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 4FC0311E8151 for <perpass@ietfa.amsl.com>; Tue, 12 Nov 2013 19:04:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.301
X-Spam-Level:
X-Spam-Status: No, score=-102.301 tagged_above=-999 required=5 tests=[AWL=0.298, 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 Syc09mHB+Olr for <perpass@ietfa.amsl.com>; Tue, 12 Nov 2013 19:03:53 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 48CDB21F9EE0 for <perpass@ietf.org>; Tue, 12 Nov 2013 19:03:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6D417BE6F; Wed, 13 Nov 2013 03:03:52 +0000 (GMT)
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 w0Ij0nTymxcr; Wed, 13 Nov 2013 03:03:51 +0000 (GMT)
Received: from [10.87.48.12] (unknown [86.44.75.204]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3F16DBE6E; Wed, 13 Nov 2013 03:03:51 +0000 (GMT)
Message-ID: <5282EC17.5060808@cs.tcd.ie>
Date: Wed, 13 Nov 2013 03:03:51 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Ted Lemon <mellon@fugue.com>
References: <20131111121027.GA31723@sources.org> <CEA6999F.25B2C%gwiley@verisign.com> <CA+9kkMDTYZ8tKnGigojWQDuDM3K0uPyoW2fesH1ueAFbTZMBrQ@mail.gmail.com> <CABkgnnVuX3bV1XMKsY1g6GOkZmhfxo=Zt9iUryt0wt+9K8tFkA@mail.gmail.com> <5282D6A3.5060205@cs.tcd.ie> <4AE06389-A46C-4F14-849E-62DC9FA7F128@fugue.com>
In-Reply-To: <4AE06389-A46C-4F14-849E-62DC9FA7F128@fugue.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Ted Hardie <ted.ietf@gmail.com>, perpass <perpass@ietf.org>, Stephane Bortzmeyer <bortzmeyer@nic.fr>, Andy Wilson <andrewgwilson@gmail.com>, "Wiley, Glen" <gwiley@verisign.com>, Martin Thomson <martin.thomson@gmail.com>
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: Wed, 13 Nov 2013 03:04:03 -0000

Hey Ted,

On 11/13/2013 02:48 AM, Ted Lemon wrote:
> On Nov 12, 2013, at 8:32 PM, Stephen Farrell
> <stephen.farrell@cs.tcd.ie> wrote:
>> The converse argument was just made on the TLS list yesterday to 
>> the effect that there's no point in TLS 1.3 (or a TLS 1.2
>> extension) encrypting SNI because its the same as the obviously
>> cleartext DNS query in many cases.
> 
> That's a terrible argument.   Then every eavesdropping issue becomes
> a chicken-and-egg problem, because nobody is willing to go first.

Well, I wouldn't say terrible, but it is unfortunate, yes.

In this case, there's a (presumed but realistic) tension between
the relative timing of DNS and TLS updates, the absence of each
of which makes the occurrence of the other less likely. And that
combination makes it less likely that we (the IETF) are motivated
to try "fix" either.

And all that is replicated up and down the stack - "why should
I make application layer privacy better when its so bad at the
RF layer with fingerprinting" is an argument that I have seen
made in IETF discussion.

But again, I'm for trying to do it all better, to the extent we
can and I'm not for giving up.

S.


> 
> 
>