Re: [TLS] Proposed text for removing renegotiation

[[e-mail] (Martin Rex)]

Brian Smith wrote:
> Martin Rex <[e-mail]> wrote:
>>
>> Conceptually, the TLS session cache is readonly after an entry
>> is created, and that is GOOD, i.e. full TLS handshakes create new,
>> distict session cache entries, and abbreviated TLS handshakes resume
>> existing session cache entries and *NEVER* modify them.
> 
> That is not true. During session resumption, the server can send a new
> session ticket for the existing session and the client has the option of
> adding the new ticket to the session (and removing the old ticket).
> 
> Also often timestamps (e.g. for LRU replacement bookkeeping) and/or
> counters (e.g. for cache hit rate statistics) in a session are updated
> during resumption, though these are "just" implementation issues.


With "conceptually", I referred to the requirements of the specification,
not to the details of certain implementations of it.  Counting how often
sessions are resumed is nothing that the spec requires, and how you
manage your cache entries (expiration) is not in scope of that concept.

When the read-only concept is violated, and implementations start scribbling
over _state_ of sessions that are in the cache during resumption
handshakes, it may result in problems such as these:

  CVE-2010-3864     http://www.openssl.org/news/secadv_20101116.txt 
  CVE-2010-4180     http://www.openssl.org/news/secadv_20101202.txt


-Martin