Internet-Draft Extended Key Update for TLS January 2024
Tschofenig, et al. Expires 7 July 2024 [Page]
Intended Status:
Standards Track
H. Tschofenig
M. Tüxen
Münster Univ. of Applied Sciences
T. Reddy
S. Fries

Extended Key Update for Transport Layer Security (TLS) 1.3


The Transport Layer Security (TLS) 1.3 specification offers a dedicated message to update cryptographic keys during the lifetime of an ongoing session. It allows the sender to perform an update of the key and initialization vector and may trigger the recipient, via the request_update field, to transmit a key update message in the reverse direction.

In environments where sessions are long-lived, such as industrial IoT or telecommunication networks, this key update along is insufficient since perfect forward secrecy is not offered via this mechanism. Earlier versions of TLS allowed the two peers to perform renegotiation, which is a handshake that establishes new cryptographic parameters for an existing session. When a security vulnerability with the renegotiation mechanism was discovered, RFC 5746 was standardized as a fix. Renegotiation has, however, been removed from TLS 1.3.

This specification defines an extended key update message that supports perfect forward secrecy using a Diffie-Hellman key exchange.

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

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 7 July 2024.

Table of Contents

1. Introduction

The features of TLS and DTLS have changed over the years and while newer versions optimized and enhanced features (often with the help of extensions) some functionality was removed without replacement. The ability to update keys and initialization vectors with forward secrecy has been added in TLS 1.3 [I-D.ietf-tls-rfc8446bis] using the KeyUpdate message and it intended to (partially) replace renegotiation from earlier TLS versions. The renegotiation feature, while complex, offered additional functionality that is not supported with TLS 1.3 anymore, including the update keys with a Diffie-Hellman exchange during the lifetime of a session. If a traffic secret (application_traffic_secret_N) has been compromised, an attacker can passively eavesdrop on all future data sent on the connection, including data encrypted with application_traffic_secret_N+1, application_traffic_secret_N+2, etc.

While such a feature is less relevant in environments with shorter-lived sessions, such as transactions on the web, there are uses of TLS and DTLS where long-lived sessions are common. In those environments, such as industrial IoT and telecommunication networks, availability is important and an interruption of the communication due to periodic session resumptions is not an option. A full handshake with (EC)DHE gives protection against active attackers but prevents the use of long-lived sessions.

Some deployments have used IPsec in the past and have now decided to switch to TLS or DTLS instead and the requirement for updates of cryptographic keys for an existing session has become a requirement. For IPsec, NIST, BSI, and ANSSI recommends very frequent re-run of Diffie-Hellman to provide forward secrecy and force attackers to perform a dynamic key extraction [RFC7624]. ANSSI writes "It is recommended to force the periodic renewal of the keys, e.g., every hour and every 100 GB of data, in order to limit the impact of a key compromise." [ANSSI-DAT-NT-003].

This specification defines a new, extended key update message supporting perfect forward secrecy. It does so by utilizing a Diffie-Hellman exchange using one of the groups negotiated during the initial exchange. The support for this extension is signaled using the TLS flags extension mechanism. The frequent re-running of extended key update forces an attacker to do dynamic key exfiltration.

This specification is applicable to both TLS 1.3 [I-D.ietf-tls-rfc8446bis] and DTLS 1.3 [RFC9147]. Throughout the specification we do not distinguish between these two protocols unless necessary for better understanding.

2. Terminology and Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

To distinguish the key update procedure defined in [I-D.ietf-tls-rfc8446bis] from the key update procedure specified in this document, we use the terms "classic key update" and "extended key update", respectively.

3. Extensions

Client and servers use the TLS flags extension [I-D.ietf-tls-tlsflags] to indicate support for the functionality defined in this document. We call this the "extended_key_update" extension and the corresponding flag is called "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 the functionality specified in this document and applications that require perfect forward security will have to initiate a full handshake.

4. Extended Key Update

4.1. Generic Considerations

The ExtendedKeyUpdate handshake message is used to indicate an update of cryptographic keys. This key update process can be sent by either peer after it has sent a Finished message. Implementations that receive a ExtendedKeyUpdate message prior to receiving a Finished message MUST terminate the connection with an "unexpected_message" alert.

The design of the ExtendedKeyUpdate message follows the design of the classic KeyUpdate message. Both allow the update of keys in one direction only. However, the ExtendedKeyUpdate message requires a full-roundtrip due to the nature of the Diffie-Hellman exchange.

The KeyShare entry in the ExtendedKeyUpdate message MUST be the same group mutually supported by the client and server during the initial handshake. The peers MUST NOT send a KeyShare Entry in the ExtendedKeyUpdate message that is not mutually supported by the client and server during the initial handshake. An implementation that receives any other value 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 message is sent to update the application traffic secrets.

       Client                                           Server

Key  ^ ClientHello
Exch | + key_share
     | + signature_algorithms
     v + Extended_Key_Update       -------->
                                                  ServerHello  ^ Key
                                                  + key_share  | Exch
                                        {EncryptedExtensions   ^ Server
                                       + Extended_Key_Update}  | Params
                                         {CertificateRequest}  v
                                                {Certificate}  ^
                                          {CertificateVerify}  | Auth
                                                   {Finished}  v
     ^ {Certificate}
Auth | {CertificateVerify}
     v {Finished}              -------->
       [Application Data]      <------->  [Application Data]
       [ExtendedKeyUpdate]     -------->
                               <--------  [ExtendedKeyUpdate]
       [ExtendedKeyUpdate]     <-------
                               -------->  [ExtendedKeyUpdate]
       [Application Data]      <------->  [Application Data]
Figure 1: Extended Key Update Message Exchange.

The structure of the ExtendedKeyUpdate message is shown below. The sender starts the key update process and the receiver responds with its key share. The extended key update always consists of two messages, one from the sender to the receiver and another one from the receiver to the sender. Both messages use the same format but the response message MUST NOT have the request_update set to update_requested(1).

The structures for KeyUpdateRequest and KeyShareEntry are defined in [I-D.ietf-tls-rfc8446bis].

enum {
    update_not_requested(0), update_requested(1), (255)
} KeyUpdateRequest;

struct {
    KeyUpdateRequest request_update;
    KeyShareEntry key_share;
} ExtendedKeyUpdate;

If the request_update field is set to "update_requested", then the receiver MUST send an ExtendedKeyUpdate of its own with request_update set to "update_not_requested" prior to sending its next Application Data record. This mechanism allows either side to force an update to the entire connection, but causes an implementation which receives multiple ExtendedKeyUpdate while it is silent to respond with a single update. Note that implementations may receive an arbitrary number of messages between sending a ExtendedKeyUpdate with request_update set to "update_requested" and receiving the peer's ExtendedKeyUpdate, because those messages may already be in flight. However, because send and receive keys are derived from independent traffic secrets, retaining the receive traffic secret does not threaten the forward secrecy of data sent before the sender changed keys.

Note: Implementations may receive an arbitrary number of messages between one peer sending a ExtendedKeyUpdate and this peer receiving the peer's ExtendedKeyUpdate, because those messages may already be in flight. This design aspect needs to be taken into account when designing APIs that inform applications using this extended key update procedure to guarantee perfect forward security.

If implementations independently send their own ExtendedKeyUpdate messages, and they cross in flight, the result is that each side increments keys by two generations.

Both sender and receiver MUST encrypt their ExtendedKeyUpdate messages with the old keys. Both sides MUST enforce that a ExtendedKeyUpdate messages with the old key is received before accepting any messages encrypted with the new key. Failure to do so may allow message truncation attacks.

If a sending implementation receives a ExtendedKeyUpdate with request_update set to "update_requested", it MUST NOT send its own ExtendedKeyUpdate if that would cause it to exceed these limits. This may result in an eventual need to terminate the connection when the limits in Section 5.5 of [I-D.ietf-tls-rfc8446bis] are reached.

The ExtendedKeyUpdate and the KeyUpdates MAY be used in combination, depending on the desired security properties.

The updated Handshake structure is shown in 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;
Figure 2: Handshake Structure.

4.2. DTLS 1.3-specific Considerations

DTLS 1.3 [RFC9147] requires the transmission of an ACK message to ensure the reliable transmission of the KeyUpdate message. Since the design of the ExtendedKeyUpdate message always requires a full roundtrip there is no need for a dedicated ACK message.

Figure 3 illustrates an example exchange of the ExtendedKeyUpdate message used to update traffic secrets in both directions in a DTLS 1.3 exchange.

   Client                                             Server

        |             Initial Handshake               |

    [Application Data]         ========>

                               <========      [Application Data]

        |              Some time later ...            |

    (epoch 3)                  -------->

                               <========      [Application Data]

                               <--------               (epoch=3)

|   Key Update (based on DH)   |

    [Application Data]
    (epoch=4)                  ========>

                               <--------     [ExtendedKeyUpdate]

    [ExtendedKeyUpdate]        -------->

                               |   Key Update (based on DH)   |

                               <========      [Application Data]
Figure 3: DTLS 1.3 Extended Key Update Example.

In order to facilitate epoch reconstruction in DTLS 1.3 (see Section 4.2.2 of [RFC9147]), implementations MUST NOT send records with the new keys or send a new ExtendedKeyUpdate messages until the previous key update has been completed. This avoids having too many epochs in active use.

Due to loss and/or reordering, DTLS 1.3 implementations may receive a record with an older epoch than the current one (the requirements above preclude receiving a newer record). They SHOULD attempt to process those records with that epoch (see Section 4.2.2 of [RFC9147] for information on determining the correct epoch) but MAY opt to discard such out-of-epoch records.

Due to the possibility of a response message of an initial ExtendedKeyUpdate being lost and thereby preventing the sender of the ExtendedKeyUpdate 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.

5. Updating Traffic Secrets

Once the handshake is complete, it is possible for either side to update its sending traffic keys using the ExtendedKeyUpdate handshake message. The next generation of traffic keys is computed by generating client_/server_application_traffic_secret_N+1 from client_/server_application_traffic_secret_N as described in this section and then re-deriving the traffic keys, as described in Section 7.3 of [I-D.ietf-tls-rfc8446bis].

There are three changes to the application_traffic_secret computation described in [I-D.ietf-tls-rfc8446bis], namely

The next-generation application_traffic_secret is computed as follows:

sk = HKDF-Extract(0, dh-secret)

application_traffic_secret_N+1 =
    Derive-Secret(sk,"traffic upd 2",

The next generation of traffic keys is computed using the HKDF, as defined in [RFC5869], and its two components, HKDF-Extract and HKDF-Expand, as recommended in Appendix F.1.1 of [I-D.ietf-tls-rfc8446bis].

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.

If a hybrid key exchange, based on [I-D.ietf-tls-hybrid-design], is used then the two shared secrets concatenated together serve as input to the HKDF-Extract function to produce the value sk.

6. Security Considerations

[RFC9325] provides a good summary of what (perfect) forward secrecy is and how it relates to the TLS protocol. In summary, it says:

"Forward secrecy (also called "perfect forward secrecy" or "PFS") is a defense against an attacker who records encrypted conversations where the session keys are only encrypted with the communicating parties' long-term keys. Should the attacker be able to obtain these long-term keys at some point later in time, the session keys and thus the entire conversation could be decrypted."

Appendix F of [I-D.ietf-tls-rfc8446bis] goes into details of explaining the security properties of the TLS 1.3 protocol and notes "... forward secrecy without rerunning (EC)DHE does not stop an attacker from doing static key exfiltration." It concludes with a recommendation by saying: "Frequently rerunning (EC)DHE forces an attacker to do dynamic key exfiltration (or content exfiltration)." (The term key exfiltration is defined in [RFC7624].)

This specification re-uses public key encryption to update application traffic secrets in both direction. Unlike the classic Key Update message defined in [I-D.ietf-tls-rfc8446bis], the key update procedure requires two messages.

7. IANA Considerations

IANA is requested to add the following entry to the "TLS Flags" extension registry defined in [I-D.ietf-tls-tlsflags]:

IANA is requested to add the following entry to the "TLS HandshakeType" [TLS-Ext-Registry] registry:

8. References

8.1. Normative References

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-rfc8446bis-09, , <>.
Nir, Y., "A Flags Extension for TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-tlsflags-12, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, , <>.
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, , <>.

8.2. Informative References

ANSSI, "Recommendations for securing networks with IPsec, Technical Report", , <>.
Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key exchange in TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-hybrid-design-09, , <>.
Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement", RFC 7624, DOI 10.17487/RFC7624, , <>.
Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, , <>.
IANA, "Transport Layer Security (TLS) Extensions", , <>.

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, are:

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 for his review of this specification.

Appendix B. Alternative Designs Considered

The design presented in this document utilizes an ephemeral Diffie-Hellman, which requires a full roundtrip since both parties need to exchange their ephemeral public keys. Since the Key Update design defined in TLS 1.3 utilizes a one-shot message, this new extension changes the behavior and is less efficient.

During the design of this specification two alternatives have been considered, which retained the original design spirit of the one-shot Key Update message by utilizing an ephemeral-static Diffie-Hellman. The static public key thereby represents a previously exchanged Diffie-Hellman public key. For the first Key Update message sent, this public key would thereby be the Diffie-Hellman public key from the key share in the initial ClientHello/ServerHello handshake message exchange. We considered two designs, one using a classical ephemeral-static Diffie-Hellman and a second design based on the Hybrid Public Key Encryption (HPKE) specification. HPKE is already used in the encrypted ClientHello and may therefore be present already in TLS stacks.

Ultimately, we decided against such an approach since it requires an implementation to keep their Diffie-Hellman public and private keys somewhere in memory (even though it is possible to utilize available hardware security modules to store the private key). The design in this document allows an implementation to discard this ephemeral Diffie-Hellman key pair immediately after the key update procedure has been finalized.

Authors' Addresses

Hannes Tschofenig
Michael Tüxen
Münster Univ. of Applied Sciences
Tirumaleswar Reddy
Steffen Fries