%% You should probably cite draft-ietf-tls-extended-key-update instead of this I-D. @techreport{tschofenig-tls-extended-key-update-02, number = {draft-tschofenig-tls-extended-key-update-02}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/02/}, author = {Hannes Tschofenig and Michael Tüxen and Tirumaleswar Reddy.K and Steffen Fries and Yaroslav Rosomakho}, title = {{Extended Key Update for Transport Layer Security (TLS) 1.3}}, pagetotal = 14, year = 2024, month = jul, day = 8, 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.}, }