Re: [TLS] Encrypted SNI

Toerless Eckert <tte@cs.fau.de> Wed, 07 June 2017 02:53 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 F08BB129534; Tue, 6 Jun 2017 19:53:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 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, 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 xqVkGLNNnj8j; Tue, 6 Jun 2017 19:53:37 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C1C12943E; Tue, 6 Jun 2017 19:53:36 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id F2AEE58C4EC; Wed, 7 Jun 2017 04:53:32 +0200 (CEST)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id DA52DB0C1A0; Wed, 7 Jun 2017 04:53:32 +0200 (CEST)
Date: Wed, 7 Jun 2017 04:53:32 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Dave Garrett <davemgarrett@gmail.com>
Cc: tls@ietf.org, Benjamin Kaduk <bkaduk@akamai.com>, "ops-dir@ietf.org" <ops-dir@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: <20170607025332.GK12522@faui40p.informatik.uni-erlangen.de>
References: <CAHbuEH4Bwr13T-cBFvLmUmn6KRzuNf1su6VTeJguyssk6S2z3g@mail.gmail.com> <2f5c3b10-0ad0-466a-03ef-495fa6acb7bc@akamai.com> <20170607003637.GI12522@faui40p.informatik.uni-erlangen.de> <201706062159.17282.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201706062159.17282.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/vc7CD4mBXYUo-J9qdLhu06DefMU>
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 02:53:39 -0000

Thanks. Just in case anyone is counting
I think thats a bad choice that limits the usefulness of 1.3. And it will just
cause less security in systems where logging etc. is required than if this
was possible by apps to configure.

Why can i negotiate a cipher suite without encryption but not disable cert encryption ?
The argument you gave could equally be made to not permit a cipher suite without encryption,
right ?  

Cheers
    Toerless

On Tue, Jun 06, 2017 at 09:59:16PM -0400, Dave Garrett wrote:
> Correct; certs are never in the clear. There is no scenario where anything will be unencrypted after the hellos in TLS 1.3+. If you're doing anything with an old system that relies on this, the general advice is to upgrade your old system to not do that anymore. If you're logging traffic from some server(s), log the traffic on those server(s) instead of MitMing. See old threads for more detail.
> 
> 
> Dave
> 
> 
> On Tuesday, June 06, 2017 08:36:38 pm Toerless Eckert wrote:
> > 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).

-- 
---
tte@cs.fau.de