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

Trevor Perrin trevp at trevp.net
Wed Jul 3 03:28:37 EDT 2013

On Tue, Jul 2, 2013 at 1:52 PM, Ben Laurie <ben at links.org> wrote:

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

If you don't want compromise of a client or server session cache to
compromise old traffic, you'd be better off doing H(k) *before* cacheing
the secret.

TLS assumes each session_id corresponds to a fixed master secret, and on a
resumed connection, the server echos the session_id to signal acceptance of
the resumption.  So for a "forward-secure" resumption you'd need to get
both parties to agree and get a new session_id, somehow.

You could imagine a TLS extension sent by the client to signal support for
"resumption forward secrecy".  If the server echos it, the client caches a
"forward-secure" session.  Something like:

new_session_id = session_id + 1
new_master_secret = SHA256(master_secret)

Not sure this is worth hacking into TLS.  But it's worth considering in new
protocols (e.g. I think QUIC is considering it).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20130703/b49f2090/attachment-0001.html>

More information about the cryptography mailing list