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

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?

-- Christian Huitema 

> On Oct 21, 2016, at 7:42 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> 
>> On Fri, Oct 21, 2016 at 12:38:29PM +1100, Martin Thomson wrote:
>> So I think that the problem could be reduced in complexity.  A little
>> at least.  The obvious consequence of changing SNI is that you end up
>> somewhere different than last time.  But we can still ensure that the
>> connection is to the same peer.
> 
> You _might_ end up somewhere different. And even with the same SNI, you
> can still end up to different server in the same "group". And different
> SNI names can still get you to the same actual place.
> 
>> If the server remembered which certificate it used, and insisted that
>> THAT remain constant, then you could take a different SNI from - for
>> example - a subjectAltName.  Provided that the routing works out, you
>> might still get the same certificate.
>> 
>> I mean, the point of SNI is to route to the right configuration.
>> Changing name messes with resumption in that you want to make sure
>> that you end up in a place that has the resumption secret.  But if you
>> end up at the wrong server, you either fail to resume, or fail to
>> connect on the normal terms of the protocol.
> 
> There are three tasks of SNI:
> 
> - Routing to the correct server. Sometimes this routing is performed by
>  middleboxes (yay, middleboxes!).
> - The certificate selection within the server.
> - Set application instance, if the protocol can't do this in-band (but
>  if it does, applications generally override this with in-band value).
> 
> And I would expect the servers to actually look at the PSKs offered and
> not blindly trying to use one, so if connection is routed wrong, I would
> expect fallback to the usual DH-CERT handshake.
> 
>> The only thing that could screw this all up is if we end up in a
>> situation where one or other peer is confused about either its own
>> identity, the identity of its peer, or the identity (-ies) that it
>> believes it peer has for itself.  However, with certificate stability
>> rather than name stability I don't think we are worse off than with -
>> say - a wildcard cert.
> 
> I would expect such confusion about own identity to be pretty much the
> norm for HTTP servers. And those are frequently used in ways that tend
> to amplify even a small errors to serious attacks.
> 
> For other types of servers, I would expect any confusion resulting in
> security problems to be pretty rare.
> 
> But since HTTP is very important usecase, this impiles that the client
> shouldn't attempt to use PSKs when such confusion could create security
> issues.
> 
>> I agree that the add-a-name stuff makes this harder.  A co-tenanted
>> server with resumption keys across a bunch of names risks confusing
>> itself if it allows resumption across certificates, depending on how
>> much state it carries from the old session.  In doing add-a-name, then
>> we need to be careful about that, but that's a problem for those of us
>> who want to do add-a-name.
> 
> You can already get such confusion with wildcard certificates, no
> changes needed.. 
> 
> 
> -Ilari
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls