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.
- Re: [perpass] DNS confidentiality Wiley, Glen
- Re: [perpass] DNS confidentiality Andy Wilson
- [perpass] DNS confidentiality Stephen Farrell
- Re: [perpass] DNS confidentiality Karl Malbrain
- Re: [perpass] DNS confidentiality Hosnieh Rafiee
- Re: [perpass] DNS confidentiality Paul Wouters
- Re: [perpass] DNS confidentiality Stephane Bortzmeyer
- Re: [perpass] DNS confidentiality Ben Laurie
- Re: [perpass] DNS confidentiality Mark Handley
- Re: [perpass] DNS confidentiality Stephen Farrell
- Re: [perpass] DNS confidentiality Stephane Bortzmeyer
- Re: [perpass] DNS confidentiality Joseph Lorenzo Hall
- Re: [perpass] DNS confidentiality Karl Malbrain
- Re: [perpass] DNS confidentiality Paul Wouters
- Re: [perpass] DNS confidentiality Karl Malbrain
- Re: [perpass] DNS confidentiality Karl Malbrain
- Re: [perpass] DNS confidentiality Stephen Farrell
- Re: [perpass] DNS confidentiality Hosnieh Rafiee
- Re: [perpass] DNS confidentiality Karl Malbrain
- Re: [perpass] DNS confidentiality Phillip Hallam-Baker
- Re: [perpass] DNS confidentiality Phillip Hallam-Baker
- Re: [perpass] DNS confidentiality Hosnieh Rafiee
- Re: [perpass] DNS confidentiality Karl Malbrain
- Re: [perpass] DNS confidentiality Phillip Hallam-Baker
- Re: [perpass] DNS confidentiality Hosnieh Rafiee
- Re: [perpass] DNS confidentiality manning bill
- Re: [perpass] DNS confidentiality Hosnieh Rafiee
- Re: [perpass] DNS confidentiality Karl Malbrain
- Re: [perpass] DNS confidentiality Stephen Farrell
- Re: [perpass] DNS confidentiality Karl Malbrain
- Re: [perpass] DNS confidentiality Hosnieh Rafiee
- Re: [perpass] DNS confidentiality Christian Huitema
- Re: [perpass] DNS confidentiality Stephane Bortzmeyer
- Re: [perpass] DNS confidentiality Stephen Farrell
- Re: [perpass] DNS confidentiality Stephane Bortzmeyer
- Re: [perpass] DNS confidentiality Wiley, Glen
- Re: [perpass] DNS confidentiality Ted Hardie
- Re: [perpass] DNS confidentiality Martin Thomson
- Re: [perpass] DNS confidentiality Stephen Farrell
- Re: [perpass] DNS confidentiality Wiley, Glen
- Re: [perpass] DNS confidentiality Ted Lemon
- Re: [perpass] DNS confidentiality Stephen Farrell
- Re: [perpass] DNS confidentiality Yoav Nir
- Re: [perpass] DNS confidentiality Christian Huitema
- Re: [perpass] DNS confidentiality Stephane Bortzmeyer
- Re: [perpass] DNS confidentiality Stephane Bortzmeyer
- Re: [perpass] DNS confidentiality Stephane Bortzmeyer
- Re: [perpass] DNS confidentiality Ondřej Surý
- Re: [perpass] DNS confidentiality Michael Richardson
- Re: [perpass] DNS confidentiality Ted Lemon
- Re: [perpass] DNS confidentiality Dan York
- Re: [perpass] DNS confidentiality Ted Hardie
- Re: [perpass] DNS confidentiality Wiley, Glen
- Re: [perpass] DNS confidentiality Stephane Bortzmeyer
- Re: [perpass] DNS confidentiality Stephane Bortzmeyer
- Re: [perpass] DNS confidentiality Stephane Bortzmeyer
- Re: [perpass] DNS confidentiality Stephen Farrell