Re: [TLS] Encrypted SNI

Eric Rescorla <ekr@rtfm.com> Wed, 07 June 2017 03:15 UTC

Return-Path: <ekr@rtfm.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 C5EEC129B4B for <tls@ietfa.amsl.com>; Tue, 6 Jun 2017 20:15:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 CxJleCGtUh39 for <tls@ietfa.amsl.com>; Tue, 6 Jun 2017 20:15:32 -0700 (PDT)
Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (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 02391129B5D for <tls@ietf.org>; Tue, 6 Jun 2017 20:15:28 -0700 (PDT)
Received: by mail-yb0-x232.google.com with SMTP id o9so206530yba.3 for <tls@ietf.org>; Tue, 06 Jun 2017 20:15:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3Nf+Leba9aVHx8SSm+35niEJrB8pPQpItU0onHo1+hA=; b=PrkwwHUxDrr/GedJlvMmv8xA94dh7nwJ1FiM1dPkeeTOtm54OFdqSnNrgwguRkvUwQ JNH494RSITeRC0JQAlpVOutHHHVvCsd3N/32kLEsmSUF/bynGOb1aXWb36UKhh42EFe0 NOe47ttDpaGtxNr/D3z7esOzHac/kFeBYVn5exarunIyMzDMBmH23OKy1N4gpQ3SHBPU JZ/uhMmBheixh0eQWOU79qyEB5F6pIkpuDSoHxSNT2dbGcI9MnQuCLLiQxk5/rejd9Mv Gg7hAKw2WsTiVDu0U59BLe+z6wPtBthbJsaHT42azqwgcHn0OWQzHAexXRvVjfhkgRh1 xMKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3Nf+Leba9aVHx8SSm+35niEJrB8pPQpItU0onHo1+hA=; b=t1ydo4mNbepG0KaEfbEjiihiCPNfjZ6Y7gd79sc7wyTI5RkRrsoR1gmlUlFo5N20Oh GVKymO/y2sa0SiUbInOCNq2q6+RJrTjRnQ7Ovg6+gzxNals8HiLv/YLnm4G/whWpcUCk nWO0Gqv9OaBmYv6gaQOmO3PcDOKK60hllDX/99Dc0mgtHHWqAQsfKCbMxcAAPYe7kLSq H3LFdpIHP3hzE0UQkNcYwPfrRe4PzBgg/KhxKy2iRoPRuxjaoKiFk6jCtE+UvdVREkzM UhdxMehMkG/FzKxosnUuxmgCvmbzPXm0ZMC/zNhqrc2ak1A2CUwIa5C/7BBRJU1+wavo ttbQ==
X-Gm-Message-State: AODbwcCMZ9+zJ/NacJ7XBHl29iXe9H6jYm/0U1p59YX3Q9hke8QNOAky 6et8jno3kV+FUm4XF+puN1cZD58Ec4i8
X-Received: by 10.37.171.2 with SMTP id u2mr5462190ybi.122.1496805326846; Tue, 06 Jun 2017 20:15:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.215.4 with HTTP; Tue, 6 Jun 2017 20:14:46 -0700 (PDT)
In-Reply-To: <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> <20170607025332.GK12522@faui40p.informatik.uni-erlangen.de>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 7 Jun 2017 05:14:46 +0200
Message-ID: <CABcZeBMdfU++dST53MRZJD-vn4hv8D9s-FqzP3RfGpWQoGrA-w@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Cc: Dave Garrett <davemgarrett@gmail.com>, "tls@ietf.org" <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
Content-Type: multipart/alternative; boundary="94eb2c063de6ce449505515625b2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Go63k6ZLXd99Xa9SBGfg8OxUPJg>
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 03:15:34 -0000

On Wed, Jun 7, 2017 at 4:53 AM, Toerless Eckert <tte@cs.fau.de> wrote:

>
> 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 ?
>

You won't be able to do that in TLS 1.3 either. We've removed all the
non-encryption
cipher suites (though someone could define more off the Standards Track).

However, with that said, I don't think that this is a very good analogy.
Having
unencrypted certs even as an options would significantly impact the state
machine,
whereas null ciphers do not

-Ekr




> 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
>