[TLS] Interaction between session resumption and negotiated protocol version

[Fabrice Gautier <[e-mail]>]

Hi all,

It's not clear to me what should be the protocol version be selected
when trying to resume sessions.

For the cipher_suite in the ServerHello, the TLS 1.2 RFC explicitly says:

      For resumed sessions, this field is the value from the state of
the session being resumed.

But for the protocol_version it does not say anything specific about
resumption, so, its just:

      This field will contain the lower of that suggested by the
client in the client hello and the highest supported by the server.


I also note that in Section 7, the definition of a Session does NOT
include the protocol version.


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.

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

So what should be the behavior of a server when trying to resume but
there is a version mismatch ?

(1) Cache the old ClientHello.version and  do not resume a session if
the new ClientHello.version does not match the cached one.
(2) Cache the old ServerHello.version and do not resume if the new
ClientHello.version does not allow to negotiate the same
ServeHello.version. Allow resuming at lower version even if both side
support higher version.
(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)
(4) Don't cache any version, always attempt to resume with the max of
ClientHello.version and max supported Server version


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

What do other think ?


Thanks

-- Fabrice