Re: [TLS] Fate of resumption

[Eric Rescorla <[e-mail]>]

On Tue, Oct 21, 2014 at 8:05 AM, Watson Ladd <[e-mail]> wrote:

> On Mon, Oct 20, 2014 at 10:41 PM, Viktor Dukhovni
> <[e-mail]> wrote:
> > On Mon, Oct 20, 2014 at 10:26:33PM -0700, Alex Elsayed wrote:
> >
> >> > 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?
> >
> > In terms of existing practice Postfix resumes cached sessions
> > independently in parallel.  When a cached a resumed session completes,
> > no new session replaces the original cache entry.  The code assumes
> > that session resumption is non-destructive, and cached state can
> > be re-used multiple times.  I imagine similar behaviour patterns
> > apply to browsers, and other applications.
> >
> > If TLS 1.3 changes session re-use semantics, it will be substantially
> > more difficult to deploy (changes will impact not just SSL library,
> > but also application code).
>
> In a little over an hour a meeting on this topic will be starting, so
> let me put in my two cents. There is no reason a resumed session needs
> to use the same keys as the record layer of the session that was
> resumed. (Actually, there is, namely 0-RTT, but lets forget that for
> the time being/solve it some other way). In particular having a
> connection generate a resumption key, and deriving from the resumption
> key new, distinct, keys for each direction of the new communication
> solves the PFS problem, while still enabling multiple resumption.
>

It solves the PFS problem between the connection that established
the session and the next session. However, as long as the keys
for resumed connection 1 and connection 2 are derived from the
same keying material, then you have a PFS problem between
connections #1 and #2.

-Ekr