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.
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. 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 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. On 21 October 2016 at 12:06, Eric Rescorla <e...@rtfm.com> wrote: > Yeah, it does seem a bit complicated.... :) > > -Ekr > > > On Thu, Oct 20, 2016 at 6:00 PM, Andrei Popov <andrei.po...@microsoft.com> > wrote: >> >> Perhaps it’s OK to resume a session with a different SNI if in this >> session the server has proved an identity that matches the new SNI. >> >> In order to enforce this, the server would have to cache (or save in the >> ticket) a list of identities it presented in each resumable session… >> >> >> >> From: Eric Rescorla [mailto:e...@rtfm.com] >> Sent: Thursday, October 20, 2016 5:47 PM >> To: Andrei Popov <andrei.po...@microsoft.com> >> Cc: tls@ietf.org >> Subject: Re: [TLS] SNI and Resumption/0-RTT >> >> >> >> >> >> >> >> On Thu, Oct 20, 2016 at 5:43 PM, Andrei Popov <andrei.po...@microsoft.com> >> wrote: >> >> Ø With that said, it does seem like there might be situations where it >> >> Ø would be useful to allow resumption/0-RTT with different SNIs. >> >> What are some example situations where resumption with a different SNI is >> useful >> >> >> >> A system where you have a bunch of co-tenanted names and you'd like to get >> 0-RTT on >> >> SNI A after negotiating with SNI B. Basically the same conceptual >> situation as Mike Bishops >> >> add-a-server-cert draft. >> >> >> >> With that said, I'm more than happy to stuff this in the "TODO-for-later" >> list. >> >> >> >> -Ekr >> >> >> >> >> >> Thanks, >> >> >> >> Andrei >> >> >> >> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla >> Sent: Thursday, October 20, 2016 5:34 PM >> To: tls@ietf.org >> Subject: [TLS] SNI and Resumption/0-RTT >> >> >> >> We used to explicitly say that you had to check SNI for 0-RTT (but >> >> didn't say anything about resumption). On the principle that 0-RTT and >> >> resumption should be the same I removed that, but it turns out that >> >> the document doesn't actually have any rule at all other than the one >> >> we've inherited from RFC 6066, which clearly says that you can't >> >> resume with a different SNI [0]. >> >> >> >> Following the discussion in >> >> https://github.com/tlswg/tls13-spec/issues/720 I've added a statement >> >> to the draft clarifying that the RFC 6066 rule still applies [1] >> >> >> >> With that said, it does seem like there might be situations where it >> >> would be useful to allow resumption/0-RTT with different SNIs. My >> >> intuition (partly informed by [2]) is that this is something we should >> >> be pretty careful about and have the server opt-in explicitly (if at >> >> all) but I'm willing to be wrong about that. >> >> >> >> Comments? >> >> -Ekr >> >> >> >> >> >> [0] https://tools.ietf.org/rfcmarkup?doc=6066#section-3 >> >> [1] >> https://github.com/tlswg/tls13-spec/commit/b26093b5e9143fb61f5b619d1da78c4ba54b2121 >> >> [2] http://antoine.delignat-lavaud.fr/doc/www15.pdf >> >> >> >> > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
