Re: [TLS] Multiple Session Caches and SNI

[Michael D'Errico <mike-list at pobox.com>]

> In addition to cache management aspects, the TLS server should keep
> robustness in mind.  e.g. robustness against TLS clients with
> a broken client-side TLS session cache management that will
> recklessly propose a TLS session resume for a session (ID) originally
> established with Mars to just about every earthling they're asked
> to connect to later on.

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.

> And before a TLS server checks for existence of a TLS session,
> whose session ID is proposed in a ClientHello, it should determine
> wheter it would be willing to establish a new session through
> a full handshake based on the other information in the ClientHello
> and under what conditions it would do so.

I do it the other way around -- after retrieving the session, checks
are made to make sure the cipher suite and compression algorithm are
listed in the ClientHello.  This is mandatory according to section
7.4.1.2.  The only other check I currently have is for the age of the
session to make sure it is fresh enough.

> 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.

Mike



> This is a simple and straightforward robustness principle leading
> to consistent behaviour, that will save implementors and consumers
> of the technology a lot of time and headaches.
>
>
> -Martin