Transport Layer Security B. c Zhou Internet-Draft Independent Obsoletes: [8446, 5077, 5246, 6961, 8422] (if 31 August 2025 approved) Updates: [5705, 6066, 7627, 8422] (if approved) Intended status: Standards Track Expires: 4 March 2026 The Transport Layer Security (TLS) Protocol Version 1.4 draft-zhou-tls-tls14-00 Abstract This document specifies a new version of the Transport Layer Security (TLS) protocol, version 1.4. It is designed to address key challenges that have emerged since the standardization of TLS 1.3, specifically related to the mobility of devices, the need for enhanced 0-RTT security, the integration of post-quantum cryptography, and the refinement of downgrade protection mechanisms. TLS 1.4 introduces a fundamental architectural shift by decoupling the cryptographic session state from the underlying transport-layer connection. This is achieved through a new, transport-agnostic Connection ID (CID). The protocol also provides a new, cryptographically-enforced replay defense for 0-RTT handshakes based on an atomic "read-compare-write" operation on a single-use Session Nonce. A native hybrid post-quantum key exchange framework is integrated into the handshake, offering a robust "safety net" against future cryptanalytic threats. This specification formally obsoletes TLS 1.3 (RFC 8446) and all its related mechanisms. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. 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 4 March 2026. Copyright Notice Copyright (c) 2025 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction 1.1. Core Architectural Principles 1.1.1. Decoupling: Separation of Session and Transport 1.1.2. Atomicity: The Read-Compare-Write Operation 1.1.3. The Core Triple: Session State Components 1.2. Handshake Protocol 1.2.1. Full Handshake (1-RTT) 1.2.2. Connection Migration and 0-RTT Handshake 1.2.3. Key and Master Secret Updates 1.3. Record Protocol and Padding 1.4. Downgrade Protection and Alerts 1.4.1. Alerts 1.5. Extended Configuration and ECH 1.6. Deprecations and Obsoletions 1.7. Security Considerations 1.8. IANA Considerations 2. References 2.1. Normative References 2.2. Informative References Author's Address 1. Introduction The Transport Layer Security (TLS) protocol has long been the cornerstone of secure communications on the Internet. With the standardization of TLS 1.3 (RFC 8446), the protocol achieved a significant reduction in handshake latency and an enhancement of its cryptographic hygiene. However, the subsequent years have highlighted new requirements and challenges driven by the evolution of network architecture and the advent of powerful new computing paradigms. The core motivations for the development of TLS 1.4 are: * *Connection and Session Decoupling:* In an era of ubiquitous mobile devices, network transitions (e.g., from Wi-Fi to 5G) are a common occurrence. Prior TLS versions, which implicitly tied the session to a transport-layer identifier (like the TCP 4-tuple), would require a full re-handshake upon a network change, causing disruption and latency. TLS 1.4 addresses this by introducing a new, transport-agnostic session identifier. * *Atomic 0-RTT:* While TLS 1.3 introduced a 0-RTT mechanism for latency reduction, it relied on time-based replay protection, a method that is complex to implement robustly across a distributed server infrastructure. TLS 1.4 introduces a fundamentally different approach, using an atomic, single-use nonce to provide a stateless, cryptographically-enforced replay defense that is both simple and highly effective in many deployment scenarios. * *Post-Quantum Hybrid Cryptography:* The threat of a large-scale quantum computer capable of breaking current public-key cryptography is no longer theoretical. To ensure the long-term security of the Internet, TLS 1.4 provides a native, integrated framework for deploying Post-Quantum Cryptography (PQC) alongside traditional algorithms. This hybrid approach allows for a secure transition, providing a "safety net" where the session's security is guaranteed as long as either the traditional or the PQC algorithm remains uncompromised. * *Enhanced Downgrade Protection:* To prevent attacks where an adversary forces a connection to an older, less secure protocol version, TLS 1.4 strengthens the downgrade protection mechanism with a non-negotiable handshake verification process. This document formally obsoletes TLS 1.3 (RFC 8446) and all its related mechanisms, including the Session Resumption ticket (RFC 5077), the Session Hash and Extended Master Secret (RFC 7627), and the original Connection ID (RFC 6961 and RFC 8422). 1.1. Core Architectural Principles The TLS 1.4 protocol is built on two primary architectural principles: Decoupling and Atomicity. These principles are managed by a core set of cryptographic components, forming the "Core Triple." 1.1.1. Decoupling: Separation of Session and Transport The protocol fundamentally separates the *TLS session's cryptographic state* from the underlying *transport-layer state*. A session is no longer tied to the ephemeral properties of the network connection but is identified by a unique, opaque, and stable identifier. The core component enabling this decoupling is the *Connection ID (CID)*. The CID is a variable-length identifier (negotiated to be 4, 8, or 16 bytes) that is independently assigned by the server to each session during the full handshake. The client MUST include this CID in a dedicated record layer field for every TLS record. This allows the server to look up the correct session state without relying on network-layer information such as the TCP 4-tuple. * *CID Lifecycle:* The CID is generated by the server and sent to the client. The client uses this CID for all subsequent records related to that session, regardless of the underlying network path. The server MAY issue a new CID to the client at any point in the session to facilitate session updates or for privacy reasons. 1.1.2. Atomicity: The Read-Compare-Write Operation TLS 1.4's 0-RTT mechanism is designed around an *atomic operation* at the server to provide a deterministic and robust defense against replay attacks. The mechanism relies on a single-use credential, the *Session Nonce (SN)*. The server's atomic operation is a single, indivisible "read-compare- write" action that MUST be performed on the server's session state table: 1. *Read:* The server reads the provided Session Nonce from the incoming client_hello_0rtt message, identified by the CID. 2. *Compare:* The server performs a cryptographically secure comparison of the received Nonce with the one stored in its session state table. This comparison MUST be constant-time to prevent timing attacks. 3. *Write:* If the nonces match, the server immediately and atomically replaces the old Nonce with a new, randomly generated one. This atomic process ensures that any subsequent attempts to use the same Session Nonce will fail, as the server's stored value has already been updated. The new Session Nonce is sent to the client in the server_hello_0rtt message, completing the exchange of a fresh, one-time credential. 1.1.3. The Core Triple: Session State Components The session state is managed by a core triple of cryptographic components: * *Connection ID (CID):* A unique, opaque identifier for a session, assigned by the server. It is the primary lookup key for a session's state on the server. * *Session Nonce (SN):* A 64-byte, one-time-use random value. It acts as a single-use credential for 0-RTT data. The size of 64 bytes is chosen to be sufficiently large for cryptographic randomness while also leaving room for future nonce-derivation schemes. * *Master Secret (MS):* The root key for the entire session. It is generated during the initial full handshake and is used to derive all subsequent session keys. 1.2. Handshake Protocol 1.2.1. Full Handshake (1-RTT) The full handshake is a TLS 1.3-like ephemeral key exchange with significant modifications to support hybrid post-quantum key exchange. 1.2.1.1. ClientHello The ClientHello message MUST include two new extensions: supported_pqc and pqc_key_share. These are in addition to the standard TLS 1.3 extensions. The format of a ClientHello is defined as: struct { uint16 legacy_version = 0x0305; /* TLS 1.4 */ opaque random[32]; opaque legacy_session_id<0..32>; CipherSuite cipher_suites<2..2^16-2>; opaque legacy_compression_methods<1..2^8-1>; Extension extensions<0..2^16-1>; } ClientHello; To provide backward compatibility, the legacy_version field is set to 0x0305 (TLS 1.4), but the client MAY use a different value to trick legacy middleboxes, such as 0x0304 (TLS 1.3). The random field is a 32-byte opaque value that helps in key derivation. The legacy_session_id field is set to a non-zero, single value to satisfy older implementations, but its contents are ignored by TLS 1.4 servers. The extensions field MUST contain: * A *supported_groups extension* for traditional key exchange algorithms (e.g., X25519, secp256r1). * A *key_share extension* containing the public key for a traditional algorithm from the supported_groups list. * A *supported_pqc extension* for post-quantum algorithms (e.g., Kyber-768, Dilithium-512). The client lists its preferred PQC algorithms here in descending order of preference. * A *pqc_key_share extension* containing the public key for a PQC algorithm from the supported_pqc list. 1.2.1.2. ServerHello The server processes the ClientHello and responds with a ServerHello. The server has two primary options for key exchange negotiation: * *Hybrid Mode (SHOULD):* This is the preferred mode. The server MUST select a pair of a traditional and a PQC algorithm from the client's lists. - The chosen traditional algorithm is sent in the ServerHello.supported_groups field. - The chosen PQC algorithm is sent in the ServerHello.supported_pqc extension. - The server's public key for the traditional algorithm is sent in the ServerHello.key_share extension. - The server's public key for the PQC algorithm is sent in the ServerHello.pqc_key_share extension. * *PQC-Only Mode (MAY):* If the server does not support a traditional algorithm from the client's list, or is configured for PQC-only, it MUST select a PQC algorithm. - The server sends a reserved value 0x1F (to be registered by IANA) in the ServerHello.supported_groups field to explicitly indicate "PQC-only". - The chosen PQC algorithm is sent in the ServerHello.supported_pqc extension. - The ServerHello.key_share extension is *omitted*. - The server's public key for the PQC algorithm is sent in the ServerHello.pqc_key_share extension. 1.2.1.3. Master Secret Derivation In hybrid mode, the *Master Secret* is derived from both the traditional and PQC shared secrets using the HKDF-Extract and HKDF- Expand functions. This ensures that the session remains secure even if one of the underlying cryptographic primitives is broken. The derivation process is as follows: +======================================+==+=======================+ | $shared_secret_{hybrid} = | | shared_secret_{pqc}$ | | shared_secret_{traditional} | | | +======================================+==+=======================+ | $MasterSecret = HKDF- | | server_hello.random)$ | | Extract(shared_secret_{hybrid}, | | | | client_hello.random | | | +--------------------------------------+--+-----------------------+ Table 1 After the initial handshake, the server generates a *Connection ID* and an initial *Session Nonce*. These are securely transmitted to the client as part of the encrypted handshake extensions and are used for all subsequent 0-RTT handshakes. 1.2.2. Connection Migration and 0-RTT Handshake TLS 1.4 introduces a new, dedicated 0-RTT handshake type to allow for immediate application data transfer upon session resumption or connection migration. This mechanism is fundamentally different from the TLS 1.3 new_session_ticket approach. 1.2.2.1. ClientHello0rtt Message The client initiates the 0-RTT handshake by sending a client_hello_0rtt message. This message is specifically designed to be concise and does not contain all fields of a standard ClientHello. The handshake type is 0x03. The format of the client_hello_0rtt message is as follows: struct { uint8 type = 0x03; /* client_hello_0rtt */ uint24 length; uint16 legacy_version = 0x0305; /* TLS 1.4 */ opaque connection_id<4..16>; opaque session_nonce<64>; Extension extensions<0..2^16-1>; opaque application_data<0..2^16-1>; } ClientHello0rtt; The application_data field contains the early application data, which is encrypted using a key derived from the Master Secret and the Session Nonce. 1.2.2.2. ServerHello0rtt Message Upon receiving the client_hello_0rtt message, the server performs the atomic verification of the provided Session Nonce. * *Verification Failure:* If the Nonce comparison fails, the server MUST immediately drop the packet and send a cleartext session_nonce_mismatch alert. The client, upon receiving this alert, MUST abort the 0-RTT handshake and initiate a full 1-RTT handshake. * *Verification Success and Response:* If the verification succeeds, the server sends a server_hello_0rtt message. This message is encrypted using the Master Secret and contains the new Session Nonce for future 0-RTT handshakes. It also includes the Certificate and CertificateVerify messages to prevent IP address spoofing, and a Finished message to conclude the handshake. The format of the server_hello_0rtt message is as follows: struct { uint8 type = 0x04; /* server_hello_0rtt */ uint24 length; uint16 legacy_version = 0x0305; /* TLS 1.4 */ opaque new_session_nonce<64>; Extension extensions<0..2^16-1>; Certificate certificate; CertificateVerify certificate_verify; Finished finished; opaque application_data<0..2^16-1>; } ServerHello0rtt; The server response also includes the Certificate and CertificateVerify messages for server identity validation, and a Finished message to conclude the handshake. 1.2.3. Key and Master Secret Updates TLS 1.4 supports the Master Secret update mechanism from TLS 1.3 (RFC 8446) but with a new extension to provide explicit control. A new extension, master_secret_update_allowed, can be sent in the ServerHello to indicate if the server permits Master Secret updates for this session. The new Session Nonce is piggybacked in this update process. If the client sends a key_update message and this extension is not present or marked as false, the request MUST be ignored and the client SHOULD terminate the connection with an unsupported_extension alert. 1.3. Record Protocol and Padding TLS 1.4 introduces a new record layer format. The Connection ID field is a mandatory addition to every TLS record. struct { opaque connection_id<4..16>; uint8 opaque_type; uint16 legacy_record_version = 0x0305; uint16 length; opaque encrypted_payload[TLSPlaintext.length]; } TLSCiphertext; TLS 1.4 mandates a standardized padding scheme for all encrypted payloads. The padding MUST consist of all zero bytes, and the total length of the payload (including padding) MUST be a multiple of 16. This is a mandatory requirement for all implementations to ensure interoperability and to mitigate certain side-channel attacks based on payload size. The padding length is implicitly derived from the total payload length. The client or server can add up to 15 bytes of zero padding to ensure the total length is a multiple of 16. 1.4. Downgrade Protection and Alerts To prevent downgrade attacks, TLS 1.4 clients and servers MUST implement a specific check using a series of 8-byte magic numbers embedded in the ServerHello.random field. The logic is as follows: * If a TLS 1.4 server negotiates TLS 1.3, the last 8 bytes of the ServerHello.random MUST be the magic number: 0x444F574E47524402. * If a TLS 1.4 server negotiates TLS 1.2, the last 8 bytes of the ServerHello.random MUST be 0x444F574E47524401. * If a TLS 1.4 server negotiates TLS 1.1 or older, the last 8 bytes of the ServerHello.random MUST be 0x444F574E47524400. A TLS 1.4 client that receives a ServerHello.random ending with one of these values MUST immediately terminate the connection with an illegal_parameter alert, thereby preventing a successful downgrade. 1.4.1. Alerts This document defines a more comprehensive set of alerts to provide better error handling and debugging. * *session_nonce_mismatch (201):* Sent by the server when the provided Session Nonce in a 0-RTT handshake does not match the one stored in the session state table. * *unsupported_pqc_algorithm (202):* Sent by the server if the client's supported_pqc list does not contain a PQC algorithm supported by the server. * *invalid_connection_id (203):* Sent by either peer when a Connection ID is received that is not associated with an active session. * *illegal_parameter (204):* Sent when a handshake message contains an invalid parameter, such as a malformed extension or an incorrect field value. This is used for downgrade protection and other general errors. 1.5. Extended Configuration and ECH If a client, via DNS records or other out-of-band mechanisms, detects that a server supports *ECH (Encrypted ClientHello)*, it MUST initiate an ECH handshake. An ECH-enabled server receiving a bare TLS 1.4 handshake (without ECH) MUST reject the connection and attempt a graceful downgrade. The server will send a ServerHello with the last 8 bytes of random set to 0x444F574E47524403, a specific downgrade signal for ECH fallback. This forces the client to fall back to a TLS 1.3 handshake as per the downgrade protection mechanism, allowing for a smooth transition. 1.6. Deprecations and Obsoletions This document formally obsoletes RFC 8446, TLS 1.3. As a result, the following TLS 1.3 extensions and mechanisms are deprecated in TLS 1.4: * *pre_shared_key extension:* Replaced by the more flexible and replay-resistant Connection ID and Session Nonce mechanism. * *psk_key_exchange_modes extension:* Obsolete due to the removal of PSK. * *cookie extension:* Obsolete as the new 0-RTT mechanism does not require a cookie. * *client_hello_id extension:* Obsolete. * *new_session_ticket mechanism:* Replaced by the Session Nonce- based 0-RTT handshake, which provides a more robust replay defense. * *Original connection_id extension (RFC 6961, updated by RFC 8422):* Obsoleted by the new, more robust, and protocol-native Connection ID v2 extension. 1.7. Security Considerations The atomic 0-RTT mechanism provides a robust defense against replay attacks in a single-server environment. However, this model faces significant challenges in high-concurrency, distributed environments. Without a centralized, synchronized, and low-latency state store, there is a risk of a replay attack succeeding if a second server in a cluster processes the same 0-RTT packet before the first server can update the shared state. This document acknowledges this as a known weakness in a distributed context. Deployments requiring high- availability and large-scale load balancing may need to implement additional, more complex mechanisms to ensure full replay protection. Possible solutions for distributed deployments include: * *Distributed Consensus Algorithms:* Using protocols like Raft or Paxos to ensure a single, consistent state across all cluster nodes before a 0-RTT packet is processed. * *Optimistic Concurrency Control:* Each server in a cluster could attempt to atomically update the shared state. If the update fails (due to a race condition), the server could fall back to a 1-RTT handshake. * *Centralized Atomic State Store:* A dedicated, highly-available, and low-latency service (e.g., a distributed database with strong consistency guarantees) could be used to manage the Session Nonce state for the entire cluster. The hybrid post-quantum key exchange ensures a "safety net" where a session remains secure even if one of the two key exchange algorithms is broken. The Master Secret derivation from both shared secrets ensures that a compromise of one does not compromise the other. 1.8. IANA Considerations This document requires the registration of several new values with IANA. This document defines two new TLS handshake message types: * client_hello_0rtt (0x03) * server_hello_0rtt (0x04) This document defines new TLS extensions that require a formal codepoint: * supported_pqc * pqc_key_share * master_secret_update_allowed * Connection ID v2 A new ServerHello.supported_groups value for PQC-only mode also needs to be registered with IANA. We suggest 0x1F as a temporary value. This document also requests the allocation of a new alert code: * session_nonce_mismatch (201) * unsupported_pqc_algorithm (202) * invalid_connection_id (203) 2. References 2.1. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, . [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", RFC 6655, DOI 10.17487/RFC6655, July 2012, . [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, DOI 10.17487/RFC7627, September 2015, . [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)", RFC 7919, DOI 10.17487/RFC7919, August 2016, . [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, . 2.2. Informative References [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/RFC4346, April 2006, . [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, . [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, . [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, . [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, . [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", RFC 6091, DOI 10.17487/RFC6091, February 2011, . [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 2011, . [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, DOI 10.17487/RFC6520, February 2012, . [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, . [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, DOI 10.17487/RFC7465, February 2015, . [RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, DOI 10.17487/RFC7568, June 2015, . [RFC7624] 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, August 2015, . [RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello Padding Extension", RFC 7685, DOI 10.17487/RFC7685, October 2015, . [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, . [RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP)", RFC 8844, DOI 10.17487/RFC8844, January 2021, . [RFC8849] Even, R. and J. Lennox, "Mapping RTP Streams to Controlling Multiple Streams for Telepresence (CLUE) Media Captures", RFC 8849, DOI 10.17487/RFC8849, January 2021, . [RFC8870] Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F. Andreasen, "Encrypted Key Transport for DTLS and Secure RTP", RFC 8870, DOI 10.17487/RFC8870, January 2021, . [RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., and C. Wood, "Randomness Improvements for Security Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020, . [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, . [RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, June 2022, . [RFC9146] Rescorla, E., Ed., Tschofenig, H., Ed., Fossati, T., and A. Kraus, "Connection Identifier for DTLS 1.2", RFC 9146, DOI 10.17487/RFC9146, March 2022, . [RFC9149] Pauly, T., Schinazi, D., and C.A. Wood, "TLS Ticket Requests", RFC 9149, DOI 10.17487/RFC9149, April 2022, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, . [RFC9257] Housley, R., Hoyland, J., Sethi, M., and C. A. Wood, "Guidance for External Pre-Shared Key (PSK) Usage in TLS", RFC 9257, DOI 10.17487/RFC9257, July 2022, . [RFC9258] Benjamin, D. and C. A. Wood, "Importing External Pre- Shared Keys (PSKs) for TLS 1.3", RFC 9258, DOI 10.17487/RFC9258, July 2022, . [RFC9345] Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, "Delegated Credentials for TLS and DTLS", RFC 9345, DOI 10.17487/RFC9345, July 2023, . Author's Address Bocai Zhou Independent Email: draft-ietf-tls-tls14@proton.me