[TLS] Fate of resumption

[Eric Rescorla <[e-mail]>]

Folks,

I wanted to get the discussion going on whether we need resumption [0] or
not
for TLS 1.3. This may be a quick discussion as I suspect the answer is
yes, but I figure we should decide it rather than just assuming it.


The argument for resumption seems pretty straightforward: it requires
significantly less computation (in the form of asymmetric operations)
than a full handshake. I suspect that this argument is less powerful
than it used to be for two reasons:

- Increased computational power.
- Faster algorithms in the form of ECC.

Nevertheless, we still have constrained devices, both in the form of
low-power phones and IOT-type devices. OTOH, it's not clear to me
how many of those devices actually (a) do public key cryptography
as opposed to PSK and (b) do session resumption.


Conversely, resumption adds complexity to the protocol both since you
have to implement both the full and resumed state machines and because
the client has uncertainty about whether a server will accept
resumption.

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

I'm hoping to get people's opinions on this (and we can discuss more
next week). How important is resumption to you as a performance
optimization? Is it still important when you can do all-ECC (which
it seems likely we will require clients to do for TLS 1.3).

-Ekr


[0] For purposes of this discussion I'm using "resumption" to mean
both ordinary resumption [RFC 5246; Figure 2] and session tickets
[RFC 5077]. I tend to agree with the comments from others that if
we retain resumption we should unify these mechanisms, but that
seems like a question to be answered after we have decided
whether to retain resumption at all.

[1] Technical note: with RFC 5077 tickets the server retains the
ticket master key (TMK) in its memory, but since the attacker is
assumed to have the ticket, an attacker who successfully attacks the
server and recovers the TMK key can recover the MS. It's true that you
could store the TMK in secure storage, but you could also implement a
session cache where the entries are encrypted under some kind of
master key which is in secure storage, so I would argue that the
security properties vis-a-vis PFS are similar.

[2] For clarity, what I mean here is:

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