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

[Ilari Liusvaara <[e-mail]>]

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