> The server ought to perform a full handshake whenever the full handshake will > result in selection & use of a _different_ TLS server certificate than what > was used for the original full handshake on a session resumption. I think this is correct, assuming a server is only able to present one cert in a TLS session (which is currently the case).
However, this does not mean that the SNI at resumption time has to match the SNI at session establishment time, because the same server cert can match multiple SNIs. Also, there appears to be interest in allowing the client to request server auth post-handshake. If this gets supported, a server may prove multiple identities to a client within the same TLS session. And then perhaps the client should be able to resume the session with an SNI that matches any of the identities the server has proved in this session. Cheers, Andrei -----Original Message----- From: Martin Rex [mailto:[email protected]] Sent: Friday, October 21, 2016 6:52 AM To: Andrei Popov <[email protected]> Cc: Eric Rescorla <[email protected]>; [email protected] Subject: Re: [TLS] SNI and Resumption/0-RTT Andrei Popov 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? The current wording in rfc6066 may be slightly confusing about what is acutally important and why. The server ought to perform a full handshake whenever the full handshake will result in selection & use of a _different_ TLS server certificate than what was used for the original full handshake on a session resumption. This is a direct consequence of the principle of least surprise. This is also the most backwards-compatible behaviour when upgrading the server from a does-not-support-SNI to a supports-SNI state/implementation. You do *NOT* want to have session caching interfere with the server certificate that a client gets to see, because that would essentially result in not-quite-deterministic server behaviour. Sometimes there may be bugs in client-side session caching, and clients proposing the wrong session for resumption, and the server doing a full handshake results in interoperable, deterministic and secure behaviour. -Martin _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
