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

[Jacob Appelbaum <[e-mail]>]

On 9/21/15, Daniel Kahn Gillmor <[e-mail]> wrote:
> On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni <[e-mail]>
> wrote:
>> So the client would now need to cache some session data by transport
>> address, and other data by name and port.  That's rather complex.
>
> This is already done by HTTP/2 clients, since they can access multiple
> servers at the same address:port combination.
>
>> And how often will the same client visit multiple servers at the
>> same transport address?
>
> *.github.io, *.blogspot.com, massive CDNs, etc.  It's a common pattern.
>
>> I don't really see this as viable or worth the effort.
>
> I disagree -- the metadata leaked to a passive attacker by mandatory SNI
> is a valuable signal.  It is worth trying to protect it.

I agree - this metadata is usable as a selector for automated
surveillance and for automated exploitation.

>
>> I don't think SNI hiding is viable without encryption at the
>> transport or network layers.
>
> any encrypted SNI is effectively acting as a shim for transport
> encryption, yes.  Then again, TLS is itself "transport layer security",
> so we should try to provide it at least as an option.

In an ideal world: using ephemeral keys, we must be able to have usage
of the protocol that is selector free.

>
>> And there's still a metadata leak via DNS which may prove difficult to
>> address.
>
> The DNS community is working to address the DNS leak in DPRIVE.  The TLS
> community should be working to fix its own part of the metadata leak.
>

Agreed, strongly.

All the best,
Jacob