Re: [cryptography] SSL session resumption defective (Re: What project would you finance? [WAS: Potential funding for crypto-related projects])
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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] SSL session resumption defective (Re: What project would you finance? [WAS: Potential funding for crypto-related projects])
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. 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). 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. 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. 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] SSL session resumption defective (Re: What project would you finance? [WAS: Potential funding for crypto-related projects])
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. Regards, - 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] SSL session resumption defective (Re: What project would you finance? [WAS: Potential funding for crypto-related projects])
I do not think it is a narrow difference. End point compromise via subpoena, physical seizing, or court mandated disclosure are far different things than pre-emptive storing and later decryption. The scale at which a society will do them, and tolerate doing them given their inherently increased visibility is much curtailed. Trying to do wide scale MITM is much harder, than hoovering ciphertext and then after the fact obtaining keys by whatever method is expedient, legal/extra-legal, secret particularized warrant, secret general warrants, government authorized malware, etc. All of these things are apparently happening on scale larger than authorized by society. Having to physically seize systems, issue individualized subpoenas to a generally public court process based on articulated suspicion creates a natural balance vs general warrants that the US rightly fought a revolution against my ancesters, the British over. Basically unless you think PRISM is a good idea, you should use DH. On Thu, Jul 04, 2013 at 12:37:40PM -0400, Thierry Moreau wrote: (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. Subpoena resistance is a pretty high priority for end user systems. 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). I think you are confusing forward secrecy (aka backward security) with backward secrecy (forward security). Ross Anderson tried to improve things with his forward secure/backward secure alternative terminology: http://www.cypherspace.org/adam/nifs/refs/forwardsecure.pdf Forward secrecy is a bad term from a mnemonic point of view, I think Anderson's forward/backward security terms are better. EDH provides both, k'=H(k) provides only backward security (aka forward secrecy). The point is you do both; you can computationally afford to do k'=H(k) with an agile key-schedule cipher like AES every minute or whatever. Adam ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] SSL session resumption defective (Re: What project would you finance? [WAS: Potential funding for crypto-related projects])
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
Re: [cryptography] SSL session resumption defective (Re: What project would you finance? [WAS: Potential funding for crypto-related projects])
On Tue, Jul 2, 2013 at 10:07 AM, 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. The whole point of session resumption is to make that fast. It can't be too fast if it implies public key cryptography. Now, with ECC DH it's probably fast enough anyways, so, yes, we should do this. Do you think anyone would be interested in fixing that? It's already possible to resume then renegotiate with an anon ECC DH cipher suite. Oh, wait, no, anon ECC DH with AES cipher suites were left out (by accident). So the fix might just be to register the missing cipher suites and always renego with one of those immediately after resuming a session. We could then work on a round-trip optimized session resumption with PFS feature. But first we'd have to get users to use cipher suites with PFS. We're not really there. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] SSL session resumption defective (Re: What project would you finance? [WAS: Potential funding for crypto-related projects])
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), propagate that to all the replicas of the session database, and carry on with the client. From my POV, that propagation cost way more than just dropping the session and starting again would - sessions are only profitable if they are write-once read-many. So why would I ever cache sessions? So, now, every new connection is a new asymmetric handshake instead of a session resume. Consequence? I am motived to reduce my TLS traffic. Alternatively, we stay in this world, clients expire sessions hourly, and we're all happy. Do you think anyone would be interested in fixing that? Adam ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] SSL session resumption defective (Re: What project would you finance? [WAS: Potential funding for crypto-related projects])
On Jul 2, 2013, at 1:52 PM, Ben Laurie b...@links.org wrote: Alternatively, we stay in this world, clients expire sessions hourly, and we're all happy. Is this what most recent browsers do? They expire their TLS sessions after an hour? That would be nice. --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] SSL session resumption defective (Re: What project would you finance? [WAS: Potential funding for crypto-related projects])
On Tue, July 2, 2013 2:02 pm, Paul Hoffman wrote: On Jul 2, 2013, at 1:52 PM, Ben Laurie b...@links.org wrote: Alternatively, we stay in this world, clients expire sessions hourly, and we're all happy. Is this what most recent browsers do? They expire their TLS sessions after an hour? That would be nice. --Paul Hoffman Firefox and Chrome use a 24-hour period, as recommended - see http://mxr.mozilla.org/nss/source/lib/ssl/sslnonce.c#21 CryptoAPI/SChannel defaults to 10 hours, but I don't know if IE is tweaking that at all - see dwSessionLifespan for http://msdn.microsoft.com/en-us/library/windows/desktop/aa379810(v=vs.85).aspx OS X/SecureTransport uses ten minutes as the default - see SESSION_CACHE_TTL in http://www.opensource.apple.com/source/Security/Security-55179.11/libsecurity_ssl/security_ssl/appleSession.c ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] SSL session resumption defective (Re: What project would you finance? [WAS: Potential funding for crypto-related projects])
On Jul 2, 2013, at 2:59 PM, Ryan Sleevi ryan+cryptogra...@sleevi.com wrote: On Tue, July 2, 2013 2:02 pm, Paul Hoffman wrote: On Jul 2, 2013, at 1:52 PM, Ben Laurie b...@links.org wrote: Alternatively, we stay in this world, clients expire sessions hourly, and we're all happy. Is this what most recent browsers do? They expire their TLS sessions after an hour? That would be nice. --Paul Hoffman Firefox and Chrome use a 24-hour period, as recommended - see http://mxr.mozilla.org/nss/source/lib/ssl/sslnonce.c#21 CryptoAPI/SChannel defaults to 10 hours, but I don't know if IE is tweaking that at all - see dwSessionLifespan for http://msdn.microsoft.com/en-us/library/windows/desktop/aa379810(v=vs.85).aspx OS X/SecureTransport uses ten minutes as the default - see SESSION_CACHE_TTL in http://www.opensource.apple.com/source/Security/Security-55179.11/libsecurity_ssl/security_ssl/appleSession.c Is this what people are seeing when they test these clients against test servers? --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
