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

On Tue, Sep 22, 2015 at 1:39 PM, Jacob Appelbaum <jacob@appelbaum.net> wrote:
> On 9/21/15, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
>> On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni <ietf-dane@dukhovni.org>
>> 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 agree with Jake and DKG wholeheartedly.

I'd add that in addition to surveillance and exploitation, cleartext
SNI will be useful for censors at various scales... the same property
that it's useful for (distinguishing which domain at an endpoint a TLS
conversation is for), can be used to impair or drop flows.

I realize there is a small minority of people that participate in TLS
WG that feel very strongly about designing a way to have encrypted
SNI, but I'd really hope that we can find a way to do it, and that
it's not considered too massive of an effort.

The uses in which we would want to harden TLS connections against
surveillance, exploitation, and censorship will seem to only grow, and
having it baked into the infrastructure (and done well) will mean we
will have much more deployed ability to resist these kinds of network
attacks.

>>
>>> 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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
joe@cdt.org
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871