Re: [TLS] About encrypting SNI

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 14 May 2014 15:25 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 231281A00B8 for <tls@ietfa.amsl.com>; Wed, 14 May 2014 08:25:57 -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 XKq8CF65cbkC for <tls@ietfa.amsl.com>; Wed, 14 May 2014 08:25:55 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id F04871A008F for <tls@ietf.org>; Wed, 14 May 2014 08:25:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AC86DBE63; Wed, 14 May 2014 16:25:47 +0100 (IST)
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 c6ba0PB5KpVz; Wed, 14 May 2014 16:25:47 +0100 (IST)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 88934BE56; Wed, 14 May 2014 16:25:47 +0100 (IST)
Message-ID: <53738AFC.4060904@cs.tcd.ie>
Date: Wed, 14 May 2014 16:25:48 +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>, Nikos Mavrogiannopoulos <nmav@redhat.com>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <D2CB0B72-A548-414C-A926-A9AA45B962DA@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <CACsn0cmusUc3Rsb2Wof+dn0PEg3P0bPC3ZdJ75b9kkZ5LDGu_A@mail.gmail.com> <534DB18A.4060408@mit.edu> <CABcZeBOJ7k8Hb9QqCAxJ_uev9g_cb4j361dp7ANvnhOOKsT7NA@mail.gmail.com> <CA+cU71kFo6EihTVUrRRtBYEHbZwCa9nZo-awt4Sub2qXcKHC7g@mail.gmail.com> <CAK3OfOi1x9huaazwcO=d72mfOFuV_RyXnfHmFRduhhbJE2miYw@mail.gmail.com> <CALCETrWukS2QJSb01n7OpXD2iaK43OhZr4E8YZyJ6JaorCdBKw@mail.gmail.com> <CAKC-DJjgFrAmxkC-MsmL+-uRWpN_mDPGkV_g-6DhbVH+69EQEQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA050@USMBX1.msg.corp.akamai.com> <53725C34.8060105@fifthhorseman.net> <1400053497.2757.12.camel@dhcp-2-127.brq.redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA62A@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA62A@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/5Yd5FkyJ3TofKi2YfpXuU6WY0Cc
Cc: "tls@ietf.org" <tls@ietf.org>, Andy Lutomirski <luto@amacapital.net>
Subject: Re: [TLS] About 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 15:25:57 -0000


On 14/05/14 16:13, Salz, Rich wrote:
>> Load balancers and redirectors will need to terminate TLS in order
>> to redirect the traffic to the proper host.
> 
> Which we know have been interdicted by various national security
> adversaries.

True. However, there's also tempora as well, so there may be
benefits even if not all adversaries are countered. I'm not
saying we have a good enough way to do that yet, but increasing
the costs to the adversary and forcing what was covert to be
more overt is part of the game too. Something that only worked
against passive things like tempora could in principle be
worthwhile if it forced the adversary to have to get their
stuff into the CDN/data-center. If we could do better that'd
be great. If we can only counter a tempora-like attack and
the costs for doing so are quite high then there would be a
case to be made for living with tempora perhaps, but I'd
rather not myself.

S.


> 
> /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
> 
>