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

[Dave Garrett <[e-mail]>]

On Friday, August 28, 2015 11:08:35 am Salz, Rich wrote:
> Having discussions through github is a really bad idea.

You're right. I posted a stupidly long side-note in there. I intended to bring it to the list too, which I'll do now.

On Friday, August 28, 2015 10:49:33 am Viktor Dukhovni wrote:
> It seems that with TLS 1.3 the client MUST send SNI, presumably in
> the clear.  Typically there's not much else of interest in the
> server certificate to hide.  I don't see a realistic way to hide
> the server identity even from passive wiretap via TLS.

Currently, we're at implementations MUST support (not necessarily send) SNI, servers MAY require it, and servers SHOULD error on such a failed requirement. This doesn't change the status quo much. If servers don't require it, you don't need to send it. HTTP/2 has its own SNI requirement, though, so lots of TLS will be moving in that direction.

The idea I had the other day is that we can technically do SNI encryption with the current TLS 1.3 draft, as-is. All that needs to really be done is stick it in a 0-RTT EncryptedExtensions, preferably only when the server specifies that it is allowed via adding a flag to server config. This would require the actual server share the 0-RTT DH key across the virtual servers it's picking via SNI, so early data probably should be off in this instance for many use-cases.

The simplest route that would allow for encrypted SNI with 0-RTT application data allowed would be to just add a second long-term DH key to the server config for SNI (and an option for servers to have one do both if they don't need two). Seeing as this would still need to be opt-in via a flag in the config, we could use the same extension ID and just encrypt it using the second key. Servers that provide an SNI key get encrypted; others get clear or none.

If we can also get a way to distribute server config out-of-band, this would even allow initial-connection SNI encryption.

I don't think encrypted SNI to servers without any prior information is really that viable, and that's been said before by others on this list. Now, with that said, you could just create a way for any client to ask a server for its config without any attempt to connect right away, in which case it can follow up with encrypted SNI at the cost of that 1-RTT (e.g. the QUIC way of doing things). Even if we allow ServerConfiguration to be optional normally, we could add this config request mode and make support for that mandatory (though, potentially with short-lived keys). This route would still require some prior information about this server: knowledge that it could request a key for SNI at all without just getting rejected. Doing so without that would require a multiple attempt check of some kind that's probably a bad idea.


Dave