Re: [TLS] Proposed text for removing renegotiation

[Andy Lutomirski <[e-mail]>]

On 05/28/2014 10:02 AM, Martin Thomson wrote:
> On 27 May 2014 17:44, 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's a good point.  Something that I missed.  A resumption handshake
> would have to include an epoch from the previous session.  That number
> would need to be incremented with each update of the master secret.

Rather than mucking with the master secret, can't we rearrange the key
hierarchy a bit:

Separately derive master_secret and temporary_secret from
premaster_secret.  Use master_secret as it's currently used for
resumption, but use temporary_secret for encryption and MAC.  When it's
time to rekey, roll over the temporary_secret but leave the
master_secret alone.

Getting resumption right might be a little tricky here: unless a new DH
exchange happens on resumption, the new temporary_secret will have to be
derived from master_secret.

This gets another benefit for free: a compromise of the session cache or
the ticket key doesn't compromise old non-resumed connections.


--Andy