Re: [TLS] Fate of resumption

[Alex Elsayed <[e-mail]>]

Eric Rescorla wrote:

<snip>

> Another problem with resumption is that it is a threat to PFS.  In the
> current TLS resumption design, if a session is resumable, then both
> the client and the server retain the MS in their session caches [1].
> Thus, even if you use a PFS cipher suite and destroy the traffic keys
> and the asymmetric keys after the connection is over, an attacker who
> attacks the session cache can decrypt your connection. As noted in my
> previous message, it's not too difficult to separate the MS stored in
> the session cache from the MS used for the initial connection that
> initiated the session, but it's much harder to do so between multiple
> resumptions of the same session, though perhaps we could do figure out
> how to do so [2].

<snip>

> 
>     Connection 1 does a full asymmetric exchange and establishes
>     session X with MS key M, storing M in the session cache and
>     using M to generate its keys.
> 
>     Connection 2 resumes session X and uses M to generate its keys.
> 
>     Connection 3 resumes session X and uses M to generate its keys.
> 
> It's fairly straightforward to have connection 1 generate two keys,
> M and M' from its PMS, use M to generate its keys and store M'
> in the session cache. But this still leaves both connection 2 and
> 3 sharing M'.

One thing I wonder - do we need to support multiple resumption of the same 
state, or do we simply need to allow a session to die and revive?

The difference is that, in the latter case, we may be able to just evolve 
the MS using some variety of one-way function between each reincarnation of 
a session:

     Connection 1 does a full asymmetric exchange and establishes
     session X with MS key M, storing M' in the session cache and
     using M to generate its keys.

     Connection 2 resumes session X as session X' and uses M' to
     generate its keys, storing M'' in the session cache.
     M' is erased.

     Connection 3 resumes session X' as session X'' and uses M''
     to generate its keys, storing M''' in the session cache.
     M'' is erased.

And so forth.