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

Copyright Notice

Copyright (c) 2024 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 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

       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]      <------->  [Application Data]
                                  ...
       [ExtendedKeyUpdate]     -------->
                               <--------  [ExtendedKeyUpdate]
                                  ...
       [ExtendedKeyUpdate]     <-------
                               -------->  [ExtendedKeyUpdate]
                                  ...
       [Application Data]      <------->  [Application Data]

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

struct {
    KeyUpdateRequest request_update;
    KeyShareEntry key_share;
} ExtendedKeyUpdate;

      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

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

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

                               <========      [Application Data]
                                                       (epoch=3)

         /-------------------------------------------\
        |              Some time later ...            |
         \-------------------------------------------/

    [ExtendedKeyUpdate]
    (epoch 3)                  -------->


                               <========      [Application Data]
                                                       (epoch=3)

                                             [ExtendedKeyUpdate]
                               <--------               (epoch=3)

 /----------------------------\
|   Key Update (based on DH)   |
 \----------------------------/

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

                               <--------     [ExtendedKeyUpdate]
                                                       (epoch=3)

    [ExtendedKeyUpdate]        -------->
    (epoch=4)

                                /----------------------------\
                               |   Key Update (based on DH)   |
                                \----------------------------/

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

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 application_traffic_secret_N is not used as an secret as it may be already exfiltrated by the attacker.¶

• the label is adjusted to distinguish it from the classic KeyUpdate message, and¶

• the Diffie-Hellman derived shared secret, as 'dh-secret', is used as input to the HKDF-Expand-Label() function to produce the value sk. sk is subsequently included as a secret value in the computation of the application_traffic_secret_N+1, making the next generation traffic key of the application traffic secret dependent on the DH-derived value.¶

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",
                  application_traffic_secret_N)

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]:¶

• Value: TBD1¶

• Flag Name: extended_key_update¶

• Messages: CH, EE¶

• Recommended: Y¶

• Reference: [This document]¶

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

• Value: TBD2¶

• Description: extended_key_update¶

• DTLS-OK: Y¶

• Reference: [This document]¶

• Comment:¶

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

• 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 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