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

[Brian Smith <[e-mail]>]

David Benjamin <[e-mail]> wrote:
> I agree #3 is the most natural. The behavior for a server is then:
> 1. Based on client_version, select a protocol version.
> 2. Look up session based on session_id or ticket.
> 3. If the version the session was established at does not match the
> negotiated version, pretend the lookup failed.
> 4. Do a full or abbreviated handshake based on whether other properties of
> the session check out (cipher suite still allowed, etc.).

<snip>

> Otherwise, #1 probably works too, though OpenSSL doesn't store the
> client_version. I think I mostly see that as the client's responsibility;
> session resumption skips negotiation of lots of parameters, so you already
> have to be aware of handling this when your half of preferences change.

Agreed.

> A server SHOULD flush its session cache and invalidate tickets when
> changing cipher preferences

I think implementing your step #4 above is better than relying on such
flushing, because in a setup where multiple servers are sharing a
session cache, the flushing would likely be racy, and/or the
individual servers may be configured differently--either temporarily
as a setting change propagates across a set of servers, or permanently
due to some (mis)configuration issue.

> a client SHOULD shard the session cache by fallback
> type, etc.

Alternatively, the client should avoid doing any fallback at all. If
it has to do fallback for some reason, it could also avoid the issue
by avoiding session resumption during fallback.

Cheers,
Brian