rfc9846v1.txt   rfc9846.txt 
Internet Engineering Task Force (IETF) E. Rescorla Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 9846 Independent Request for Comments: 9846 Independent
Obsoletes: 8446 January 2026 Obsoletes: 8446 May 2026
Updates: 5705, 6066, 7627, 8422 Updates: 5705, 6066, 7627, 8422
Category: Standards Track Category: Standards Track
ISSN: 2070-1721 ISSN: 2070-1721
The Transport Layer Security (TLS) Protocol Version 1.3 The Transport Layer Security (TLS) Protocol Version 1.3
Abstract Abstract
This document specifies version 1.3 of the Transport Layer Security This document specifies version 1.3 of the Transport Layer Security
(TLS) protocol. TLS allows client/server applications to communicate (TLS) protocol. TLS allows client/server applications to communicate
skipping to change at line 1535 skipping to change at line 1535
| server_certificate_type [RFC7250] | CH, EE | | server_certificate_type [RFC7250] | CH, EE |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| padding [RFC7685] | CH | | padding [RFC7685] | CH |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| cached_info [RFC7924] | CH, EE | | cached_info [RFC7924] | CH, EE |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| compress_certificate [RFC8879] | CH, CR | | compress_certificate [RFC8879] | CH, CR |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| record_size_limit [RFC8449] | CH, EE | | record_size_limit [RFC8449] | CH, EE |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| delegated_credentials [RFC9345] | CH, CR, CT | | delegated_credential [RFC9345] | CH, CR, CT |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| supported_ekt_ciphers [RFC8870] | CH, EE | | supported_ekt_ciphers [RFC8870] | CH, EE |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| pre_shared_key [RFC8446] | CH, SH | | pre_shared_key [RFC8446] | CH, SH |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| early_data [RFC8446] | CH, EE, NST | | early_data [RFC8446] | CH, EE, NST |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| psk_key_exchange_modes [RFC8446] | CH | | psk_key_exchange_modes [RFC8446] | CH |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| cookie [RFC8446] | CH, HRR | | cookie [RFC8446] | CH, HRR |
skipping to change at line 1684 skipping to change at line 1684
struct { struct {
opaque cookie<1..2^16-1>; opaque cookie<1..2^16-1>;
} Cookie; } Cookie;
Cookies serve two primary purposes: Cookies serve two primary purposes:
* Allowing the server to force the client to demonstrate * Allowing the server to force the client to demonstrate
reachability at their apparent network address (thus providing a reachability at their apparent network address (thus providing a
measure of DoS protection). This is primarily useful for non- measure of DoS protection). This is primarily useful for non-
connection-oriented transports (see [RFC6347] for an example of connection-oriented transports (see [RFC9147] for an example of
this). this).
* Allowing the server to offload state to the client, thus allowing * Allowing the server to offload state to the client, thus allowing
it to send a HelloRetryRequest without storing any state. The it to send a HelloRetryRequest without storing any state. The
server can do this by storing the hash of the ClientHello in the server can do this by storing the hash of the ClientHello in the
HelloRetryRequest cookie (protected with some suitable integrity HelloRetryRequest cookie (protected with some suitable integrity
protection algorithm). protection algorithm).
When sending a HelloRetryRequest, the server MAY provide a "cookie" When sending a HelloRetryRequest, the server MAY provide a "cookie"
extension to the client (this is an exception to the usual rule that extension to the client (this is an exception to the usual rule that
skipping to change at line 3352 skipping to change at line 3352
chance of a joint key/IV collision is much lower. To provide an chance of a joint key/IV collision is much lower. To provide an
extra margin of security, sending implementations MUST NOT allow the extra margin of security, sending implementations MUST NOT allow the
epoch -- and hence the number of key updates -- to exceed 2^48-1. In epoch -- and hence the number of key updates -- to exceed 2^48-1. In
order to allow this value to be changed later -- for instance for order to allow this value to be changed later -- for instance for
ciphers with more than 128-bit keys -- receiving implementations MUST ciphers with more than 128-bit keys -- receiving implementations MUST
NOT enforce this rule. If a sending implementation receives a NOT enforce this rule. If a sending implementation receives a
KeyUpdate with request_update set to "update_requested", it MUST NOT KeyUpdate with request_update set to "update_requested", it MUST NOT
send its own KeyUpdate if that would cause it to exceed these limits send its own KeyUpdate if that would cause it to exceed these limits
and SHOULD instead ignore the "update_requested" flag. This may and SHOULD instead ignore the "update_requested" flag. This may
result in an eventual need to terminate the connection when the result in an eventual need to terminate the connection when the
limits described in Section 5.5 are reached. limits in Section 5.5 are reached.
5. Record Protocol 5. Record Protocol
The TLS record protocol takes messages to be transmitted, fragments The TLS record protocol takes messages to be transmitted, fragments
the data into manageable blocks, protects the records, and transmits the data into manageable blocks, protects the records, and transmits
the result. Received data is verified, decrypted, reassembled, and the result. Received data is verified, decrypted, reassembled, and
then delivered to higher-level clients. then delivered to higher-level clients.
TLS records are typed, which allows multiple higher-level protocols TLS records are typed, which allows multiple higher-level protocols
to be multiplexed over the same record layer. This document to be multiplexed over the same record layer. This document
skipping to change at line 4484 skipping to change at line 4484
received. After early data is accepted, records may continue to be received. After early data is accepted, records may continue to be
streamed to the server over a longer time period. streamed to the server over a longer time period.
9. Compliance Requirements 9. Compliance Requirements
9.1. Mandatory-to-Implement Cipher Suites 9.1. Mandatory-to-Implement Cipher Suites
In the absence of an application profile standard specifying In the absence of an application profile standard specifying
otherwise: otherwise:
A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 * A TLS-compliant application MUST implement the
[GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the
[GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256
Appendix B.4). [RFC8439] cipher suites (see Appendix B.4).
A TLS-compliant application MUST support digital signatures with * A TLS-compliant application MUST support digital signatures with
rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for
CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A CertificateVerify and certificates), and ecdsa_secp256r1_sha256.
TLS-compliant application MUST support key exchange with secp256r1 A TLS-compliant application MUST support key exchange with
(NIST P-256) and SHOULD support key exchange with X25519 [RFC7748]. secp256r1 (NIST P-256) and SHOULD support key exchange with X25519
[RFC7748].
9.2. Mandatory-to-Implement Extensions 9.2. Mandatory-to-Implement Extensions
In the absence of an application profile standard specifying In the absence of an application profile standard specifying
otherwise, a TLS-compliant application MUST implement the following otherwise, a TLS-compliant application MUST implement the following
TLS extensions: TLS extensions:
* Supported Versions ("supported_versions"; Section 4.2.1) * Supported Versions ("supported_versions"; Section 4.2.1)
* Cookie ("cookie"; Section 4.2.2) * Cookie ("cookie"; Section 4.2.2)
skipping to change at line 5094 skipping to change at line 5095
DOI 10.1109/sp.2016.36, May 2016, DOI 10.1109/sp.2016.36, May 2016,
<https://doi.org/10.1109/sp.2016.36>. <https://doi.org/10.1109/sp.2016.36>.
[Mac17] MacCarthaigh, C., "Security Review of TLS1.3 0-RTT", May [Mac17] MacCarthaigh, C., "Security Review of TLS1.3 0-RTT", May
2017, <https://github.com/tlswg/tls13-spec/issues/1001>. 2017, <https://github.com/tlswg/tls13-spec/issues/1001>.
[MM24] Moustafa, M., Sethi, M., and T. Aura, "Misbinding Raw [MM24] Moustafa, M., Sethi, M., and T. Aura, "Misbinding Raw
Public Keys to Identities in TLS", arxiv:2411.09770, 29 Public Keys to Identities in TLS", arxiv:2411.09770, 29
September 2025, <https://arxiv.org/pdf/2411.09770>. September 2025, <https://arxiv.org/pdf/2411.09770>.
[PRE-RFC9849]
Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", RFC PRE-RFC9849,
DOI 10.17487/preRFC9849, December 2025,
<https://www.rfc-editor.org/info/rfc9849>.
[PS18] Patton, C. and T. Shrimpton, "Partially specified [PS18] Patton, C. and T. Shrimpton, "Partially specified
channels: The TLS 1.3 record layer without elision", 2018, channels: The TLS 1.3 record layer without elision", 2018,
<https://eprint.iacr.org/2018/634>. <https://eprint.iacr.org/2018/634>.
[PSK-FINISHED] [PSK-FINISHED]
Cremers, C., Horvat, M., van der Merwe, T., and S. Scott, Cremers, C., Horvat, M., van der Merwe, T., and S. Scott,
"Revision 10: possible attack if client authentication is "Revision 10: possible attack if client authentication is
allowed during PSK", message to the TLS mailing list, 31 allowed during PSK", message to the TLS mailing list, 31
October 2015, <https://mailarchive.ietf.org/arch/msg/tls/ October 2015, <https://mailarchive.ietf.org/arch/msg/tls/
TugB5ddJu3nYg7chcyeIyUqWSbA/>. TugB5ddJu3nYg7chcyeIyUqWSbA/>.
skipping to change at line 5199 skipping to change at line 5194
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure
Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
DOI 10.17487/RFC6101, August 2011, DOI 10.17487/RFC6101, August 2011,
<https://www.rfc-editor.org/info/rfc6101>. <https://www.rfc-editor.org/info/rfc6101>.
[RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer
(SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March
2011, <https://www.rfc-editor.org/info/rfc6176>. 2011, <https://www.rfc-editor.org/info/rfc6176>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport
Layer Security (TLS) and Datagram Transport Layer Security Layer Security (TLS) and Datagram Transport Layer Security
(DTLS) Heartbeat Extension", RFC 6520, (DTLS) Heartbeat Extension", RFC 6520,
DOI 10.17487/RFC6520, February 2012, DOI 10.17487/RFC6520, February 2012,
<https://www.rfc-editor.org/info/rfc6520>. <https://www.rfc-editor.org/info/rfc6520>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
skipping to change at line 5336 skipping to change at line 5327
[RFC9345] Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, [RFC9345] Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
"Delegated Credentials for TLS and DTLS", RFC 9345, "Delegated Credentials for TLS and DTLS", RFC 9345,
DOI 10.17487/RFC9345, July 2023, DOI 10.17487/RFC9345, July 2023,
<https://www.rfc-editor.org/info/rfc9345>. <https://www.rfc-editor.org/info/rfc9345>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023, RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>. <https://www.rfc-editor.org/info/rfc9525>.
[RFC9849] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", RFC 9849, DOI 10.17487/RFC9849,
March 2026, <https://www.rfc-editor.org/info/rfc9849>.
[RSA] Rivest, R., Shamir, A., and L. Adleman, "A method for [RSA] Rivest, R., Shamir, A., and L. Adleman, "A method for
obtaining digital signatures and public-key obtaining digital signatures and public-key
cryptosystems", Association for Computing Machinery (ACM), cryptosystems", Association for Computing Machinery (ACM),
Communications of the ACM vol. 21, no. 2, pp. 120-126, Communications of the ACM vol. 21, no. 2, pp. 120-126,
DOI 10.1145/359340.359342, February 1978, DOI 10.1145/359340.359342, February 1978,
<https://doi.org/10.1145/359340.359342>. <https://doi.org/10.1145/359340.359342>.
[Selfie] Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3 [Selfie] Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3
with PSK", 2019, <https://eprint.iacr.org/2019/347>. with PSK", 2019, <https://eprint.iacr.org/2019/347>.
skipping to change at line 6120 skipping to change at line 6115
connections. connections.
It is RECOMMENDED that the labels for external identities be selected It is RECOMMENDED that the labels for external identities be selected
so that they do not provide additional information about the identity so that they do not provide additional information about the identity
of the user. For instance, if the label includes an email address, of the user. For instance, if the label includes an email address,
then this trivially identifies the user to a passive attacker, unlike then this trivially identifies the user to a passive attacker, unlike
the client's Certificate, which is encrypted. There are a number of the client's Certificate, which is encrypted. There are a number of
potential ways to avoid this risk, including (1) using random potential ways to avoid this risk, including (1) using random
identity labels, (2) pre-encrypting the identity under a key known to identity labels, (2) pre-encrypting the identity under a key known to
the server, or (3) using the Encrypted Client Hello extension the server, or (3) using the Encrypted Client Hello extension
[PRE-RFC9849]. [RFC9849].
If an external PSK identity is used for multiple connections, then it If an external PSK identity is used for multiple connections, then it
will generally be possible for an external observer to track clients will generally be possible for an external observer to track clients
and/or servers across connections. Use of the Encrypted Client Hello and/or servers across connections. Use of the Encrypted Client Hello
extension [PRE-RFC9849] can mitigate this risk, as can mechanisms extension [RFC9849] can mitigate this risk, as can mechanisms
external to TLS that rotate or encrypt the PSK identity. external to TLS that rotate or encrypt the PSK identity.
C.5. Unauthenticated Operation C.5. Unauthenticated Operation
Previous versions of TLS offered explicitly unauthenticated cipher Previous versions of TLS offered explicitly unauthenticated cipher
suites based on anonymous Diffie-Hellman. These modes have been suites based on anonymous Diffie-Hellman. These modes have been
deprecated in TLS 1.3. However, it is still possible to negotiate deprecated in TLS 1.3. However, it is still possible to negotiate
parameters that do not provide verifiable server authentication by parameters that do not provide verifiable server authentication by
several methods, including: several methods, including:
 End of changes. 11 change blocks. 
25 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.48.