Subject: [TLS] Fate of resumption

From: Eric Rescorla <[email-masked]>
Date: Sat, 18 Oct 2014 17:16:27 +0100

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

---

From: Yoav Nir <[email-masked]>
Date: Sat, 18 Oct 2014 19:54:48 +0300

> - Faster algorithms in the form of ECC.

There’s one other thing, that is relevant for HTTPS, which is the biggest use case for TLS. The trend in recent years is that the TCP connections (and thus, TLS sessions) last for far longer than they used to.

This trend started with HTTP/1.1, but it’s now common for TLS sessions to last for many minutes as long as the browser window remains open.Since the original session lasts and lasts, there is less use for resumption. 

The latest figures I’ve heard were of 50% of sessions being resumed, which is still a lot, but far less than it used to be 10 years ago, when both browsers and servers typically closed TCP connections after several seconds of inactivity. Still, assuming PK operations account for a large chunk of a server’s CPU cycles (and it is so in some common benchmark tests), eliminating resumption can reduce a server’s session rate by up to 50%.

With HTTP/2 poised to get deployed on much of the Internet, that 50% figure (that I suspect is driven by browsers opening several simultaneous connections before a session cache entry is available) is likely to be reduced further.

Yoav

---

From: Erik Nygren <[email-masked]>
Date: Sun, 19 Oct 2014 11:43:58 -0400

> yes, but I figure we should decide it rather than just assuming it.

+1 for leaving in resumption for TLS 1.3, for the reasons mentioned.

Resumption is another part of the "istlsfastyet" story that helps in selling
people on making TLS more ubiquitous, both from a performance
and cost perspective.  Dropping it at this point might harm adoption
of both TLS 1.3 as well as momentum towards TLS in general.

(Some of the other discussions on this topic focused on best
practices around session ticket key management.  If resumption
is going to stick around, then ideally there should be a BCP or similar
on sane implementation practices that do as little harm to forward secrecy
as possible.)

One other thing we may wish to consider is the relative safety
and complexity and interactions of 0RTT vs Resumption for various scenarios,
such as against replay attacks (when nonces are available and
when they aren't available).

       Erik

---

From: Joseph Salowey <[email-masked]>
Date: Sun, 19 Oct 2014 10:07:13 -0700

+1

For the reasons Peter mentioned.  There are cases where the TLS handshake
is used as an authentication mechanism such as EAP-TLS and other TLS based
EAP mechanisms.  Many deployments rely heavily on session resumption (and
session tickets).  There are also many IoT type devices that support public
key based mechanisms and would benefit from session resumption.

Joe

On Sun, Oct 19, 2014 at 8:43 AM, Erik Nygren <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Tom Ritter <[email-masked]>
Date: Sun, 19 Oct 2014 19:00:27 -0400

> when they aren't available).

++ I'm confident a Resumption-like thing will need to be present, but
I'm not clear on the difference between 0RTT and Resumption, and if we
need the latter if we have the former. (Whatever it's called.)

-tom

---

From: Alex Elsayed <[email-masked]>
Date: Mon, 20 Oct 2014 22:26:33 -0700

Eric Rescorla wrote:

<snip>

> resumptions of the same session, though perhaps we could do figure out

<snip>

> in the session cache. But this still leaves both connection 2 and

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.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 21 Oct 2014 05:41:19 +0000

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

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Oct 2014 07:41:52 +0200

>      to generate its keys, storing M''' in the session cache.

How would erasing the session interact with RFC 5077 tickets?

-Ekr

---

From: Watson Ladd <[email-masked]>
Date: Mon, 20 Oct 2014 23:05:22 -0700

> 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

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Oct 2014 09:04:54 +0200

> 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