On Tue, Jul 2, 2013 at 1:52 PM, Ben Laurie <b...@links.org> wrote: > On 2 July 2013 16:07, Adam Back <a...@cypherspace.org> wrote: > > On Tue, Jul 02, 2013 at 11:48:02AM +0100, Ben Laurie wrote: > >> > >> On 2 July 2013 11:25, Adam Back <a...@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). Trevor
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
