Re: [perpass] DNS confidentiality

Ted Hardie <ted.ietf@gmail.com> Wed, 13 November 2013 16:17 UTC

Return-Path: <ted.ietf@gmail.com>
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 DC9BA21E80A9 for <perpass@ietfa.amsl.com>; Wed, 13 Nov 2013 08:17:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.505
X-Spam-Level:
X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 oWFKnVhjFJDR for <perpass@ietfa.amsl.com>; Wed, 13 Nov 2013 08:17:01 -0800 (PST)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1910821E8152 for <perpass@ietf.org>; Wed, 13 Nov 2013 08:16:55 -0800 (PST)
Received: by mail-wi0-f171.google.com with SMTP id hn6so2625535wib.10 for <perpass@ietf.org>; Wed, 13 Nov 2013 08:16:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jf/dUMIBFKn1ImjUwHFeIDITfBENiYvSooeYwD+CWnA=; b=xEvkEF7OoJSEVcYrfQMsWlX4h9b/l89ML8fHg47n8VVYy48YCMHoFaG3IwiI8zExui TaUSERzzMVIbuazGTn5MOKOivmsBNlabPGosKHGaKqKw9hpA5vLM1oxgyHwjZ+BSYenM A4pPyGMLbCYMNh0a8G3iTWSscMhYhyEDqpL5lcu5kYl3dD9wMvuCuHssdbB7HsWU9hFo 64ZQBd7XMQf6/lEZMpp7WogTCwMncATrl9EraxaWiMtkHxm/kI6EaRkkqhw7MRWLdn/J Bj86CENDspcDnHhs+nC3BzA03MJu7pFo3e/V187oyU7hvzzX08oDWtYIcltYN0GEdHxx iQEA==
MIME-Version: 1.0
X-Received: by 10.180.94.162 with SMTP id dd2mr17669101wib.38.1384359415252; Wed, 13 Nov 2013 08:16:55 -0800 (PST)
Received: by 10.227.27.73 with HTTP; Wed, 13 Nov 2013 08:16:55 -0800 (PST)
In-Reply-To: <CABkgnnVuX3bV1XMKsY1g6GOkZmhfxo=Zt9iUryt0wt+9K8tFkA@mail.gmail.com>
References: <20131111121027.GA31723@sources.org> <CEA6999F.25B2C%gwiley@verisign.com> <CA+9kkMDTYZ8tKnGigojWQDuDM3K0uPyoW2fesH1ueAFbTZMBrQ@mail.gmail.com> <CABkgnnVuX3bV1XMKsY1g6GOkZmhfxo=Zt9iUryt0wt+9K8tFkA@mail.gmail.com>
Date: Wed, 13 Nov 2013 08:16:55 -0800
Message-ID: <CA+9kkMCUaVJSzisvePLWbNPh0_5HcrsWg+-OR_EgvoB8Y2KaBw@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="f46d04462ea830335d04eb114b65"
Cc: "Wiley, Glen" <gwiley@verisign.com>, perpass <perpass@ietf.org>, Stephane Bortzmeyer <bortzmeyer@nic.fr>, Andy Wilson <andrewgwilson@gmail.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
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 16:17:04 -0000

On Tue, Nov 12, 2013 at 5:16 PM, Martin Thomson <martin.thomson@gmail.com>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.
>

True; I'd been thinking about the blogspot-style use cases where you get an
initial negotiation at one name followed by a large set of alternate names,
but that's not the common case.  The VPN case is still an issue, though.

Having read through the rest of the thread, pushing SNI into the encrypted
portion of TLS in 1.3 seems like a good thing to do.

Ted