Re: [TLS] Encrypted SNI

[Eric Rescorla <[e-mail]>]

On Wed, Jun 7, 2017 at 4:53 AM, Toerless Eckert <[e-mail]> 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).
>
> --
> ---
> [e-mail]
>