IETF Logo Mail Archive

Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3

"Salz, Rich" <rsalz@akamai.com> Thu, 07 November 2013 19:56 UTC

Return-Path: <rsalz@akamai.com>
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 B055311E81F3 for <tls@ietfa.amsl.com>; Thu, 7 Nov 2013 11:56:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.598
X-Spam-Level:
X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 7J36A9J5E4LU for <tls@ietfa.amsl.com>; Thu, 7 Nov 2013 11:56:03 -0800 (PST)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3733911E8296 for <tls@ietf.org>; Thu, 7 Nov 2013 11:55:49 -0800 (PST)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 707EB284F9; Thu, 7 Nov 2013 19:55:48 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 58F10284F7; Thu, 7 Nov 2013 19:55:48 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 4E52C202A; Thu, 7 Nov 2013 19:55:48 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.206]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Thu, 7 Nov 2013 14:55:48 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Yoav Nir <ynir@checkpoint.com>, Ryan Hurst <ryan.hurst@globalsign.com>
Date: Thu, 07 Nov 2013 14:55:47 -0500
Thread-Topic: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
Thread-Index: AQHO29cQ9VyMic6aPkyI1tVd5LOXZJoZ1sKAgAAGd4CAAAeWAIAABPCAgAAhNICAACMt4A==
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF248@USMBX1.msg.corp.akamai.com>
References: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com> <CACsn0c=VWmsfxvE_17+FyBASUXPCNrS1FQQ02fzhF5rA6zx4wQ@mail.gmail.com> <CA+BZK2oAj6FmXTbDoY0oRHpHFVzeN-NmDJde2mJTwOzBW0CdiQ@mail.gmail.com> <EEF0FE50-3032-4C7B-BA07-1845CDEDA155@checkpoint.com> <eb6ba436dfc994f6079ba798d048a02c@mail.gmail.com> <68078EDD-F924-4AA5-A605-E7B688509EE3@checkpoint.com>
In-Reply-To: <68078EDD-F924-4AA5-A605-E7B688509EE3@checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 07 Nov 2013 19:56:07 -0000

> IMO, if both sites are either collocated on the same machine, or hosted behind the same SSL accelerator, they already share enough that multi-SAN is not a bad thing.

Our experience disagrees.

> With SNI is it currently stands, the site you are looking for is sent in the clear. If we keep the choose-certificate functionality in 1.3, we still leave it exposed in either the SNI or in the certificate that the server sends. A generic certificate is the only one that hides what the client is browsing.

First, a disclaimer that this isn't a use-case my employer cares about much; on a personal note, I want more privacy.  But I don't see how you can make a 'generic certificate' that really meets the desired goal.  You already can't make a wildcard SAN for "*.com" or "*.co.uk" for example.

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

v2.23.0 | Report a Bug | By Email