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 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
