I have heard that with forward secrecy that the ECDSA ciphers generate different keys for "each session" because they are not dependent on the private key of the server. My question is how is "each session" defined? Does this different key approach mean it happens with each consecutive/different SSL connection to say the same server or does it happen within the existing SSL connection as server side SSL re-negotiation request happen?
Each session means each SSL session. An SSL session can be reused over multiple TCP connections (that is SSL connections) if both client and server implement session reuse and each of the SSL connections gets closed in a clean way.
A SSL connection might also consist of multiple SSL sessions if you do multiple full SSL handshakes within the same connection.
The key used to protect transmission of data must not be used to derive any additional keys, and if the key used to protect transmission of data is derived from some other keying material, then that material must not be used to derive any more keys. In this way, compromise of a single key permits access only to data protected by that single key.
PFS holds true above, but satisfies the two properties below:
- Generates random public keys per session for the purposes of key agreement
- Does not use any sort of deterministic algorithm in doing so
Addressing your questions in SSL/TLS
How is "each session" defined?
Ephemeral Diffie Hellman is used for PFS. Using Ephemeral Diffie Hellman (DHE/ECDHE) forces each session to renegotiate its DH parameter every time a single SSL session closes. So "each session" quite literally means as soon as the session ends the keys are destroyed. No session IDs are stored by the server, so new keys are forced each time.
Does this different key approach mean it happens with each consecutive/different SSL connection to say the same server or does it happen within the existing SSL connection as server side SSL re-negotiation request happen?
Doesn't matter if its the same server, or a server side re-negotiation the server shouldn't have cached session keys. So new DH parameters are needed with *DHE cipher suites. Now this is how the theory works. Configuration is kind of a different story. Some servers might have to disable session resumption to ensure this occurs.
Implementations SHOULD generate a new X for each handshake when using DHE cipher suites.