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<mailto: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<mailto:tls-boun...@ietf.org>] On Behalf Of Eric Rescorla Sent: Thursday, October 20, 2016 5:34 PM To: tls@ietf.org<mailto: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
