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

Jacob Appelbaum <jacob@appelbaum.net> Fri, 08 November 2013 01:52 UTC

Return-Path: <jacob@appelbaum.net>
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 1A5AC21E814C for <tls@ietfa.amsl.com>; Thu, 7 Nov 2013 17:52:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level:
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_LOW=-1]
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 tOeVF7teYRqX for <tls@ietfa.amsl.com>; Thu, 7 Nov 2013 17:51:55 -0800 (PST)
Received: from mail-ea0-f171.google.com (mail-ea0-f171.google.com [209.85.215.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0766C11E81BB for <tls@ietf.org>; Thu, 7 Nov 2013 17:51:54 -0800 (PST)
Received: by mail-ea0-f171.google.com with SMTP id h15so608080eak.2 for <tls@ietf.org>; Thu, 07 Nov 2013 17:51:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=aMCFD8XK2oT4p84iQCB1bXmxffn+SaYOYC9GsTA9Y4g=; b=Gdw3Vg/fsQJrwaQMhAOR5s/oikVM1xLam4bBPGx4FGRxa7yKssYklTx/ZZefPw//z2 ZWBIVeiouuJP2Y9wXyuyGpMyIUGeBJViuVYvivXiYB4U41ZD2X57F8y3e7drC+B/bor6 Uhfbw+M6u0Olt2nYTpSj0PGjVvE8fvjK0y//xnkmyBnxUg8ZDt4lY0oLulhLpbt76prS YdsDqBbnunsBsPGv1pTEzOPqKfTFKPxZZumKy2RudnFuI+CG6HA24t4fliCfI2zd1BwQ /cAkCBXs/cU3iS869Qi9ksnOLumninUuNqlk/mQXd2iKZtc6uLHqmloGfudB6gkfWIlO XzOQ==
X-Gm-Message-State: ALoCoQkII01bg0bDZMQOZMJNbgplYzmQW6phKpxKi0/4FoY3cdWJP7tbSTd6FBdv7GmVePD7hNFd
X-Received: by 10.15.75.73 with SMTP id k49mr12741397eey.36.1383875513788; Thu, 07 Nov 2013 17:51:53 -0800 (PST)
Received: from 127.0.0.1 ([37.221.160.203]) by mx.google.com with ESMTPSA id a6sm16336836eei.10.2013.11.07.17.51.50 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 17:51:52 -0800 (PST)
Message-ID: <527BDB0D.5050505@appelbaum.net>
Date: Thu, 07 Nov 2013 18:25:17 +0000
From: Jacob Appelbaum <jacob@appelbaum.net>
MIME-Version: 1.0
To: tls@ietf.org
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>
In-Reply-To: <EEF0FE50-3032-4C7B-BA07-1845CDEDA155@checkpoint.com>
OpenPGP: id=4193A197
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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: Fri, 08 Nov 2013 01:52:01 -0000

Yoav Nir:
> Hi, Ralf.
> 
> I'm not disagreeing with you regarding 1.3. At least in the long
> version of the handshake (which you should be able to enable in any
> browser, if you want a little more privacy in exchange for an extra
> roundtrip).
> 
> But ordinarily, the sites that can get you killed are not collocated
> with benign sites. 

I disagree. Cloud computing is a good counter example. AppSpot is the
perfect example where there are more benign sites than dangerous sites
and it is easy to use it for interesting tricks.

> And even when sites are collocated, the servers
> demux not based on the SNI parameter in the TLS handshake, but based
> on the Server header in HTTP. The only use of the SNI parameter is
> for selecting the right certificate. So if you try to go to
> https://www.gmail.com , you get a certificate for
> www.gmail.com<http://www.gmail.com> , before being redirected to the
> same server, but this time with the URI https://mail.google.com .
> 

The DPI boxes demux on whatever they can steal off of the wire.

> It would be much nicer if we could update HTTPS (RFC 2818) to support
> this kind of multi-homing so as to make SNI superfluous. For example,
> if the server certificate could list the different domain names that
> it was valid for. Yes, I know there's an economic side to this as
> well. I'm sure the CAs could charge by alternate name if needed.

I agree that RFC 2818 should be updated to reflect these kinds of uses.

All the best,
Jacob