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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
