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
