Extended Key Update for Transport Layer Security (TLS) 1.3

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 18 July 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. 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 [TLS-RENEGOTIATION] 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 [ANSSI]), 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 [CONFIDENTIALITY]. 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 Appendix F of [TLS], 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 [TLS] and DTLS 1.3 [DTLS]. For clarity, the term "TLS" is used throughout this document to refer to both protocols unless otherwise specified.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

To distinguish the key update procedure defined in [TLS] 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 [CCG16]. 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 [TLS], and are replaced with new ones after each successful Extended Key Update.¶

3. Negotiating the Extended Key Update

Client and servers use the TLS flags extension [TLS-FLAGS] 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.¶

4. 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 Section 13.3.¶

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.¶

Figure 1 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.¶

       Client                                           Server

Key  ^ ClientHello
Exch | + key_share
     | + signature_algorithms
     v + extended_key_update   -------->
                                                  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:¶

enum {
   key_update_request(0),
   key_update_response(1),
   new_key_update(2),
   (255)
} ExtendedKeyUpdateType;

struct {
   ExtendedKeyUpdateType eku_type;
   select (eku_type) {
      case key_update_request: {
          KeyShareEntry key_share;
      }
      case key_update_response: {
          KeyShareEntry key_share;
      }
      case new_key_update: {
          /* empty */
      }
   };
} ExtendedKeyUpdate;

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 Section 4.2.8 of [TLS]).¶

5. TLS 1.3 Considerations

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

1. 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.¶

2. 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.¶

3. After the responder sends ExtendedKeyUpdate(key_update_response) it MUST update its send keys.¶

4. 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.¶

5. After sending ExtendedKeyUpdate(new_key_update) initiator MUST update its send keys.¶

6. 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 Figure 2).¶

      struct {
          HandshakeType msg_type;    /* handshake type */
          uint24 length;             /* bytes in message */
          select (Handshake.msg_type) {
              case client_hello:          ClientHello;
              case server_hello:          ServerHello;
              case end_of_early_data:     EndOfEarlyData;
              case encrypted_extensions:  EncryptedExtensions;
              case certificate_request:   CertificateRequest;
              case certificate:           Certificate;
              case certificate_verify:    CertificateVerify;
              case finished:              Finished;
              case new_session_ticket:    NewSessionTicket;
              case key_update:            KeyUpdate;
              case extended_key_update:   ExtendedKeyUpdate;
          };
      } Handshake;

       Client                                           Server

Key  ^ ClientHello
Exch | + key_share
     | + signature_algorithms
     v + extended_key_update
                             -------->
                                                  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

6. 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 Section 5.5 of [DTLS]. 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:¶

1. 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.¶

2. 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.¶

3. 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.¶

4. The initiator transmits an ExtendedKeyUpdate(new_key_update) message. This message is subject to DTLS retransmission until acknowledged.¶

5. The responder MUST acknowledge the received message by sending an ACK message.¶

6. 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.¶

7. 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 Figure 4).¶

       enum {
           client_hello(1),
           server_hello(2),
           new_session_ticket(4),
           end_of_early_data(5),
           encrypted_extensions(8),
           request_connection_id(9),
           new_connection_id(10),
           certificate(11),
           certificate_request(13),
           certificate_verify(15),
           finished(20),
           key_update(24),
           extended_key_update(TBD),  /* new */
           message_hash(254),
           (255)
       } HandshakeType;

       struct {
           HandshakeType msg_type;    /* handshake type */
           uint24 length;             /* bytes in message */
           uint16 message_seq;        /* DTLS-required field */
           uint24 fragment_offset;    /* DTLS-required field */
           uint24 fragment_length;    /* DTLS-required field */
           select (msg_type) {
               case client_hello:          ClientHello;
               case server_hello:          ServerHello;
               case end_of_early_data:     EndOfEarlyData;
               case encrypted_extensions:  EncryptedExtensions;
               case certificate_request:   CertificateRequest;
               case certificate:           Certificate;
               case certificate_verify:    CertificateVerify;
               case finished:              Finished;
               case new_session_ticket:    NewSessionTicket;
               case key_update:            KeyUpdate;
               case extended_key_update:   ExtendedKeyUpdate;
               case request_connection_id: RequestConnectionId;
               case new_connection_id:     NewConnectionId;
           } body;
       } DTLSHandshake;

Client                            Server
(Initiator)                       (Responder)

  /---------------------------------------\
 |           Initial Handshake             |
  \---------------------------------------/

[C: tx=3, rx=3]                   [S: tx=3, rx=3]
[Application Data]               -------->
[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]

+--------------------+----------------+--------------+
| Message            | Client tx/rx   | Server tx/rx |
+--------------------+----------------+--------------+
| APP ------------>  | 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   |
+--------------------+----------------+--------------+

7. 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.¶

       Main Secret N
             |
             v
       Derive-Secret(., "derived", "")
             |
             v
 (EC)DHE -> 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 Section 7.1 of [TLS]). 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 Section 7.3 of [TLS].¶

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.¶

8. 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 [TLS-HYBRID]. Specific hybrid groups have been registered in [TLS-ECDHE-MLKEM]. 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 [TLS-MLKEM] 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.¶

9. SSLKEYLOGFILE Update

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

1. CLIENT_TRAFFIC_SECRET_N+1: identifies the client_application_traffic_secret_N+1 in the key schedule¶

2. SERVER_TRAFFIC_SECRET_N+1: identifies the server_application_traffic_secret_N+1 in the key schedule¶

3. 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_.¶

10. Exporter

exporter_secret_0 =
Derive-Secret(Main Secret,
"exporter eku",
Transcript-Hash(ClientHello..server Finished))

11. 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 [RFC9261].¶

12. Security Considerations

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] continue to apply.¶

13. IANA Considerations

14. References

Appendix A. 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.¶

Appendix B. 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 Section 7 of [DTLS]¶

• 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 Section 2.¶

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.¶

Appendix C. 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.¶

Authors' Addresses