Added Security Goals and fixed terminology

draft-ietf-tls-extended-key-update.md

@@ -110,7 +110,7 @@ who record encrypted traffic for later decryption.
 TLS 1.3 also includes a KeyUpdate mechanism that allows traffic keys to be refreshed
 during an established session. However, this mechanism does not provide
 post-compromise security, as it applies only a key derivation function to the
-previous application traffic secret as input. While this design is generally sufficient
+previous application traffic key as input. While this design is generally sufficient
 for short-lived connections, it may present security limitations in scenarios where
 sessions persist for extended periods, such as in industrial IoT or telecommunications
 systems, where continuous availability is critical and session renegotiation or resumption
@@ -139,7 +139,7 @@ This specification defines a TLS extension that introduces an extended key updat
 mechanism. Unlike the standard key update, this mechanism allows peers to perform a
 fresh Diffie-Hellman exchange within an active session using one of the groups
 negotiated during the initial handshake. By periodically rerunning (EC)DHE, this
-extension enables the derivation of new traffic secrets that are independent of
+extension enables the derivation of new traffic keys that are independent of
 prior key material. As noted in {{Appendix F of !TLS=I-D.ietf-tls-rfc8446bis}}, this
 approach mitigates the risk of static key exfiltration and shifts the attacker
 burden toward dynamic key exfiltration.
@@ -158,7 +158,7 @@ from the key update procedure specified in this document, we use the terms
 
 In this document, we use the term post-compromise security, as defined in
 {{CCG16}}. We assume that an adversary may obtain
-access to the application traffic secrets.
+access to the application traffic keys.
 
 Unless otherwise specified, all references to traffic keys in this document
 refer to application traffic keys and because the Extended Key Update procedure
@@ -621,10 +621,10 @@ the message transmission.
 {: #dtls-table title="Example DTLS 1.3 Extended Key Update: Epoch Changes."}
 
 
-# Updating Traffic Secrets {#key_update}
+# Updating Traffic Keys {#key_update}
 
 When the extended key update message exchange is completed both peers
-have successfully updated their application traffic secrets. The
+have successfully updated their application traffic keys. The
 key derivation function described in this document is used to perform
 this update.
 
@@ -817,15 +817,15 @@ secret, as described in Section 3.3.2 of {{!RFC3711}}.
 
 # Use of Exported Authenticators with Extended Key Update {#exported}
 
-EKU provides fresh traffic secrets, but EKU alone does not authenticate
+EKU provides fresh traffic keys, but EKU alone does not authenticate
 that both endpoints derived the same updated keys. An active attacker
 interfering with an EKU exchange could cause key divergence without detection.
 
 To confirm that both peers transitioned to the same new key state, endpoints
 can use Exported Authenticators {{?RFC9261}} immediately after completing EKU.
 However, the authenticator transcript defined in {{?RFC9261}} does not cover the
 EKU messages. As a result, an authenticator generated after EKU is not bound to the
-newly derived traffic secrets.
+newly derived traffic keys.
 
 To ensure MiTM-resilient key updates, this document updates Section 5.2.2 of
 {{?RFC9261}} to incorporate the Extended Key Update transcript (Hash(EKU-Transcript))
@@ -839,7 +839,7 @@ Section 5.2.2 of {{?RFC9261}}.
 
 This section discusses additional security and operational aspects introduced by the Extended Key Update mechanism. All security considerations of TLS 1.3 {{TLS}} and DTLS.13 {{!DTLS=RFC9147}} continue to apply.
 
-## Scope of Key Compromise
+## Scope of Key Compromise {#scope}
 
 Extended Key Update assumes a transient compromise of the current application
 traffic keys, not a persistent attacker with ongoing access to key material.
@@ -1257,3 +1257,30 @@ Throughout the process:
 | FINISHED  |
 +-----------+
 ~~~
+
+
+# Overview of Security Goals
+
+A complete security analysis of the EKU is outside the scope of this document. This appendix provides an informal description of the primary security goals that EKU is designed to achieve.
+
+## Post-Compromise Security (PCS)
+
+Extended Key Update supports post-compromise security under the assumptions described in {{scope}}. If an attacker temporarily compromises an endpoint and obtains the traffic keys in use before an Extended Key Update takes place, but the compromise does not persist after the EKU completes, the attacker cannot derive the new keying material established by EKU. This property follows from the use of fresh ephemeral key exchange material during each Extended Key Update, which produces new traffic keys that are independent of the previous ones.
+
+As a result, confidentiality of application data encrypted after the Extended Key Update is preserved even if the earlier traffic keys were exposed.
+
+## Key Freshness and Cryptographic Independence
+
+Each Extended Key Update derives new traffic keys from ephemeral key exchange material. This ensures strong separation between successive traffic keys:
+
+* The new traffic keys established by an Extended Key Update are independent of the previous traffic keys.
+* Compromise of one of traffic keys does not allow recovery of any earlier or later traffic keys.
+* Application data protected under one of the traffic keys cannot be decrypted using keys from another.
+
+## Elimination of Standard KeyUpdate
+
+Once Extended Key Update has been negotiated for a session, peers rely exclusively on EKU rather than the standard TLS 1.3 KeyUpdate mechanism. Relying solely on Extended Key Update helps maintain PCS properties throughout the lifetime of the TLS session.
+
+## Detecting Divergent Key State
+
+As described in {{exported}}, Exported Authenticators can be used after an Extended Key Update to confirm that both endpoints derived the same traffic keys. Because the authenticator computation depends on the exporter secret associated with the most recent EKU, any divergence in traffic keys causes signature validation to fail, revealing interference by an active attacker.