Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

[Dave Garrett <[e-mail]>]

I've been effectively convinced that encrypted SNI can only provide mild protection in some specific instances, and usually only provides a false sense of security. That said, if someone does want to design a system, I can think of a relatively easy route forward here. The TLS 1.3 spec will be introducing Server Configuration Extensions (different from Hello extensions). Encrypted SNI could be implemented by creating a config extension to provide a second semi-static key to be used for SNI encryption. This would require server configurations be distributed through some out-of-band route, but this will probably already be desired and is not really avoidable if you want to encrypt something in the first-flight, like SNI. Without this, at least repeat connections could have SNI encrypted. This ESNI key would be shared across virtual servers and be issued by the host. The same server_name hello extension would be used, but it'd just be encrypted for hosts that support it.

The even simpler route is to just put the SNI extension in EncryptedExtensions when possible, but that requires sharing one 0RTT key across all virtual servers on the host. There's probably plenty of situations where this is fine, but I think it'd be better to just generalize things to have a second key and avoid problems here, at this point.


Dave