Re: [TLS] Fate of resumption

On Mon, Oct 20, 2014 at 10:41 PM, Viktor Dukhovni
<ietf-dane@dukhovni.org> 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.

Furthermore, resumption has always been optional. TLS 1.2 states that
a client does not know if a server will permit resumption. Likewise, a
server doesn't know if a client supports resumption. That said, adding
mutability to something that wasn't mutable is a major change in
multithreaded code, and should be avoided.

Sincerely,
Watson Ladd
>
> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin