Re: [perpass] DNS confidentiality

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 13 November 2013 01:32 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 75AAA11E816D for <perpass@ietfa.amsl.com>; Tue, 12 Nov 2013 17:32:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.273
X-Spam-Level:
X-Spam-Status: No, score=-102.273 tagged_above=-999 required=5 tests=[AWL=0.327, 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 dSdL1l5O+sTt for <perpass@ietfa.amsl.com>; Tue, 12 Nov 2013 17:32:27 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 46D4421E809C for <perpass@ietf.org>; Tue, 12 Nov 2013 17:32:21 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 90C83BE73; Wed, 13 Nov 2013 01:32:20 +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 IDGn-uChz6pm; Wed, 13 Nov 2013 01:32:19 +0000 (GMT)
Received: from [10.87.48.12] (unknown [86.44.75.204]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6DCBABE6E; Wed, 13 Nov 2013 01:32:19 +0000 (GMT)
Message-ID: <5282D6A3.5060205@cs.tcd.ie>
Date: Wed, 13 Nov 2013 01:32:19 +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: Martin Thomson <martin.thomson@gmail.com>, Ted Hardie <ted.ietf@gmail.com>
References: <20131111121027.GA31723@sources.org> <CEA6999F.25B2C%gwiley@verisign.com> <CA+9kkMDTYZ8tKnGigojWQDuDM3K0uPyoW2fesH1ueAFbTZMBrQ@mail.gmail.com> <CABkgnnVuX3bV1XMKsY1g6GOkZmhfxo=Zt9iUryt0wt+9K8tFkA@mail.gmail.com>
In-Reply-To: <CABkgnnVuX3bV1XMKsY1g6GOkZmhfxo=Zt9iUryt0wt+9K8tFkA@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "Wiley, Glen" <gwiley@verisign.com>, perpass <perpass@ietf.org>, Stephane Bortzmeyer <bortzmeyer@nic.fr>, Andy Wilson <andrewgwilson@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 01:32:33 -0000

On 11/13/2013 01:16 AM, Martin Thomson wrote:
> On 12 November 2013 08:12, Ted Hardie <ted.ietf@gmail.com> wrote:
>> The DNS query tells you which resource was the target even if the HTTP flow
>> was protected by TLS.
> 
> In practice, since server name indication is sent in the clear, even
> this doesn't help.  Unless you are running a browser from 2001, you
> are sending SNI.
> 
> That said, SNI may be pushed into an encrypted payload in TLS 1.3.
> The challenge there is that servers often use SNI to select what
> credentials to offer.

Actually, I think that's maybe interestingly illustrative of some
of the non-crypto issues we face.

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. (Not in all cases being due to VPNs, but that's
not the point.)

I think there are at least two credible choices for how one regards
attempts to counter traffic analysis: 1) give up, its too hard, and
going to get worse no matter what we try do, or 2) try chip away at
the problem as and when we can in the hope we eventually do make it
better.

There are probably more as well, but I'm for (2) even though I can
understand those who think (1) is much more practical. Or maybe I
just hate giving up;-)

S.