Re: [TLS] Encrypted SNI

Dave Garrett <davemgarrett@gmail.com> Sat, 05 December 2015 20:53 UTC

Return-Path: <davemgarrett@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 546901A1B5F for <tls@ietfa.amsl.com>; Sat, 5 Dec 2015 12:53:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no
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 hckHlJdXMhC7 for <tls@ietfa.amsl.com>; Sat, 5 Dec 2015 12:53:55 -0800 (PST)
Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 548271A1B4B for <tls@ietf.org>; Sat, 5 Dec 2015 12:53:55 -0800 (PST)
Received: by qgec40 with SMTP id c40so116351049qge.2 for <tls@ietf.org>; Sat, 05 Dec 2015 12:53:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=JGBsGg+eRgzTo38gAfoQtzVzuyG/OHLx1EANH9DL9/8=; b=CcX5aZ1tk2ky3FDw5S7+SvUHW7SbKGo0p3Ldo/oD+jTxnPxQULriX7vdeFlPZuvNqL jvBJUkp8igTqjafZrmUS0umqNdM71TkUvvVLhezNed7y+V7X/Xl2qbm7nE9GKk3tJOa0 EwnI28kFPK3KN7opNMybHSu1L2IBnCI4iXqUCgq1jyt9Yk9G/ouJJwLKIfnFyXkU6HEB IpTK7bAIt7jUKuj1EjCEivg6LLnWQXBm20AQCEBfmGHPHuPgugDprDna2tLniO7zjihA 6yE5v85zNp4CpOokTSz/AHd1TVsBAdThh+iEwTm+INhE0mJBm4xPpPJC/b9Bu+YtMWfW FufQ==
X-Received: by 10.140.166.10 with SMTP id m10mr27716796qhm.35.1449348834590; Sat, 05 Dec 2015 12:53:54 -0800 (PST)
Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id p17sm8251913qhb.34.2015.12.05.12.53.54 (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 05 Dec 2015 12:53:54 -0800 (PST)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Sat, 5 Dec 2015 15:53:52 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <CABcZeBPFAp4hD3ykY9pAA4=ELsAkNoa2yDhaoiSP917v5XgAiw@mail.gmail.com>
In-Reply-To: <CABcZeBPFAp4hD3ykY9pAA4=ELsAkNoa2yDhaoiSP917v5XgAiw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201512051553.53074.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/BdQEAzk3vdndgTdsbBVlwoqGJsA>
Subject: Re: [TLS] Encrypted 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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 05 Dec 2015 20:53:57 -0000

On Saturday, December 05, 2015 01:32:11 pm Eric Rescorla wrote:
> Subject: SNI Encryption Part XLVIII
> 
> Folks,
> 
> TL;DR.
> This message describes a technique for doing SNI encryption that just
> requires (re)adding EncryptedExtensions to the client's first flight [0]
> defining an extension that indicates "tunnelled TLS" and (maybe) a new
> TLS content type. We would only tunnel the first flight and everything
> else would be handed off to the hidden service. This seems like the
> minimal change to enable Encrypted SNI while retaining our existing
> analytical frame for the rest of TLS.
[...snip...]

Neat. This design is modeled more similarly to what SNI is actually for and this generalized approach may be useful for other applications. Not that simple, but we knew that we weren't going to get that here.

This is actually more than just SNI encryption; every possible indicator in a server's first flight gets encrypted here. We can get encrypted ALPN through this too, which could be nice to have. It would give ideal protection against attempts to identify the intended server via ClientHello fingerprinting, in general. (still a finite amount of virtual hosts to guess from, but that's not fixable here)

Sounds like a good proposal to me. :)


Dave