D-H key re-use considerations #768
Conversation
Added a subsection to the Security Considerations section. It discusses key reuse (do it carefully or do it not). It has the "don't do this or this grape juice might ferment" weasel words suggested by someone at the meeting.
| @@ -4037,6 +4046,26 @@ lacking a "server_name" extension by terminating the connection with a | |||
| Security issues are discussed throughout this memo, especially in | |||
| {{implementation-notes}}, {{backward-compatibility}}, and {{security-analysis}}. | |||
|
|
|||
| ## Re-using Ephemeral shares | |||
There was a problem hiding this comment.
Consistent capital Letters?
| means that they are used for a short time. Keeping the private key secret forever | ||
| is necessary for the property of Perfect Forward Secrecy. The simplest and safest | ||
| way to achieve this is to generate a new Diffie-Hellman share for each TLS | ||
| handshake. This has some cost in processing power. |
There was a problem hiding this comment.
The simplest and safest way to achieve this is to generate a new Diffie-Hellman share for each TLS handshake, and to destroy keys after they are used.
There was a problem hiding this comment.
I'm changing the text, but you want to destroy the keys after use whether they are single-use or not.
| way to achieve this is to generate a new Diffie-Hellman share for each TLS | ||
| handshake. This has some cost in processing power. | ||
|
|
||
| Alternatively, it is possible to save some CPU cycles by generating a |
There was a problem hiding this comment.
I would drop "Alternatively, "
| often include wiping the memory that held the key after the last use, preventing | ||
| swap-out of that memory, and not providing an interface for the export of such | ||
| private keys. Possession of such keys will allow an attacker to decrypt the | ||
| contents of any TLS connection that was set up using this key. |
There was a problem hiding this comment.
Possession of either a client or server Diffie-Hellman private key will allow an attacker to decrypt the contents of any TLS connection [...]
|
From the paper:
And for ECDHE:
Given the simplicity of checks, I don't see why they shouldn't be mandatory in the first place. Secondly, the ecdhe section (#ecdhe-param) doesn't specify what kind of checks should be performed on the share... |
I agree.
Well, there's #763 that proposes this, and the feeling in the room was that people liked this. My PR is a little forward-looking then. |
| way to achieve this is to generate a new Diffie-Hellman share for each TLS | ||
| handshake, and to destroy keys immediately after they are used. This has some | ||
| cost in processing power. | ||
|
|
There was a problem hiding this comment.
Yes, our symbolic proofs assume that the DH keys are fresh. This needs to be true to achieve PFS as defined in [DOW92]. The definition in [DOW92] refers to the 'safety' (secrecy) of exchanged keys from earlier runs; perhaps the definition in Appendix D should be altered to reflect this, the current phrasing is strange.
Also, this phrasing seems somewhat odd to me "Keeping the private key secret forever is necessary for the property of Perfect Forward Secrecy." As phrased here, this suggests that compromise should never occur but PFS is defined in terms of a compromise.
There was a problem hiding this comment.
It isn't clear whether we need ephemeral keys to be fresh in our proofs (we use a variant of the Gap Diffie-Hellman assumption). For classic AKE properties (confidentiality and integrity) we need the peer's DH key to be "honest" and "strong", not necessarily fresh. For PFS, we need all the secrets of the session to be destroyed, not just the ephemerals. After the keys are derived, we destroy all master secrets and ephemeral secrets. After the connection is closed, we destroy the connection keys and EMS. This still leaves RMS whose compromise would break PFS for resumed sessions.
There was a problem hiding this comment.
But you don't get PFS if you're using the RMS only, right? That's why you need new DH shares.
There was a problem hiding this comment.
I agree it's clear that you don't get PFS if you don't use fresh DH keys. I think the question is whether the AKE properties of your proofs depend on the DH keys being fresh. @tvdmerwe is this something you could relax in the Tamarin model easily?
Basically, my concern here is that this text seems to say that it's OK to use non-fresh DH shares for 1.3, with the cost being PFS. If we're to incorporate text like that, it would be nice to have some analytic results which indicate that it's true.
There was a problem hiding this comment.
@tvdmerwe: I believe the properties wrt the RMS are as follows:
- Knowledge of the RMS established in connection N is not sufficient to decrypt N
- If you establish a new connection N+1 with the RMS as the PSK and do not do DH, then knowledge of the RMS is sufficient to decrypt N+1. However, N+1 generates its own RMS and that is not sufficient to decryption N+1 (though of course you can use it for N+2).
- If you operate a session cache type system, then the server can delete the RMS once it has been used to establish the session, giving you PFS even w/o DH
- If you operate a ticket-based system, you don't get PFS until the ticket key has been destroyed.
There was a problem hiding this comment.
Quick answer: yes (barring any complications that don't immediately come to mind).
Remind me, if DH shares aren't fresh, what secrets will be new? The RMS?
There was a problem hiding this comment.
I believe that in a non-resumed connection, the DH shared secret would be non-unique but the Handshake Secret and anything derived from it will be unique as long as the nonces are fresh. This also implies that the RMS will be different for two handshakes where the client and server both reuse DH shares.
There was a problem hiding this comment.
Thanks. Sounds about right!
|
Closed per WG consensus in Chicago |
Added a subsection to the Security Considerations section. It discusses key reuse (do it carefully or do it not).
It has the "don't do this or this grape juice might ferment" weasel words suggested by someone at the meeting.