Re: [TLS] Fate of resumption

On Tue, Oct 21, 2014 at 7:26 AM, Alex Elsayed <eternaleye@gmail.com> wrote:

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

How would erasing the session interact with RFC 5077 tickets?

-Ekr

> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>