clear up forward secrecy

Author: drbruced12

tls.rst

@@ -318,10 +318,11 @@ the binding, and if the HMAC calculation succeeds, then the server and
 client now have agreement that they can use a shared secret
 established in the prior session. They use a "resumption master
 secret" that was calculated and stored in the prior session to derive
-a new set of keys for this session. The keys of the new
-session are different from those of the prior session to support
-forward secrecy (i.e., an attacker who learns the key for session N
-doesn't immediately have the keys for session N+1).
+a new set of keys for this session. The keys of the new session are
+different from those of the prior session to support forward secrecy
+(i.e., even if an attacker manages to compromise the key for one
+session, they don't gain the ability to decrypt data from other
+sessions).
 
 When the server sends its "Finished" message, it calculates the HMAC
 over the handshake messages using the agreed-upon new key, and thus
@@ -349,15 +350,15 @@ provided by the socket layer (b) the application must know how to deal
 with replays of data sent as 0-RTT, e.g., by only sending 0-RTT
 data for operations that are idempotent.
 
-The other drawback of 0-RTT data is that it depends on keys that are
+The other drawback of 0-RTT data is that it depends on tickets that are
 derived from secrets used in an earlier transaction. If those secrets
 were somehow compromised, the attacker would have the necessary
 information to compromise the new session. Thus, 0-RTT data lacks
 forward secrecy. For this reason, the option exists to generate a new
 set of keys as part of the session resumption handshake with a new
 Diffie-Hellman exchange. This means that only the data sent in the
 first RTT lacks forward secrecy, and the rest of the session is
-protected by the new, uncompromised keys.
+protected by the new ephemeral keys.
 
 
 All of this work to reduce the setup time of TLS by a single RTT might