Extended Key Update for Transport Layer Security (TLS) 1.3

Extended Key Update for Transport Layer Security (TLS) 1.3 Siemens

hannes.tschofenig@gmx.net

Münster Univ. of Applied Sciences

tuexen@fh-muenster.de

Nokia

kondtir@gmail.com

Siemens

steffen.fries@siemens.com

Zscaler

yrosomakho@zscaler.com

Security Transport Layer Security Internet-Draft TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie-Hellman key exchange during the initial handshake, protecting past communications even if a party's long-term keys (typically a private key with a corresponding certificate) are later compromised. While the built-in KeyUpdate mechanism allows application traffic keys to be refreshed during a session, it does not incorporate fresh entropy from a new key exchange and therefore does not provide post-compromise security. This limitation can pose a security risk in long-lived sessions, such as those found in industrial IoT or telecommunications environments. To address this, this specification defines an extended key update mechanism that performs a fresh Diffie-Hellman exchange within an active session, thereby ensuring post-compromise security. By forcing attackers to exfiltrate new key material repeatedly, this approach mitigates the risks associated with static key compromise. Regular renewal of session keys helps contain the impact of such compromises. The extension is applicable to both TLS 1.3 and DTLS 1.3.

Introduction The Transport Layer Security (TLS) 1.3 protocol provides forward secrecy by using an ephemeral Diffie-Hellman (DHE) key exchange during the initial handshake. This ensures that encrypted communication remains confidential even if an attacker later obtains a party's long-term private key, protecting against passive adversaries 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 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 is impractical. Earlier versions of TLS supported session renegotiation, which allowed peers to negotiate fresh keying material, including performing new Diffie-Hellman exchanges during the session lifetime. Due to protocol complexity and known vulnerabilities, renegotiation was first restricted by and ultimately removed in TLS 1.3. While the KeyUpdate message was introduced to offer limited rekeying functionality, it does not fulfill the same cryptographic role as renegotiation and cannot refresh the TLS main secret and consequently cannot derive new secrets from fresh DHE input. Security guidance from national agencies, such as ANSSI (France ), recommends the periodic renewal of cryptographic keys during long-lived sessions to limit the impact of key compromise. This approach encourages designs that force an attacker to perform dynamic key exfiltration, as defined in . Dynamic key exfiltration refers to attack scenarios where an adversary must repeatedly extract fresh keying material to maintain access to protected data, increasing operational cost and risk for the attacker. In contrast, static key exfiltration, where the TLS main secret is extracted once and reused, poses a greater long-term threat, especially when session keys are not refreshed with fresh key exchange input rather than key derivation. This specification defines a TLS extension that introduces an extended key update 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 keys that are independent of prior key material. As noted in , this approach mitigates the risk of static key exfiltration and shifts the attacker burden toward dynamic key exfiltration. The proposed extension is applicable to both TLS 1.3 and DTLS 1.3 . For clarity, the term "TLS" is used throughout this document to refer to both protocols unless otherwise specified.

Terminology and Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. To distinguish the key update procedure defined in from the key update procedure specified in this document, we use the terms "standard key update" and "extended key update", respectively. In this document, we use the term post-compromise security, as defined in . We assume that an adversary may obtain 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 occurs after the handshake phase has completed, no handshake traffic keys are involved. In this document, send key refers to the [sender]_write_key, and receive key refers to the [receiver]_write_key. These keys are derived from the active client_application_traffic_secret_N and server_application_traffic_secret_N, as defined in (D)TLS 1.3 , and are replaced with new ones after each successful Extended Key Update.

Negotiating the Extended Key Update Client and servers use the TLS flags extension to indicate support for the functionality defined in this document. We call this flag "Extended_Key_Update" flag. The "Extended_Key_Update" flag proposed by the client in the ClientHello (CH) MUST be acknowledged in the EncryptedExtensions (EE), if the server also supports the functionality defined in this document and is configured to use it. If the "Extended_Key_Update" flag is not set, servers ignore any of the functionality specified in this document and applications that require post-compromise security will have to initiate a full handshake.

Extended Key Update Messages If the client and server agree to use the extended key update mechanism, the standard key update MUST NOT be used. In this case, the extended key update fully replaces the standard key update functionality. Implementations that receive a classic KeyUpdate message after successfully negotiating the Extended Key Update functionality MUST terminate the connection with an "unexpected_message" alert. The extended key update messages are signaled in a new handshake message named ExtendedKeyUpdate (EKU), with an internal uint8 message subtype indicating its role. This specification defines three ExtendedKeyUpdate message subtypes:

key_update_request (0)
key_update_response (1)
new_key_update (2)

New ExtendedKeyUpdate message subtypes are assigned by IANA as described in . A TLS peer which receives a ExtendedKeyUpdate with an unexpected message subtype MUST abort the connection with an "unexpected_message" alert. The extended key update process can be initiated by either peer after it has sent a Finished message. Implementations that receive an ExtendedKeyUpdate message prior to the sender having sent Finished MUST terminate the connection with an "unexpected_message" alert. The KeyShareEntry carried in a key_update_request and in a key_update_response MUST use the group that was negotiated by the client and server during the initial handshake. An implementation that receives an algorithm other than previously negotiated MUST terminate the connection with an "illegal_parameter" alert. shows the interaction graphically. First, support for the functionality in this specification is negotiated in the ClientHello and the EncryptedExtensions messages. Then, the ExtendedKeyUpdate exchange is sent to update the application traffic secrets. The extended key update exchange is performed between the initiator and the responder; either the TLS client or the TLS server may act as initiator.

Extended Key Update Message Exchange in TLS 1.3. ServerHello ^ Key + key_share | Exch v {EncryptedExtensions ^ Server + extended_key_update} | Params {CertificateRequest} v {Certificate} ^ {CertificateVerify} | Auth {Finished} v <-------- ^ {Certificate} Auth | {CertificateVerify} v {Finished} --------> [Application Data]N <-------> [Application Data]N ... [EKU(key_update_request)]N --------> <-------- [EKU(key_update_response)]N [EKU(new_key_update)]N --------> ... [Application Data]N+1 <-------> [Application Data]N+1 Legend: + Indicates noteworthy extensions sent in the previously noted message. - Indicates optional or situation-dependent messages/extensions that are not always sent. () Indicates messages protected using keys derived from a client_early_traffic_secret. {} Indicates messages protected using keys derived from a [sender]_handshake_traffic_secret. []N Indicates messages protected using keys derived from [sender]_application_traffic_secret_N. ]]> The ExtendedKeyUpdate wire format is: Fields:

eku_type: the subtype of the ExtendedKeyUpdate message.
key_share: key share information. The contents of this field is determined by the specified group and its corresponding definition (see ).

TLS 1.3 Considerations The following steps are taken by a TLS 1.3 implementation; the steps executed with DTLS 1.3 differ slightly.

The initiator sends ExtendedKeyUpdate(key_update_request) carrying a KeyShareEntry. While an extended key update is in progress, the initiator MUST NOT initiate another key update.
Upon receipt, the responder sends its own KeyShareEntry in a ExtendedKeyUpdate(key_update_response) message. While an extended key update is in progress, the responder MUST NOT initiate another key update. The responder MAY defer sending a response if system load or resource constraints prevent immediate processing. In such cases, the response MUST be sent once sufficient resources become available.
After the responder sends ExtendedKeyUpdate(key_update_response) it MUST update its send keys.
Upon receipt of an ExtendedKeyUpdate(key_update_response) the initiator derives the new secrets from the exchanged key shares. The initiator then updates its receive keys and sends an empty ExtendedKeyUpdate(new_key_update) message to complete the process. The initiator MUST NOT defer derivation of the secrets and sending the ExtendedKeyUpdate(new_key_update) message as it would stall the communication.
After sending ExtendedKeyUpdate(new_key_update) initiator MUST update its send keys.
After receiving the initiator’s ExtendedKeyUpdate(new_key_update), the responder MUST update its receive keys.

Both initiator and responder MUST encrypt their ExtendedKeyUpdate messages with the old keys. Responder MUST ensure that the ExtendedKeyUpdate(new_key_update) encrypted with the old key is received before accepting any messages encrypted with the new key. If TLS peers independently initiate the extended key update and the requests cross in flight, the ExtendedKeyUpdate(key_update_request) with the lower lexicographic order of the key_exchange value in KeyShareEntry MUST be ignored. This prevents each side from advancing keys by two generations. If the tie-break comparison yields equality (an event that should be impossible for genuine asymmetric key pairs), the endpoint MUST treat this as a protocol violation, send an "unexpected_message" alert, and close the connection. The handshake framing uses a single HandshakeType for this message (see ).

TLS 1.3 Handshake Structure.

TLS 1.3 Extended Key Update Example While shows the high-level interaction between a TLS 1.3 client and server, this section shows an example message exchange with information about the updated keys added. There are two phases:

The support for the functionality in this specification is negotiated in the ClientHello and the EncryptedExtensions messages.
Once the initial handshake is completed, a key update can be triggered.

provides an overview of the exchange starting with the initial negotiation followed by the key update.

Extended Key Update Example. ServerHello ^ Key + key_share | Exch v {EncryptedExtensions ^ Server + extended_key_update} | Params {CertificateRequest} v {Certificate} ^ {CertificateVerify} | Auth {Finished} v <-------- ^ {Certificate} Auth | {CertificateVerify} v {Finished} --------> ... some time later ... [EKU(key_update_request --------> (with key_share))] <-------- [EKU(key_update_response (with key_share))] # Server derives new secrets # and updates SEND keys here # Client derives new secrets # and updates RECEIVE keys here [EKU(new_key_update)] --------> # Client updates SEND keys here # Server updates RECEIVE keys here ]]>

DTLS 1.3 Considerations Unlike TLS 1.3, DTLS 1.3 implementations must take into account that handshake messages are not transmitted over a reliable transport protocol. EKU messages MUST be transmitted reliably, like other DTLS handshake messages. If necessary, EKU messages MAY be fragmented as described in . Due to the possibility of an ExtendedKeyUpdate messages being lost and thereby preventing the sender of that message from updating its keying material, receivers MUST retain the pre-update keying material until receipt and successful decryption of a message using the new keys. Due to packet loss and/or reordering, DTLS 1.3 peers MAY receive records from an earlier epoch. If the necessary keys are available, implementations SHOULD attempt to process such records; however, they MAY choose to discard them. The exchange has the following steps:

The initiator sends an ExtendedKeyUpdate(key_update_request) message, which contains a key share. While an extended key update is in progress, the initiator MUST NOT initiate further key updates. This message is subject to DTLS handshake retransmission, but delivery is only confirmed when the initiator either receives the corresponding ExtendedKeyUpdate(key_update_response) or an ACK.
Upon receipt, the responder sends its own KeyShareEntry in a ExtendedKeyUpdate(key_update_response) message. While an extended key update is in progress, the responder MUST NOT initiate further key updates. The responder MAY defer sending a response if system load or resource constraints prevent immediate processing. In such cases, the responder MUST acknowledge receipt of the key_update_request with an ACK and, once sufficient resources become available, retransmit the key_update_response until it is acknowledged by the initiator.
On receipt of ExtendedKeyUpdate(key_update_response) the initiator derives a secret key based on the exchanged key shares. This message also serves as an implicit acknowledgment of the initiator's ExtendedKeyUpdate(key_update_request), so no separate ACK is required. The initiator MUST update its receive keys and epoch value. The initiator MUST NOT defer derivation of the secrets.
The initiator transmits an ExtendedKeyUpdate(new_key_update) message. This message is subject to DTLS retransmission until acknowledged.
The responder MUST acknowledge the received message by sending an ACK message.
After the responder receives the initiator's ExtendedKeyUpdate(new_key_update), the responder MUST update its send key and epoch value. With the receipt of that message, the responder MUST also update its receive keys.
On receipt of the ACK message, the initiator updates its send key and epoch value. If this ACK is not received, the initiator re-transmits its ExtendedKeyUpdate(new_key_update) until ACK is received. The key update is complete once this ACK is processed by the initiator.

The handshake framing uses a single HandshakeType for this message (see ).

DTLS 1.3 Handshake Structure.

DTLS 1.3 Extended Key Update Example The following example illustrates a successful extended key update, including how the epochs change during the exchange.

Example DTLS 1.3 Extended Key Update: Message Exchange. [C: tx=3, rx=3] [S: tx=3, rx=3] [C: tx=3, rx=3] [S: tx=3, rx=3] <-------- [Application Data] [C: tx=3, rx=3] [S: tx=3, rx=3] /---------------------------------------\ | Some time later ... | \---------------------------------------/ [C: tx=3, rx=3] [S: tx=3, rx=3] [EKU(key_update_request)] --------> # no epoch change yet <-------- [EKU(key_update_response)] # Sent under OLD epoch. Server does NOT bump yet. # Step 3: initiator bumps RECEIVE epoch on # receiving key update response-in: # (rx:=rx+1; tx still old) [C: tx=3, rx=4] [S: tx=3, rx=3] [EKU(new_key_update)] --------> # Sender's NKU is tagged with OLD tx (3). # Epoch switch point: # Step 6: responder bumps BOTH tx and rx on NKU-in: [C: tx=3, rx=4] [S: tx=4, rx=4] <-------- [ACK] (tag=new) # Step 7: initiator bumps SEND epoch on ACK-in: [C: tx=4, rx=4] [S: tx=4, rx=4] [Application Data] --------> [C: tx=4, rx=4] [S: tx=4, rx=4] <-------- [Application Data] [C: tx=4, rx=4] [S: tx=4, rx=4] ]]> shows the steps, the message in flight, and the epoch changes on both sides. The A/B -> X/Y notation indicates the change of epoch values for tx/rx before and after the message transmission.

Example DTLS 1.3 Extended Key Update: Epoch Changes. | 3/3 -> 3/3 | 3/3 -> 3/3 | | <------------ APP | 3/3 -> 3/3 | 3/3 -> 3/3 | | req -------------> | 3/3 -> 3/3 | 3/3 -> 3/3 | | <------------ resp | 3/3 -> 3/4 | 3/3 -> 3/3 | <- step 3 | NKU ------------> | 3/4 -> 3/4 | 3/3 -> 4/4 | <- step 6 | <------------- ACK | 3/4 -> 4/4 | 4/4 -> 4/4 | <- step 7 | APP -------------> | 4/4 -> 4/4 | 4/4 -> 4/4 | | <------------- APP | 4/4 -> 4/4 | 4/4 -> 4/4 | +--------------------+----------------+--------------+ ]]>

Updating Traffic Keys When the extended key update message exchange is completed both peers have successfully updated their application traffic keys. The key derivation function described in this document is used to perform this update. The design of the key derivation function for computing the next generation of application_traffic_secret is motivated by the desire to include

a secret derived from the (EC)DHE exchange (or from the hybrid key exchange / PQ-KEM exchange),
a secret that allows the new key exchange to be cryptographically bound to the previously established secret,
the concatenation of the ExtendedKeyUpdate(key_update_request) and the ExtendedKeyUpdate(key_update_response) messages, which contain the key shares, binding the encapsulated shared secret ciphertext to IKM in case of hybrid key exchange, and
new label strings to distinguish it from the key derivation used in TLS 1.3.

The following diagram shows the key derivation hierarchy. HKDF-Extract = Main Secret N+1 | +-----> Derive-Secret(., "c ap traffic", | EKU(key_update_request) || | EKU(key_update_response)) | = client_application_traffic_secret_N+1 | +-----> Derive-Secret(., "s ap traffic", | EKU(key_update_request) || | EKU(key_update_response)) | = server_application_traffic_secret_N+1 | +-----> Derive-Secret(., "exp master", | EKU(key_update_request) || | EKU(key_update_response)) | = exporter_secret_N+1 | +-----> Derive-Secret(., "res master", | EKU(key_update_request) || | EKU(key_update_response)) = resumption_main_secret_N+1 ]]> During the initial handshake, the Main Secret is generated (see ). Since the Main Secret is discarded during the key derivation procedure, a derived value is stored. This stored value then serves as the input salt to the first key update procedure that incorporates the ephemeral (EC)DHE- established value as input keying material (IKM) to produce main_secret_{N+1}. The derived value from this new master secret serves as input salt to the subsequent key update procedure, which also incorporates a fresh ephemeral (EC)DHE value as IKM. This process is repeated for each additional key update procedure. The traffic keys are re-derived from client_application_traffic_secret_N+1 and server_application_traffic_secret_N+1, as described in . Once client_/server_application_traffic_secret_N+1 and its associated traffic keys have been computed, implementations SHOULD delete client_/server_application_traffic_secret_N and its associated traffic keys as soon as possible. Note: The client_/server_application_traffic_secret_N and its associated traffic keys can only be deleted by the responder after receiving the ExtendedKeyUpdate(new_key_update) message. Once client_/server_application_traffic_secret_N+1 and the corresponding traffic keys are in use, all subsequent records, including alerts and post-handshake messages MUST be protected using those keys. When using this extension, it is important to consider its interaction with ticket-based session resumption. If resumption occurs without a new (EC)DH exchange that provides forward secrecy, an attacker could potentially revert the security context to an earlier state, thereby negating the benefits of the extended key update. To preserve the security guarantees provided by key updates, endpoints MUST either invalidate any session tickets issued prior to the key update or ensure that resumption always involves a fresh (EC)DH exchange. If session tickets cannot be stored securely, developers SHOULD consider disabling ticket-based resumption in their deployments. While this approach may impact performance, it provides improved security properties.

Post-Quantum Cryptography Considerations Hybrid key exchange refers to the simultaneous use of multiple key exchange algorithms, with the resulting shared secret derived by combining the outputs of each. The goal of this approach is to maintain security even if all but one of the component algorithms are later found to be vulnerable. The transition to post-quantum cryptography has motivated the adoption of hybrid key exchanges in TLS, as described in . Specific hybrid groups have been registered in . When hybrid key exchange is used, the key_exchange field of each KeyShareEntry in the initial handshake is formed by concatenating the key_exchange fields of the constituent algorithms. This same approach is reused during the Extended Key Update, when new key shares are exchanged. The specification in registers the lattice-based ML-KEM algorithm and its variants, such as ML-KEM-512, ML-KEM-768 and ML-KEM-1024. The KEM encapsulation key or KEM ciphertext is represented as a 'KeyShareEntry' field. This same approach is reused during the Extended Key Update, when new key shares are exchanged.

SSLKEYLOGFILE Update As a successful extended key update exchange invalidates previous secrets, SSLKEYLOGFILE needs to be populated with new entries. As a result, two additional secret labels are utilized in the SSLKEYLOGFILE:

CLIENT_TRAFFIC_SECRET_N+1: identifies the client_application_traffic_secret_N+1 in the key schedule
SERVER_TRAFFIC_SECRET_N+1: identifies the server_application_traffic_secret_N+1 in the key schedule
EXPORTER_SECRET_N+1: identifies the exporter_secret_N+1 in the key schedule

Similar to other entries in the SSLKEYLOGFILE, the label is followed by the 32-byte value of the Random field from the ClientHello message that established the TLS connection, and the corresponding secret encoded in hexadecimal. SSLKEYLOGFILE entries for the extended key update MUST NOT be produced if SSLKEYLOGFILE was not used for other secrets in the handshake. Note that each successful Extended Key Update invalidates all previous SSLKEYLOGFILE secrets including past iterations of CLIENT_TRAFFIC_SECRET_, SERVER_TRAFFIC_SECRET_ and EXPORTER_SECRET_.

Exporter

Post-Compromise Security for the Initial Exporter Secret The TLS 1.3 Key Schedule, see Figure 5 of , derives the exporter_secret from the main secret. This exporter_secret is static for the lifetime of the connection and is not updated by a standard key update. A core design goal of this specification is not met if the exporter_secret does not change. Therefore, this document defines an exporter interface that derives a fresh exporter secret whenever new application traffic keys are updated through the EKU. If the initial exporter secret for this new interface were identical to exporter_secret, then compromising exporter_secret at any point during the lifetime of the connection would enable an attacker to recompute all exporter outputs derived from it. This would break post-compromise security for exported keying material. Therefore, the initial exporter secret used by the exporter interface defined in this document, i.e., the exporter output available prior to the first Extended Key Update, MUST be distinct from the exporter_secret. This separation ensures that compromise of the TLS exporter interface does not compromise outputs derived from the exporter interface defined in this document. Prior to the first Extended Key Update, the exporter interface provides an initial exporter secret, denoted exporter_secret_0. This secret is derived from the TLS main secret and the handshake transcript, but is cryptographically independent of the TLS exporter_secret. It is computed as follows: Applications that require post-compromise security MUST use the exporter interface defined in this document. This exporter interface is independent of the TLS exporter defined in , which continues to use a static exporter_secret for the lifetime of the connection for compatiblity with "legacy" applications.

Exporter Usage After Extended Key Update Protocols such as DTLS-SRTP and DTLS-over-SCTP rely on TLS or DTLS for key establishment, but reuse portions of the derived keying material for their own specific purposes. These protocols use the TLS exporter defined in . Exporters are also used for deriving authentication related values such as nonces, as described in . Once the Extended Key Update mechanism is complete, such protocols would need to use the newly derived exporter secret to generate Exported Keying Material (EKM) to protect packets. The "sk" derived in the will be used as the "Secret" in the exporter function, defined in , to generate EKM, ensuring that the exported keying material is aligned with the updated security context. The newly derived exporter secret is cryptographically independent of previous exporter secrets. When a new exporter secret becomes active following a successful Extended Key Update, the TLS or DTLS implementation would have to provide an asynchronous notification to the application indicating that:

A new epoch has become active, and the (D)TLS implementation can include the corresponding epoch identifier. Applications receiving an epoch identifier can use it to request keying material for that specific epoch through an epoch-aware exporter interface. In TLS, this identifier represents a local logical counter that may differ between peers.

Applications are notified that a new epoch is active only after both peers have completed the Extended Key Update exchange and switched to the new traffic keys.

In TLS, the initiator triggers notification after Step 5 in , and the responder triggers notification after Step 4 in .
In DTLS, the initiator triggers notification to the application after Step 7 in , and the responder triggers notification after Step 9 in .

The corresponding EKM is obtained by the application through the TLS/DTLS exporter interface using its chosen label and context values as defined in . To prevent desynchronization, the application will have to retain both the previous and the newly derived exporter secrets for a short period. For TLS, the previous exporter secret would be discarded once data derived from the new exporter has been successfully processed, and no records protected with the old exporter secret are expected to arrive. For DTLS, the previous exporter secret needs to be retained until the retention timer expires for the prior epoch, to allow for processing of packets that may arrive out of order. The retention policy for exporter secrets is application-specific. For example, in DTLS-SRTP, the application might retain the previous exporter secret until its replay window no longer accepts packets protected with keys derived from that secret, as described in Section 3.3.2 of .

Use of Post-Handshake Authentication and Exported Authenticators with Extended Key Update EKU provides fresh traffic secrets, but EKU alone does not authenticate that both endpoints derived the same updated keys. An attacker that temporarily compromises an endpoint may later act as an active MitM capable of interfering with the EKU exchange. Such an attacker can cause the peers to transition to divergent traffic secrets without detection, but cannot compromise the endpoint to derive secrets after the new epoch is established. To confirm that both peers transitioned to the same new key state, TLS 1.3 provides two mechanisms: Post-Handshake Certificate-Based Client Authentication and Exported Authenticators .

Post-Handshake Certificate-Based Client Authentication When Post-handshake Certificate-Based Client Authentication (Section 4.6.2 of ) is performed after an Extended Key Update is complete, it produces a Finished message computed using the application traffic keys of the new epoch. This confirms that both peers are operating with the same updated traffic keys and completes an authenticated transition after the EKU.

Exported Authenticators This document updates Section 5.1 of to specify that, after an Extended Key Update has completed, the Handshake Context and Finished MAC Key used for Exported Authenticators can be derived from the exporter secret associated with the current epoch. Implementations that support the epoch-aware Exported Authenticators interface will have to provide a means for applications to request the generation or validation of Exported Authenticators using the exporter secret for a specific epoch. The Handshake Context and Finished MAC Key used in both the CertificateVerify message (Section 5.2.2 of ) and the Finished message (Section 5.2.3 of ) are derived from the exporter secret associated with the current epoch. If a MitM interferes with the EKU exchange and causes the peers to derive different traffic and exporter secrets, their Handshake Contexts and Finished MAC Keys will differ. As a result, validation procedures specified in Section 5.2.4 of will fail, thereby detecting the divergence of key state between peers. A new optional API SHOULD be defined to permit applications to request or verify Exported Authenticators for a specific exporter epoch. As discussed in Section 7 of , this can, as an exception, be implemented at the application layer when the epoch-aware TLS exporter is available. The APIs defined in remain unchanged, so existing applications continue to operate without modification. The epoch-aware API accepts an epoch identifier; when present, the (D)TLS implementation MUST derive the Handshake Context and Finished MAC Key from the exporter secret associated with that epoch. When Exported Authenticators are generated using the epoch-aware Exported Authenticators interface, the epoch identifier used for their derivation can be conveyed in the certificate_request_context field, allowing the peer, particularly in DTLS where records may be reordered, to determine the correct exporter secret for validation.

Security Considerations This section discusses additional security and operational aspects introduced by the Extended Key Update mechanism. All security considerations of TLS 1.3 and DTLS.13 continue to apply.

Scope of Key Compromise Extended Key Update assumes a transient compromise of the current application traffic keys, not a persistent attacker with ongoing access to key material. The procedure itself does not rely on long-term private keys; those are assumed to remain secure, as they are typically stored in a secure element, such as a Trusted Execution Environment (TEE), Hardware Security Module (HSM), or Trusted Platform Module (TPM). In contrast, application traffic keys are stored within the rich operating system, where short-term exposure due to memory disclosure or transient compromise may occur. Post-compromise security can be re-established, provided the compromise is no longer active when an Extended Key Update is performed. Extended Key Update can restore confidentiality only if the attacker no longer has access to either peer. If an adversary retains access to current application traffic keys and can act as a man-in-the-middle during the Extended Key Update, then the update cannot restore security unless is used. If one of the mechanisms defined in is not used, the attacker can impersonate each endpoint, substitute EKU messages, and maintain control of the communication. When Post-handshake Certificate-Based Client Authentication or the modified Exported Authenticator mechanism is used, the authentication messages are bound to the keys established after the EKU. Any modification or substitution of EKU messages therefore becomes detectable, preventing this attack. If a compromise occurs before the handshake completes, the ephemeral key exchange, client_handshake_traffic_secret, server_handshake_traffic_secret, and the initial client_/server_application_traffic_secret could be exposed. In that case, only the initial handshake messages and the application data encrypted under the initial client_/server_application_traffic_secret can be decrypted until the Extended Key Update procedure completes. The Extended Key Update procedure derives fresh application_traffic_secrets from a new ephemeral key exchange, ensuring that all subsequent application data remains confidential.

Post-Compromise Security Extended Key Update provides post-compromise security for long-lived TLS sessions. To ensure post-compromise security guarantees:

Each update MUST use freshly generated ephemeral key-exchange material. Implementations MUST NOT reuse ephemeral key-exchange material across updates or across TLS sessions.

Denial-of-Service (DoS) The Extended Key Update mechanism increases computational and state-management overhead. A malicious peer could attempt to exhaust CPU or memory resources by initiating excessive update requests. Implementations SHOULD apply the following mitigations:

Limit the frequency of accepted Extended Key Update requests per session.
A peer that has sent an Extended Key Update MUST NOT initiate another until the previous update completes. If a peer violates this rule, the receiving peer MUST treat it as a protocol violation, send an "unexpected_message" alert, and terminate the connection.

Operational Guidance Deployments SHOULD evaluate Extended Key Update performance under load and fault conditions, such as high-frequency or concurrent updates. TLS policies SHOULD define explicit rate limits that balance post-compromise security benefits against potential DoS exposure.

IANA Considerations

TLS Flags IANA is requested to add the following entry to the "TLS Flags" extension registry :

Value: TBD1
Flag Name: extended_key_update
Messages: CH, EE
Recommended: Y
Reference: [This document]

TLS HandshakeType IANA is requested to add the following entry to the "TLS HandshakeType" registry :

Value: TBD2
Description: extended_key_update
DTLS-OK: Y
Reference: [This document]

ExtendedKeyUpdate Message Subtypes Registry IANA is requested to create a new registry "TLS ExtendedKeyUpdate Message Subtypes", within the existing "Transport Layer Security (TLS) Parameters" registry . This new registry reserves types used for Extended Key Update entries. The initial contents of this registry are as follows.

Value	Description	DTLS-OK	Reference
0	key_update_request	Y	This document
1	key_update_response	Y	This document
2	new_key_update	Y	This document
3-255	Unassigned

New assignments in the "TLS ExtendedKeyUpdate Types" registry will be administered by IANA through Specification Required procedure . The role of the designated expert is described in . The designated expert ensures that the specification is publicly available. It is sufficient to have an Internet-Draft (that is posted and never published as an RFC) or to cite a document from another standards body, industry consortium, or any other location. An expert may provide more in-depth reviews, but their approval should not be taken as an endorsement of the ExtendedKeyUpdate Message Subtype.

SSLKEYLOGFILE labels IANA is requested to add the following entries to the "TLS SSLKEYLOGFILE Labels" extension registry :

Value	Description	Reference	Comment
CLIENT_TRAFFIC_SECRET_N+1	Secret protecting client records after Extended Key Update	This document	N represents iteration of Extended Key Update
SERVER_TRAFFIC_SECRET_N+1	Secret protecting server records after Extended Key Update	This document	N represents iteration of Extended Key Update
EXPORTER_SECRET_N+1	Exporter secret after Extended Key Update	This document	N represents iteration of Extended Key Update

References Normative References The Transport Layer Security (TLS) Protocol Version 1.3 Independent This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. A Flags Extension for TLS 1.3 Dell Technologies A number of extensions are proposed in the TLS working group that carry no interesting information except the 1-bit indication that a certain optional feature is supported. Such extensions take 4 octets each. This document defines a flags extension that can provide such indications at an average marginal cost of 1 bit each. More precisely, it provides as many flag extensions as needed at 4 + the order of the last set bit divided by 8. The Concealed HTTP Authentication Scheme Most HTTP authentication schemes are probeable in the sense that it is possible for an unauthenticated client to probe whether an origin serves resources that require authentication. It is possible for an origin to hide the fact that it requires authentication by not generating Unauthorized status codes; however, that only works with non-cryptographic authentication schemes: cryptographic signatures require a fresh nonce to be signed. Prior to this document, there was no existing way for the origin to share such a nonce without exposing the fact that it serves resources that require authentication. This document defines a new non-probeable cryptographic authentication scheme. Keying Material Exporters for Transport Layer Security (TLS) A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. [STANDARDS-TRACK] The Secure Real-time Transport Protocol (SRTP) This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK] Exported Authenticators in TLS This document describes a mechanism that builds on Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) and enables peers to provide proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out of band to the other peer, and verified by the receiving peer. Informative References Recommendations for securing networks with IPsec, Technical Report ANSSI Transport Layer Security (TLS) Extensions IANA On Post-compromise Security IEEE Transport Layer Security (TLS) Renegotiation Indication Extension Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack. [STANDARDS-TRACK] Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement Since the initial revelations of pervasive surveillance in 2013, several classes of attacks on Internet communications have been discovered. In this document, we develop a threat model that describes these attacks on Internet confidentiality. We assume an attacker that is interested in undetected, indiscriminate eavesdropping. The threat model is based on published, verified attacks. Hybrid key exchange in TLS 1.3 University of Waterloo Cisco Systems University of Haifa and Meta Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if a way is found to defeat the encryption for all but one of the component algorithms. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 PQShield AWS Cloudflare University of Waterloo This draft defines three hybrid key agreements for TLS 1.3: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 which combine a post-quantum KEM with an elliptic curve Diffie-Hellman (ECDHE). ML-KEM Post-Quantum Key Agreement for TLS 1.3 SandboxAQ This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as NamedGroups and and registers IANA values in the TLS Supported Groups registry for use in TLS 1.3 to achieve post-quantum (PQ) key establishment. The SSLKEYLOGFILE Format for TLS Mozilla Zscaler University of Applied Sciences Bonn-Rhein-Sieg A format that supports logging information about the secrets used in a TLS connection is described. Recording secrets to a file in SSLKEYLOGFILE format allows diagnostic and logging tools that use this file to decrypt messages exchanged by TLS endpoints. This format is intended for use in systems where TLS only protects test data. Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. IANA Registry Updates for TLS and DTLS This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.

Acknowledgments We would like to thank the members of the "TSVWG DTLS for SCTP Requirements Design Team" for their discussion. The members, in no particular order, were:

Marcelo Ricardo Leitner
Zaheduzzaman Sarker
Magnus Westerlund
John Mattsson
Claudio Porfiri
Xin Long
Michael Tüxen
Hannes Tschofenig
K Tirumaleswar Reddy
Bertrand Rault

Additionally, we would like to thank the chairs of the Transport and Services Working Group (tsvwg) Gorry Fairhurst and Marten Seemann as well as the responsible area director Martin Duke. Finally, we would like to thank Martin Thomson, Ilari Liusvaara, Benjamin Kaduk, Scott Fluhrer, Dennis Jackson, David Benjamin, Matthijs van Duin, Rifaat Shekh-Yusef, Joe Birr-Pixton, Eric Rescorla, and Thom Wiggers for their review comments.

State Machines The sections below describe the state machines for the extended key update operation for TLS 1.3 and DTLS 1.3. The state machine diagrams in the Appendix are provided for illustrative purposes only to aid understanding of the protocol flow. They are not normative. In case of any discrepancy between the Appendix diagrams and the protocol behavior specified in the main body of this document, the text in the draft takes precedence. For editorial reasons we abbreviate the protocol message types:

Req - ExtendedKeyUpdate(request)
Resp - ExtendedKeyUpdate(response)
NKU - ExtendedKeyUpdate(new_key_update)
ACK - Acknowledgement message from
APP - application data payloads

In the (D)TLS 1.3 state machines discussed below, the terms SEND and RECEIVE keys refer to the send and receive key variables defined in . The TLS state machine diagrams use the following notation:

Numbered labels (1), (2), … denote normal protocol transitions in the order they occur.
Lettered labels (A), (B), … denote exceptional or conditional transitions.
Self-loops indicate that the state does not change as a result of the event.

TLS 1.3 State Machines This section describes the initiator and responder state machines.

NKU message is sent under old keys.
If a classic KeyUpdate arrives (EKU negotiated), ABORT "unexpected_message".
Crossed-requests: ignore the request with LOWER lexicographic key_exchange; if equal, abort.

Responder may defer Resp under load (no status reply), then must send it once resources are free.
If a classic KeyUpdate arrives (EKU negotiated), ABORT "unexpected_message".

DTLS 1.3 State Machines This section describes the initiator and responder state machines.

Terms and Abbreviations The following variables and abbreviations are used in the state machine diagrams.

rx - current, accepted receive epoch.
tx - current transmit epoch used for tagging outgoing messages.
E - initial epoch value.
updating - true while a key-update handshake is in progress.
old_rx - the previous receive epoch remembered during retention.
retain_old - when true, receiver accepts tags old_rx and rx.
tag=... - the TX-epoch value written on an outgoing message.
e==... - the epoch tag carried on an incoming message (what the peer sent).
FINISHED / START / WAIT_RESP / WAIT_I_NKU / WAIT_R_NKU / ACTIVATE RETENTION / RESPOND / WAIT_ACK - diagram states; FINISHED denotes the steady state after success.

Crossed requests. If both peers independently initiate the extended key update and the key_update_request messages cross in flight, compare the KeyShareEntry.key_exchange values. The request with the lower lexicographic value must be ignored. If the values are equal, the endpoint must abort with an "unexpected_message" alert. If the peer's value is higher than the local one, the endpoint abandons its in-flight update and processes the peer's request as responder.

State Machine (Initiator) The initiator starts in the START state with matching epochs (rx := E; tx := E). It sends a Req and enters WAIT_RESP (updating := 1). While waiting, APP data may be sent at any time (tagged with the current tx) and received according to the APP acceptance rule below. Once the responder returns Resp with a tag matching the current rx, the initiator derives new key material. It then sends NKU still tagged with the old tx. The initiator activates retention mode: the old epoch is remembered, the receive epoch is incremented, and application data is accepted under both epochs for a transition period. Initiator moves to WAIT_ACK. If a peer key_update_request arrives while in WAIT_RESP (crossed updates), apply the crossed-request rule above. If the peer's key_exchange is higher, abandon the local update (updating := 0) and continue as responder: send key_update_response, derive new secrets, then proceed with the responder flow. If lower, ignore the peer's request; if equal, abort with "unexpected_message". Upon receiving the responder's ACK matching the updated epoch, the initiator completes the transition by synchronizing transmit and receive epochs (tx := rx), disabling retention, and clearing the update flag. The state machine returns to FINISHED, ready for subsequent updates. Throughout the process:

Duplicate messages are tolerated (for retransmission handling).
Temporary epoch mismatches are permitted while an update is in progress.
Application data flows continuously, subject to epoch acceptance rules.

State Machine (Responder) The responder starts in the START state with synchronized transmit and receive epochs (rx := E; tx := E) and no update in progress. Application data can be transmitted at any time using the sender's current transmit epoch. A receiver must accept application data if the epoch tag on the DTLS record equals the receiver's current receive epoch. If the receiver has retention active (retain_old == true), the receiver must also accept DTLS records whose epoch tag equals the remembered previous epoch. Upon receiving an ExtendedKeyUpdate(key_update_request) (Req), the responder transitions to RESPOND. The responder may defer sending ExtendedKeyUpdate(key_update_response) under load; in that case it must acknowledge the request with an ACK and retransmit the response until it is acknowledged by the initiator, as specified in DTLS considerations. When sent, ExtendedKeyUpdate(key_update_response) is tagged with the current tx. After an ExtendedKeyUpdate(new_key_update) (NKU) is received with the correct epoch, the responder:

activates retention (old_rx := rx; retain_old := 1),
increments both epochs (rx++, tx++),
sends ACK tagged with the new tx (which now equals the new rx),
clears updating and enters FINISHED.

Retention at the responder ends automatically on the first APP received under the new rx (then retain_old := 0). APP traffic is otherwise permitted at any time; reordering is tolerated by the acceptance rule. APP acceptance rule (receiver): accept if e == rx or (retain_old && e == old_rx). If retain_old is set and an APP with the new rx arrives, clear retain_old.

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 . 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. This property provides only best-effort post-compromise security, as it assumes the attacker is not acting as a MiTM during the Extended Key Update. 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 , both Post-handshake Certificate-Based Client Authentication and Exported Authenticators can be used after an Extended Key Update to confirm that both endpoints derived the same traffic keys. Because the authentication messages produced by these mechanisms depend on values derived from the updated traffic keys, any divergence in those traffic keys causes validation to fail, revealing interference by an active attacker.