Extended Key Update for Transport Layer Security (TLS) 1.3
draft-tschofenig-tls-extended-key-update-02
Document | Type |
Replaced Internet-Draft
(tls WG)
Expired & archived
|
|
---|---|---|---|
Authors | Hannes Tschofenig , Michael Tüxen , Tirumaleswar Reddy.K , Steffen Fries , Yaroslav Rosomakho | ||
Last updated | 2024-09-23 (Latest revision 2024-07-08) | ||
Replaced by | draft-ietf-tls-extended-key-update | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | (None) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | Adopted by a WG | |
Document shepherd | (None) | ||
IESG | IESG state | Replaced by draft-ietf-tls-extended-key-update | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
The Transport Layer Security (TLS) 1.3 specification offers a dedicated message to update cryptographic keys during the lifetime of an ongoing session. The traffic secret and the initialization vector are updated directionally but the sender 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 alone is insufficient since 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 developed as a fix. Renegotiation has, however, been removed from version 1.3 leaving a gap in the feature set of TLS. This specification defines an extended key update that supports forward secrecy.
Authors
Hannes Tschofenig
Michael Tüxen
Tirumaleswar Reddy.K
Steffen Fries
Yaroslav Rosomakho
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)