Re: [TLS] SNI and tickets and resumption

[[e-mail] (Martin Rex)]

Salz, Rich <[e-mail]> asked:
>
> Can a client connect with an SNI extension and then later on resume
> or send a ticket with a different SNI value?

AGL responded:
>
> At Google, we share ticket keys between servers, but the servers will
> reject a resumption if any part of the ClientHello causes a different
> certificate to be selected than was presented on the original
> connection.


Salz, Rich wrote:
>
> We do the same thing, but wasn't sure if it was legit. 


The words you're using are sufficiently ambiguous to get me worried.

Since the specification of the TLS extension "server name indication"
is also somewhat wrong (which I only noticed when I implemented it),
I would appreciate to get this clarified.

On a mismatch of SNI in combination of resumption with the original SNI
value (and I include _absent_ SNI on an initial SSLv2 CLIENT-HELLO
in this count!), the server should behave according to the
"Principle of least surprise", and **NOT** reject the connection
(i.e. *NOT* abort with a fatal alert).

If the server doesn't use SNI at all (which includes not supporting
TLS extension SNI), then it should continue to ignore SNI on resumption.


If the server uses SNI on initial full handshakes (those without any
kind of resumption proposed by the client), then the server should
perform a full TLS handshake if SNI differs from what was used for
the session that was proposed for resumption.


-Martin