Re: [TLS] Tonight's Encrypted SNI Hangout Session

Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 13 November 2017 19:11 UTC

Return-Path: <ilariliusvaara@welho.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 0D52B126B6D for <tls@ietfa.amsl.com>; Mon, 13 Nov 2017 11:11:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 VAb9DqRlyuDI for <tls@ietfa.amsl.com>; Mon, 13 Nov 2017 11:11:17 -0800 (PST)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B584D120721 for <tls@ietf.org>; Mon, 13 Nov 2017 11:11:17 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 4B2BC5DE8D; Mon, 13 Nov 2017 21:11:15 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id AZAP7P79Aabx; Mon, 13 Nov 2017 21:11:15 +0200 (EET)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id EADB327F; Mon, 13 Nov 2017 21:11:11 +0200 (EET)
Date: Mon, 13 Nov 2017 21:11:11 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: David P <dbpaull1@gmail.com>
Cc: Bret Jordan <jordan.ietf@gmail.com>, tls@ietf.org
Message-ID: <20171113191111.6gf2iigtbg4qqg5w@LK-Perkele-VII>
References: <CAPCpN4t4m9M6u=E29u=TQnBScjRTfA91K9pdyPG3nvyi+GHC3w@mail.gmail.com> <20171113175533.d2ncygry5imzqdw3@LK-Perkele-VII> <6FEBB0BE-24F1-4902-893B-7900A78E5625@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6FEBB0BE-24F1-4902-893B-7900A78E5625@gmail.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dW7rjqLZUC94dvqNRNUX1S6hJMk>
Subject: Re: [TLS] Tonight's Encrypted SNI Hangout Session
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 13 Nov 2017 19:11:20 -0000

On Mon, Nov 13, 2017 at 01:45:51PM -0500, David P wrote:
> 
> > On Nov 13, 2017, at 12:55 PM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> > 
> >> On Mon, Nov 13, 2017 at 09:28:23PM +0800, Bret Jordan wrote:
> >> 
> >> 3) We need to compile a list of use cases and scenarios in a draft document
> >> that talk about how the SNI (for good or for bad) is being used today and
> >> what an encrypted SNI will mean for these use cases.
> > 
> > What I think SNI is mainly (legimately) used for:
> > 
> > - Specify the certificate.
> > - Specify the next service (both before and after TLS termination).
> > 
> > Ideally, specifying certificate would be enough to specify the next
> > service. But we all know reality is not ideal, so it might not be.
> > In the converse direction, having multiple certificates all covering
> > the same next service is very common (e.g., it would requre special
> > setup with common webservers not to have it this way).
> > 
> > As to specifying certificate, there are many reasons why a server
> > might want multiple certificates:
> > 
> > - There are too many names to put into one certificate.
> > - Putting all the names into one certificate would be difficult to
> >  manage.
> > - The server wants to make some separation between the names.
> > - The names have different next service.
> > 
> 
> What about a use case (for SNI) of different teams (or budgets) procuring
> certificates for different sites housed on either the same server, or at
> least in the same data center behind the same load balancing device? 
> And SNI being used at a gateway, or entry point to that enterprise’s WAN. 

AFAICT, that would fall into "too difficult to manage with one
certificate" and "next service before TLS termination".

And yes, genuine encrypted SNI could be somewhat nasty for routing
before terminating TLS. And if one tries to simply use public-key
encryption, AFAICT, all the known ways are either slower than
ECDH-ES or have much larger size overhead (heck, ECDH-ES itself is
either optimal size-wise or close to it). Also, DH-ES type schemes do
not work with PQC (which is starting to be a concern).


-Ilari