On Tue, Sep 22, 2015 at 1:39 PM, Jacob Appelbaum <ja...@appelbaum.net> wrote: > On 9/21/15, Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote: >> On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni <ietf-d...@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 j...@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
