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
