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

Thierry Moreau thierry.moreau at connotech.com
Thu Jul 4 12:37:40 EDT 2013

Adam Back wrote:

> Forward secrecy is exceedingly important security property.  Without it an
> attacker can store encrypted messages via passive eavesdropping, or court
> order an any infrastructure that records messages (advertised or covert) 
> and
> then obtain the private key via burglary, subpoena, coercion or
> software/hardware compromise.

With an exceedingly narrow field of application: those client systems 
that a) delete secret information (application and keys) in a 
forensic-resistant way, and b) delete the application information 
systematically to render ineffective any later burglary, subpoena, 
coercion, or software/hardware compromise. Under these circumstances, 
chances are that the selected crypto mechanism would indeed already 
embed DH.

> The fact that the user couldnt decrypt the traffic even if he wanted to as
> he automatically no longer has the keys, is extremely valuable to the
> overall security for casual, high assurance and after-the-fact security 
> (aka
> subpoena).
> In my view all non-forward-secret ciphersuits should be deprecated.
> (The argument that other parts of the system are poorly secured, is not an
> excuse; and anyway their failure modes are quite distinct).

In my opinion, when you consider the casual user needs, I see those 
arguments not at a top priority.

> Btw DH is not the only way to get forward secrecy; ephemeral (512-bit) RSA
> keys were used as part of the now-defunct export ciphers, and the less well
> known fact that you can extend forward secrecy using symmetric key one way
> functions hash function k' = H(k), delete k.

Not completely by this counterexample: generate k, suffer from an enemy 
copy of system state including k, let k'=H(k), delete k', use k' in 
dangerous confidence. I mean the textbook PFS definition is not 
satisfied by k'=H(k).

> DH also provides forward security (bacward secrecy?) its all a misnomer but
> basically recovery of security, if decryption keys are compromised, but the
> random number generator is still secure.  (And auth keys presumably.)
> The fact that forward secrecy is secure against passive adversaries even
> with posession of authenticating signature keys, also ups the level of
> attack required to obtaining plaintext.  A MITM is something harder to
> achieve at large scale, and without detection, in the face of compromised
> CAs and so on.  So that is another extremely valuable functionality 
> provided
> by DH.
> Dont knock DH - it provides multiple significant security advantages over
> long-live keys.  All comms that is not necessarily store and forward should
> be using it.

Indeed having a DH component in a session key establishment is the way 
to go. I am with you that the DH forcing a MITM arrangement is a useful 
line of defense.

I question the marginal benefit of upgrading from a deployed base where 
DH was omitted at the outset, under the PFS argument alone.


- Thierry

> Adam
> On Thu, Jul 04, 2013 at 11:16:21AM -0400, Thierry Moreau wrote:
>> Thanks to Nico for bringing the focus on DH as the central ingredient 
>> of PFS.
>> Nico Williams wrote:
>>> But first we'd have to get users to use cipher suites with PFS.  We're
>>> not really there.
>> Why?
>> Perfect forward secrecy (PFS) is an abstract security property defined 
>> because Diffie-Hellman (DH) -- whatever flavor of it -- provides it.
>> As a reminder, PFS prevents an adversary who gets a copy of a victim's 
>> system state at time T (long term private keys), then *only* 
>> eavesdrops the victim's system protocol exchanges at any time T' that 
>> is past a session key renegotiation (hint: the DH exchange part of the 
>> renegotiation bars the passive eavesdropper).
>> It's nice for us cryptographers to provide such protection. But its 
>> incremental security appears marginal.
>> So, is it really *needed* by the users given the state of client 
>> system insecurity?
>> I would rather get users to raise their awareness and self-defense 
>> against client system insecurity (seldom a cryptographer achievement).
>> -- 
>> - Thierry Moreau

More information about the cryptography mailing list