IETF Logo Mail Archive

Re: [TLS] In support of encrypting SNI

Fabrice <fabrice.gautier@gmail.com> Thu, 15 May 2014 06:23 UTC

Return-Path: <fabrice.gautier@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB8D1A03DC for <tls@ietfa.amsl.com>; Wed, 14 May 2014 23:23:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 lRMP6w9kxLVX for <tls@ietfa.amsl.com>; Wed, 14 May 2014 23:23:34 -0700 (PDT)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8B91A03D9 for <tls@ietf.org>; Wed, 14 May 2014 23:23:34 -0700 (PDT)
Received: by mail-pa0-f46.google.com with SMTP id kq14so651182pab.5 for <tls@ietf.org>; Wed, 14 May 2014 23:23:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EBUfzs0aR3lGreV/FqogGT+ZYkR/p6ftEsY7LnC+NMQ=; b=H3pfcpGobaMZ6j10QoEfwl0MmWWr6jxyuj2WpUGFwg/M8Mhcfmh7HXqH+2phi3RPLz higTHsEsc2grs9ejvS0iaNjJAgHHpCwiTteEt1HQIjB2QFGEdmfznHZpHPcCRsdOJ48U CoQdCV+7JHsbzQg/Rc8BeLj/HNlSce+OcHoGbjwcqFhq7HdYpUi5i7YB78OUW8T/qawQ tx4Df5GTKivLOQiGScmsSg8DVBYU7WgW5wj6E9g92w+XVFb/cPYX/Y7eCeH3zBz2kDvd bX4jN2RV782LZRMrb5NLOBex+vGAUlR1EC8Q1CtrMHwhpGJLDKSb8F85GuhlNZbyqjVT 2pDA==
X-Received: by 10.69.31.107 with SMTP id kl11mr10019713pbd.142.1400135007163; Wed, 14 May 2014 23:23:27 -0700 (PDT)
Received: from [10.0.1.4] (c-67-188-142-21.hsd1.ca.comcast.net. [67.188.142.21]) by mx.google.com with ESMTPSA id tb4sm16934090pac.45.2014.05.14.23.23.25 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 May 2014 23:23:25 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Fabrice <fabrice.gautier@gmail.com>
X-Mailer: iPhone Mail (11D167)
In-Reply-To: <CACsn0cmOcJF=VmCD-=1iNg=gP+THU2ZBXn_wtPOWRhaG-BeQMg@mail.gmail.com>
Date: Wed, 14 May 2014 23:23:24 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <498BFB9F-EF8D-48E2-92A9-4287491FB9B7@gmail.com>
References: <5373C4F3.3010602@blah.is> <5373d656.84c5440a.1a9b.25a0SMTPIN_ADDED_BROKEN@mx.google.com> <CACsn0cmOcJF=VmCD-=1iNg=gP+THU2ZBXn_wtPOWRhaG-BeQMg@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vbyr35kijlsyGbqif-bYY0fHbeI
Cc: ietf tls <tls@ietf.org>
Subject: Re: [TLS] In support of encrypting SNI
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: <http://www.ietf.org/mail-archive/web/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: Thu, 15 May 2014 06:23:36 -0000

> On May 14, 2014, at 15:15, Watson Ladd <watsonbladd@gmail.com> wrote:
> 
> Dear all,
> There are several different proposals for encrypted SNI floating
> around, and I'd like to take the time to summarize them:
[...]
> 3: Have DNS records contain a key to use to encrypt the handshake, key
> shared across sites hosted under the same IP address
> 4: Encrypt the handshake with a key that is per-site
> 
> [...] 4 and 3
> involve administrative action by websites, and depend on DNSSEC
> deployment: they are unlikely to be widely deployed.

If a comprehensive solution to the surveillance problem also involve changes to plug leaks by DNS, wouldn't it be reasonable that the TLS portion of the solution  depends on the DNS bits being deployed as well?

-- Fabrice

v2.23.0 | Report a Bug | By Email