Re: [TLS] SNI and Resumption/0-RTT

[Christian Huitema <[e-mail]>]

I mentioned obfuscation as one possible solution. I know that I can make it work for small scale servers, e.g., up to a few hundreds registered clients. But if we can achieve the same privacy results with some mechanisms using dynamic certificates, that's fine too. My only point is, please don't forbid future privacy enhancement with a hard rule on SNI. Maybe something like "should use the same SNI, but may use different ones if client and server agree on an SNI privacy scheme."

-- Christian Huitema 

> On Oct 21, 2016, at 8:14 AM, Ilari Liusvaara <[e-mail]> wrote:
> 
>> On Fri, Oct 21, 2016 at 07:58:57AM -0700, Christian Huitema wrote:
>> I am a bit worried about privacy implications of the SNI. Suppose
>> that we invent an obfuscation mechanism that prevents third parties
>> to track which service corresponds to an SNI string. The SNI would
>> then be different for any connection, including resumptions. Do we
>> want to prevent that with a hard rule in the spec?
> 
> Such mechanism on TLS level would be pretty hard to do. You can't do
> any sort of static encryption or obfustication for instance (because
> that would be trivially attackable).
> 
> 
> Much more feasible to have application layer (with possibly TLS protocol
> support) way of sending new server certificates in the fly (post-
> handshake auth, but with servers).
> 
> (It seems to me that due to the roles of HTTP clients and servers, post-
> handshake server auth is a lot less scary than post-handshake client
> auth).
> 
> 
> -Ilari