IETF Logo Mail Archive

Re: [TLS] New Draft: Using DNS to set the SNI explicitly

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 10 March 2017 15:29 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B8D129624 for <tls@ietfa.amsl.com>; Fri, 10 Mar 2017 07:29:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8sK3UZ0RyJl for <tls@ietfa.amsl.com>; Fri, 10 Mar 2017 07:29:31 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A51C1295F1 for <tls@ietf.org>; Fri, 10 Mar 2017 07:29:31 -0800 (PST)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 964BF7A32D8 for <tls@ietf.org>; Fri, 10 Mar 2017 15:29:30 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CAHbrMsCpCH2qSG=cZjMMuWbpzCn8dQhvaTDaRc1riwnYiKGjsg@mail.gmail.com>
Date: Fri, 10 Mar 2017 10:29:30 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F223FC8-32BC-4203-B2C8-E71D5CC47764@dukhovni.org>
References: <CAHbrMsCpCH2qSG=cZjMMuWbpzCn8dQhvaTDaRc1riwnYiKGjsg@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sRDxiuDgvV_eErItTF_Ss_oducY>
Subject: Re: [TLS] New Draft: Using DNS to set the SNI explicitly
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: "<tls@ietf.org>" <tls@ietf.org>
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Mar 2017 15:29:33 -0000

> On Feb 7, 2017, at 11:12 AM, Ben Schwartz <bemasc@google.com> wrote:
> 
> Like a lot of people here, I'm very interested in ways to reduce the leakage of users' destinations in the ClientHello's cleartext SNI.  It seems like the past and current proposals to fix the leak are pretty difficult, involving a lot of careful cryptography and changes to clients and servers.
> 
> While we're trying to figure that out, I think there's a simple trick that could help a lot: just let domain owners tell users an alternate SNI in a DNS entry.
> 
> Here's the full draft:
> https://tools.ietf.org/html/draft-schwartz-dns-sni-00
> 
> If you just want to glance at it, I recommend Figure 2.
> 
> Please read and critique!  This is a starting point; the contents will change based on your input.

Instead of looking for a kludgey replacement SNI in DNS (that won't get deployed,
and provides rather weak obfuscation) it seems more sensible to publish keys in
DNS that make it possible to encrypt the entire client HELLO, SNI and all.

I do not think that the proposed SNI in DNS is worth doing.

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email