[cryptography] SSL session resumption defective (Re: What project would you finance? [WAS: Potential funding for crypto-related projects])
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
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
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...
More information about the cryptography