Re: [TLS] Multiple Session Caches and SNI

[Michael D'Errico <[e-mail]>]

>> Section 7.2.2 of RFC 5246 concerning Error Alerts handles this.  If
>> a connection terminates with a fatal alert, the session associated
>> with that connection MUST NOT be resumed.  So perhaps a server will
>> try to resume the session once, but it will delete it from its cache
>> when the handshake fails.  Other servers that don't recognize the
>> session ID will perform full handshakes.
> 
> That appears to strict to me.  I would make the server delete
> a session from his cache when an attempted resume results in a failure.
> I can not currently think of an error (i.e. fatal alert) after a
> mutual successful finished message verification that should cause
> the server to flush the affected ssl session from his session cache.

The main one is a BAD_RECORD_MAC alert if decryption fails, padding
is wrong, the MACs don't match.  The record version could be wrong;
the record could be greater than 2^14 bytes.  None of these things
should happen under normal circumstances, so you have to assume an
attack is underway.

>>> If the TLS server finds a TLS session with the proposed session ID
>>> in his cache, it should then use the results from the previous
>>> determination of the ClientHello parameters whether it is OK to
>>> attempt to resume the cached session, or whether it is advised
>>> to perform a full SSL handshake, because of a significant mismatch
>>> of the newly determine session characteristics from those
>>> of the cachend session identified by the client-proposed Session ID.
>> RFC 4366 states:
>>
>>     -  If, on the other hand, the older session is resumed, then the
>>        server MUST ignore the extensions and send a server hello
>>        containing none of the extension types.  In this case, the
>>        functionality of these extensions negotiated during the original
>>        session initiation is applied to the resumed session.
> 
> Correct, but you should not read it backwards.
> 
> If the server agrees to resume (for whatever reason), the other
> accompanying information in the ClientHello should NOT be used to
> modify that cached session.
> 
> Does rfc-4366 say anywhere that the server _must_not_ involve the
> parameters and extensions present in a ClientHello in his decision
> to resume or not resume a cached SSL session when the client
> includes a session id in the ClientHello handshake message?

Aside from what I quoted, I don't believe so.  The server can decide
not to resume a session for whatever reason it wants.  In fact there
is no requirement to support session caching at all.  What the text
means is that IF the server agrees to resume the session, the resumed
session will have the same features as the original according to the
extensions in the original handshake, regardless of the extensions in
the ClientHello for the resumed session.

Mike