]> Siemens

hannes.tschofenig@gmx.net

Münster Univ. of Applied Sciences

tuexen@fh-muenster.de

Nokia

kondtir@gmail.com

Siemens

steffen.fries@siemens.com

Security TLS Internet-Draft 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.

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 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 . 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." . 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 and DTLS 1.3 . Throughout the specification we do not distinguish between these two protocols unless necessary for better understanding.

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 . To distinguish the key update procedure defined in from the key update procedure specified in this document, we use the terms "classic key update" and "extended key update", respectively.

Extensions Client and servers use the TLS flags extension 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.

Extended Key Update

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

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

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 .

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

DTLS 1.3-specific Considerations DTLS 1.3 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. illustrates an example exchange of the ExtendedKeyUpdate message used to update traffic secrets in both directions in a DTLS 1.3 exchange.

(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) ]]>

In order to facilitate epoch reconstruction in DTLS 1.3 (see Section 4.2.2 of ), 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 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.

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 . There are three changes to the application_traffic_secret computation described in , 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:

The next generation of traffic keys is computed using the HKDF, as defined in , and its two components, HKDF-Extract and HKDF-Expand, as recommended in Appendix F.1.1 of . 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 , is used then the two shared secrets concatenated together serve as input to the HKDF-Extract function to produce the value sk.

Security Considerations 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 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 .) This specification re-uses public key encryption to update application traffic secrets in both direction. Unlike the classic Key Update message defined in , the key update procedure requires two messages.

IANA Considerations IANA is requested to add the following entry to the "TLS Flags" extension registry defined in : 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" registry: Value: TBD2 Description: extended_key_update DTLS-OK: Y Reference: [This document] Comment:

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. Windy Hill Systems, LLC 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, and 8446. This document also specifies new requirements for TLS 1.2 implementations. 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. 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. This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. 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. University of Waterloo Cisco Systems University of Haifa Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. 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. Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design. ANSSI IANA

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.

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.