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