Subject: Re: [TLS] Encrypted SNI

From: Toerless Eckert <[email-masked]>
Date: Fri, 2 Jun 2017 10:43:00 +0200

Thanks, Benoit

[hope it's ok. to cross-port and redirect replies to TLS]

I have not followed TLS 1.3 in detail, so a quick question first:

Will TLS 1.3 still permit servers to send their certificate and/or SNI in the clear as an option or
will it force server operators to encrypt either/or ? If it does not permit server applications
to indicate what to encrypt, then i would really love to know which shared web-hosters did
explicitly express support for TLS 1.3.

Use case: (i can't believe this hasn't been discussed _forever_, but i do not subscribe to TLS...)

Operators of "client-side" networks want to be able to enforce policies which "web-services"
their clients can communicate with. As soon as the IP address used to host a web-service runs
multiple web-services (domain-names), this is today done by inspecting the TLS 1.2 server certificate
or SNI. 

Web hosters whose services do share IP addresses across domain name should be very interested to
ensure such inspection works, because else a single misbehaving web-service they host will easily
cause all their web-services to be blacklisted by any of the varied organizations that create 
blacklists: because blacklisting can then only be applied on a per-IP address.

Of course, IPv6 could make this need somewhat obsolete because there should be no reason to
share IPv6 addresses across domain-names, but i am not aware what todays common practice are with IPv6
in this respect.

Cheers
    Toerless

On Thu, Jun 01, 2017 at 04:38:46PM +0200, Benoit Claise wrote:
> Dear all,
> 
> You should be aware that the TLS list is debating encrypting SNI so
> that the host name cannot be seen from TLS sessions.
> https://www.ietf.org/mail-archive/web/tls/current/msg23251.htm
> 
> If you're aware of valid (valid in the IETF-sense) operational
> practices that require the host name visible, we should enter the
> debate.
> 
> Regards, Benoit

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 2 Jun 2017 11:57:30 +0300

> explicitly express support for TLS 1.3.

SNI is always in the clear, certificates are always encrypted.

There was lots of discussion about SNI encryption, but encrypting SNI
turned out to be too nasty.
 
> blacklists: because blacklisting can then only be applied on a per-IP address.

At least GSB can blacklist even at page granularity (I have seen such
blacklisting, in that case due to images being loaded from "shady"
sites.)

-Ilari

---

From: Richard Barnes <[email-masked]>
Date: Fri, 2 Jun 2017 13:16:01 +0300

On Fri, Jun 2, 2017 at 11:43 AM, Toerless Eckert <[email-masked]> wrote:

> their clients can communicate with.

Operators trying to do this by inspecting TLS (and not decrypting) are
going to have a bad time anyway.  With HTTP/2 connection coalescing, even
if they can see the certificate, the actual HTTP request could be for any
name in the certificate.  So there's nothing really gained by exposing the
certificate.

--Richard

> As soon as the IP address used to host a web-service runs
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 2 Jun 2017 12:31:51 +0200

> name in the certificate.  So there's nothing really gained by exposing the

If a web service hoster does not provide any useful demultiplexer then it can of course not
expect not to get blacklisted across services. Is it not already common practice to assign
separate certificates to separate "web customers" ?

--Toerless

-- 
---
[email-masked]

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 2 Jun 2017 08:03:40 -0400

> separate certificates to separate "web customers" ?

No. It's typically the opposite.

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 2 Jun 2017 15:28:33 +0200

> No. It's typically the opposite.

Thanks.

Btw: does TLS 1.3 mandate server side cert encryption or is this something server
apps can decide ? Just because shared web services may not yet leverage the ability to
use certs to authenticate network connections well doesn't mean that that option should not
be given to apps. And it would be sad if one would have to revert to older protocol options
to have that functionality.

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.

Cheers
    Toerless

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 2 Jun 2017 07:16:35 -0700

On Fri, Jun 2, 2017 at 6:28 AM, Toerless Eckert <[email-masked]> wrote:

> > > If a web service hoster does not provide any useful demultiplexer then
> it
> > > can of course not
> apps can decide ?

It mandates it.

> Just because shared web services may not yet leverage the ability to

That functionality is illusory even now, because they are unable to
determine
that the server and the client are not colluding to lie about the server's
identity.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 2 Jun 2017 17:21:36 +0300

> Btw: does TLS 1.3 mandate server side cert encryption or is this something server

It is required.

Of server messages, TLS 1.3 only leaves ServerHello unencrypted. SH
contains low-level connection parameters:

- TLS version used
- Server random value
- Record protection / PRF algorithm used
- DH key share (if DH is used).
- PSK identity selected (if PSK is used).

The certificate is sent in certificate message, which is always
protected (encrypted).

-Ilari

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 4 Jun 2017 15:25:46 -0500

> relevant level of auditing if the auditing relevant class of information was visible via

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

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 7 Jun 2017 02:36:38 +0200

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

---

From: Dave Garrett <[email-masked]>
Date: Tue, 6 Jun 2017 21:59:16 -0400

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

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 7 Jun 2017 04:53:32 +0200

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

-- 
---
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 7 Jun 2017 05:14:46 +0200

> Why can i negotiate a cipher suite without encryption but not disable cert

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

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