[cryptography] SSL session resumption defective (Re: What project would you finance? [WAS: Potential funding for crypto-related projects])

Ben Laurie ben at links.org
Tue Jul 2 16:52:56 EDT 2013

On 2 July 2013 16:07, Adam Back <adam at cypherspace.org> wrote:
> On Tue, Jul 02, 2013 at 11:48:02AM +0100, Ben Laurie wrote:
>> On 2 July 2013 11:25, Adam Back <adam at cypherspace.org> wrote:
>>> does it provide forward secrecy (via k' = H(k)?).
>> Resumed [SSL] sessions do not give forward secrecy. Sessions should be
>> expired regularly, therefore.
> That seems like an SSL protocol bug no?  With the existence of forward
> secret ciphersuites, the session resumption cache mechanism itself MUST
> exhibit forward secrecy.

Well. I've been thinking about this on and off all day, and it seems
to me it has difficulties.

Let's say we move to your world and I'm a scalable provider of TLS.

To present a pessimistic view: when a session is resumed, I have to
find that session in my session database, extract k, replace it with
H(k), propagate that to all the replicas of the session database, and
carry on with the client. From my POV, that propagation cost way more
than just dropping the session and starting again would - sessions are
only profitable if they are write-once read-many. So why would I ever
cache sessions?

So, now, every new connection is a new asymmetric handshake instead of
a session resume. Consequence? I am motived to reduce my TLS traffic.

Alternatively, we stay in this world, clients expire sessions hourly,
and we're all happy.

> Do you think anyone would be interested in fixing that?
> Adam

More information about the cryptography mailing list