Re: [TLS] Encrypted SNI

Toerless Eckert <tte@cs.fau.de> Wed, 07 June 2017 00:36 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 C3DE4127286; Tue, 6 Jun 2017 17:36:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 ggMId-_i7mwe; Tue, 6 Jun 2017 17:36:41 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8467C128961; Tue, 6 Jun 2017 17:36:41 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 376AB58C4EC; Wed, 7 Jun 2017 02:36:38 +0200 (CEST)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 19A97B0C207; Wed, 7 Jun 2017 02:36:38 +0200 (CEST)
Date: Wed, 7 Jun 2017 02:36:38 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Benjamin Kaduk <bkaduk@akamai.com>
Cc: "ops-dir@ietf.org" <ops-dir@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>, Benoit Claise <bclaise@cisco.com>, "sec-ads@ietf.org" <sec-ads@ietf.org>, "ops-ads@ietf.org" <ops-ads@ietf.org>, ops-chairs@ietf.org
Message-ID: <20170607003637.GI12522@faui40p.informatik.uni-erlangen.de>
References: <CAHbuEH4Bwr13T-cBFvLmUmn6KRzuNf1su6VTeJguyssk6S2z3g@mail.gmail.com> <4d2f195a-c61b-4abb-9b33-bc36773775cd@cisco.com> <20170602084300.GB12522@faui40p.informatik.uni-erlangen.de> <CAL02cgS+eym_=TNupJo0f0qAFgZc14rXNfO=VdGzRX28jXVqkQ@mail.gmail.com> <20170602103151.GC12522@faui40p.informatik.uni-erlangen.de> <CAErg=HG8NFmuX7NUR3tLXbstzj2Spgc_dyh6b5DZqCFh73dt=Q@mail.gmail.com> <20170602132833.GE12522@faui40p.informatik.uni-erlangen.de> <2f5c3b10-0ad0-466a-03ef-495fa6acb7bc@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2f5c3b10-0ad0-466a-03ef-495fa6acb7bc@akamai.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/q6vZT2ZN7Xqkecd7Xim8_t75jxs>
Subject: Re: [TLS] Encrypted SNI
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: Wed, 07 Jun 2017 00:36:44 -0000

So no options in TLS 1.3 that make it possible to see the server cert in the clear ?

On Sun, Jun 04, 2017 at 03:25:46PM -0500, Benjamin Kaduk wrote:
> On 06/02/2017 08:28 AM, Toerless Eckert wrote:
> > Another candidate use case coming to mind eg: auditing tht is required in many eg: financial
> > environments. In the past i have seen even the requirement for the whole data streams to be unencrypted
> > for auditing. Maybe that market segment would also be able to get more privacy but maintain a
> > relevant level of auditing if the auditing relevant class of information was visible via
> > the cert.
> 
> That use case has been extensively discussed (look for the thread
> "Industry Concerns about TLS 1.3", also a fair bit of hallway
> discussions), and was not seen to provide a compelling argument for any
> change in TLS 1.3.  There are purely server-side options that should be
> able to provide the necessary functionality (crypto details omitted for
> now).
> 
> -Ben