Re: [TLS] In support of encrypting SNI

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 14 May 2014 22:01 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 900821A01F6 for <tls@ietfa.amsl.com>; Wed, 14 May 2014 15:01:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 kw5h3EU_PXxv for <tls@ietfa.amsl.com>; Wed, 14 May 2014 15:01:12 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DAA241A0203 for <tls@ietf.org>; Wed, 14 May 2014 15:01:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 285B5BE63; Wed, 14 May 2014 23:01:04 +0100 (IST)
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 ydQ2PpYa8tMN; Wed, 14 May 2014 23:01:02 +0100 (IST)
Received: from [10.87.48.12] (unknown [86.44.79.203]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BD14ABE5B; Wed, 14 May 2014 23:01:02 +0100 (IST)
Message-ID: <5373E79E.7090008@cs.tcd.ie>
Date: Wed, 14 May 2014 23:01:02 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "Salz, Rich" <rsalz@akamai.com>, Dan Blah <dan@blah.is>, ietf tls <tls@ietf.org>
References: <5373C4F3.3010602@blah.is> <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA846@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA846@USMBX1.msg.corp.akamai.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lhwL0RBsDuE81pXEplCxeKzvMN0
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: Wed, 14 May 2014 22:01:14 -0000


On 14/05/14 21:35, Salz, Rich wrote:
> Dan, thanks for writing the passionate and detailed note.
> 
>> . Surely any crucial increase of free expression we here can give
>> others out weighs technicalities.
> 
> I just want to let you know that, somewhat sadly, I disagree with the
> quoted sentence, and I'm not alone.  (Even the author of the "it's an
> attack" RFC has said that barring good technical solutions we're
> unlikely to do it.) Encrypting the handshake will not prevent passive
> surveillance. From a technical view, it's not clear it provides
> enough privacy to justify the non-inconsiderable costs.

I think you've slightly misinterpreted me there Rich, I'll try be
clearer:-)

Yes we do need a good technical solution and we don't yet have
one written down. There is an of course obvious technical solution
for at least passive attacks, but that does have the significant
and real negative aspect that you pointed out, so is perhaps not
good enough by itself.

I'm also less concerned with monetary costs (most who are running
large numbers of TLS instances like you guys could afford some
monetary costs:-) but more with the architectural problem that the
TLS stacks running in different VMs would not be willing to agree
on SNI protection algorithms etc. should a solution require those
to be the same across all VMs. But I'm not at all clear that's
insurmountable really.

So same point I made before: we need folks who want this to put
in the work to write down their solutions. (And the corollary is
that if we don't figure out how to protect SNI then we need to
document why fairly well, not necessarily in an RFC, but in some
kind of referenceable thing.)

Cheers,
S.

PS: And again, wearing no hats for this conversation.

> 
> /r$
> 
> -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM:
> rsalz@jabber.me; Twitter: RichSalz
> 
> _______________________________________________ TLS mailing list 
> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
>