Re: [TLS] Tonight's Encrypted SNI Hangout Session

[Ilari Liusvaara <[e-mail]>]

On Mon, Nov 13, 2017 at 09:28:23PM +0800, Bret Jordan wrote:
> 
> 3) We need to compile a list of use cases and scenarios in a draft document
> that talk about how the SNI (for good or for bad) is being used today and
> what an encrypted SNI will mean for these use cases.

What I think SNI is mainly (legimately) used for:

- Specify the certificate.
- Specify the next service (both before and after TLS termination).

Ideally, specifying certificate would be enough to specify the next
service. But we all know reality is not ideal, so it might not be.
In the converse direction, having multiple certificates all covering
the same next service is very common (e.g., it would requre special
setup with common webservers not to have it this way).

As to specifying certificate, there are many reasons why a server
might want multiple certificates:

- There are too many names to put into one certificate.
- Putting all the names into one certificate would be difficult to
  manage.
- The server wants to make some separation between the names.
- The names have different next service.


One can note that both uses are really just to save IP address space.
There are two main reasons why one would want to do that:

- Conserving address space (IPv4!!!).
- Avoiding adminstrative overhead of multiple IP addresses.


Easier way to partially solve this would be to reduce the granularity
of data. Does not work with all servers.


The more difficult way would be to actually encrypt the SNI value
(bound to the client public key to avoid a nasty attack that breaks
the entiere scheme). This would make SNI before-termination routing
more difficult, and absent something nontrivial, would increase the
server handshake cost by over a half.


However, much of the "encrypted SNI" discusion has been about different
thing, namely proxying. Which is whole another can of worms, and is
also a three-party protocol, not two-party.




-Ilari