Re: [TLS] Interaction between session resumption and negotiated protocol version

[Brian Smith <[e-mail]>]

Fabrice Gautier <[e-mail]> wrote:
> Given that, it seems that it's acceptable for a server to attempt to
> resume a session with TLS 1.2 that was originally established with TLS
> 1.0, or vice-versa.

Perhaps one could construct a logical argument for that. However, is
it really worth the complication for the server to try to resume a
session that was established at a different version than it would
otherwise create a new session? I doubt any potential benefit would
outweigh the likely harm of doing so.

> That seems wrong, but I also guess this is a very plausible scenario
> given that many implementation do version fallback if something goes
> wrong.

Two wrongs don't make a right.

> (3) Cache the old ServerHello.version and do not resume unless the
> cached version is the max of ClientHello.version and max supported
> Server version. (e.g.: Do full handshake at best version instead of
> downgrading to a lower cached version)

<snip>

> My guts tell me that (3) is the right thing to do.

Yes!

Here's another way of thinking about it: Given
ClientHello.client_version and the max version the server supports,
calculate ServerHello.server_version. Then, look in the session cache
for an entry that has the *exact same* ServerHello.server_version. If
you find one, resume that session. Otherwise, do a full handshake.

If you want to be really careful, also calculate cipher_suite before
resuming, and only resume a session that has the same cipher_suite.

Cheers,
Brian