New here. What about a use case (for SNI) of different teams (or budgets) procuring certificates for different sites housed on either the same server, or at least in the same data center behind the same load balancing device? And SNI being used at a gateway, or entry point to that enterprise’s WAN.
Sent from my iPhone > On Nov 13, 2017, at 12:55 PM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > >> 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 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
