rfc9852v1.txt		rfc9852.txt
	skipping to change at line 14 ¶		skipping to change at line 14 ¶
	BCP: 195 N. Aviram		BCP: 195 N. Aviram
	Updates: 9325 January 2026		Updates: 9325 January 2026
	Category: Best Current Practice		Category: Best Current Practice
	ISSN: 2070-1721		ISSN: 2070-1721
	New Protocols Using TLS Must Require TLS 1.3		New Protocols Using TLS Must Require TLS 1.3
	Abstract		Abstract
	TLS 1.3 is widely used, has had comprehensive security proofs, and		TLS 1.3 is widely used, has had comprehensive security proofs, and
	improves both security and privacy over TLS 1.2. Therefore, new		improves both security and privacy deficiencies in TLS 1.2.
	protocols that use TLS must require TLS 1.3. As DTLS 1.3 is not		Therefore, new protocols that use TLS must require TLS 1.3. As DTLS
	widely available or deployed, this prescription does not pertain to		1.3 is not widely available or deployed, this prescription does not
	DTLS (in any DTLS version); it pertains to TLS only.		pertain to DTLS (in any DTLS version); it pertains to TLS only.
	This document updates RFC 9325. It discusses post-quantum		This document updates RFC 9325. It discusses post-quantum
	cryptography and the security and privacy improvements over TLS 1.2		cryptography and the security and privacy improvements in TLS 1.3 as
	as the rationale for the update.		the rationale for the update.
	Status of This Memo		Status of This Memo
	This memo documents an Internet Best Current Practice.		This memo documents an Internet Best Current Practice.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	BCPs is available in Section 2 of RFC 7841.		BCPs is available in Section 2 of RFC 7841.
	skipping to change at line 68 ¶		skipping to change at line 68 ¶
	5. Changes to RFC 9325		5. Changes to RFC 9325
	6. Security Considerations		6. Security Considerations
	7. IANA Considerations		7. IANA Considerations
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	8.2. Informative References		8.2. Informative References
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	This document specifies that, since TLS 1.3 use is widespread, new		This document specifies that new protocols that use TLS must assume
	protocols that use TLS must require and assume its existence. It		that TLS 1.3 is available and require its use. As DTLS 1.3 is not
	updates [RFC9325] as described in Section 5. As DTLS 1.3 is not
	widely available or deployed, this prescription does not pertain to		widely available or deployed, this prescription does not pertain to
	DTLS (in any DTLS version); it pertains to TLS only.		DTLS (in any DTLS version); it pertains to TLS only.
	TLS 1.3 [TLS13] is in widespread use and fixes most known		TLS 1.3 [TLS13] is in widespread use and fixes most known
	deficiencies with TLS 1.2. Examples of this include encrypting more		deficiencies with TLS 1.2. Examples of this include encrypting more
	of the traffic so that it is not readable by outsiders and removing		of the traffic so that it is not readable by outsiders and removing
	most cryptographic primitives now considered weak. Importantly, the		most cryptographic primitives now considered weak. Importantly, the
	protocol has had comprehensive security proofs and should provide		protocol has had comprehensive security proofs and should provide
	excellent security without any additional configuration.		excellent security without any additional configuration.
	TLS 1.2 [TLS12] is in use and can be configured such that it provides		TLS 1.2 [TLS12] is in use and can be configured such that it provides
	good security properties. However, TLS 1.2 suffers from several		good security properties. However, TLS 1.2 suffers from several
	deficiencies, as described in Section 6. Addressing them usually		deficiencies, as described in Section 6. Addressing them usually
	requires bespoke configuration.		requires bespoke configuration.
	This document updates [RFC9325]. It discusses post-quantum		This document updates [RFC9325]. It discusses post-quantum
	cryptography and the fixed weaknesses in TLS 1.2 as a rationale for		cryptography and the security and privacy improvements in TLS 1.3 as
	the update.		the rationale for the update. See Section 5.
	2. Conventions		2. Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Implications for Post-Quantum Cryptography (PQC)		3. Implications for Post-Quantum Cryptography (PQC)
	Cryptographically Relevant Quantum Computers (CRQCs), once available,		Cryptographically Relevant Quantum Computers (CRQCs), once available,
	will have a huge impact on TLS traffic (see, e.g., Section 2 of		will have a huge impact on TLS traffic (see, e.g., Section 2 of
	[PQC-FOR-ENGINEERS]). To mitigate this, TLS applications will need		[PQC-FOR-ENGINEERS]). To mitigate this, TLS applications will need
	to migrate to Post-Quantum Cryptography (PQC) [PQC]. Detailed		to migrate to Post-Quantum Cryptography (PQC) [PQC]. Detailed
	considerations of when an application requires PQC or when a CRQC is		considerations of when an application requires PQC or when a CRQC is
	a threat that an application needs to protect against are beyond the		a threat that an application needs to protect against are beyond the
	scope of this document.		scope of this document.
	For TLS, it is important to note that the focus of these efforts		It is important to note that the TLS Working Group is focusing its
	within the TLS Working Group is TLS 1.3 or later; TLS 1.2 will not be		efforts on TLS 1.3 or later; TLS 1.2 will not be supported (see
	supported (see [TLS12FROZEN]). This is one more reason for new		[TLS12FROZEN]). This is one more reason for new protocols to require
	protocols to require TLS to default to TLS 1.3, where PQC is actively		TLS to default to TLS 1.3, where PQC is actively being standardized,
	being standardized, as this gives new applications the option to use		as this gives new applications the option to use PQC.
	PQC.
	4. TLS Use by Other Protocols and Applications		4. TLS Use by Other Protocols and Applications
	Any new protocol that uses TLS MUST specify TLS 1.3 as its default.		Any new protocol that uses TLS MUST specify TLS 1.3 as its default.
	For example, QUIC [QUICTLS] requires TLS 1.3 and specifies that		For example, QUIC [QUICTLS] requires TLS 1.3 and specifies that
	endpoints MUST terminate the connection if an older version is used.		endpoints MUST terminate the connection if an older version is used.
	If deployment considerations are a concern, the protocol MAY specify		If deployment considerations are a concern, the protocol MAY specify
	TLS 1.2 as an additional, non-default option. As a counter example,		TLS 1.2 as an additional, non-default option. As a counter example,
	the Usage Profile for DNS over TLS [DNSTLS] specifies TLS 1.2 as the		the Usage Profile for DNS over TLS [DNSTLS] specifies TLS 1.2 as the
	skipping to change at line 136 ¶		skipping to change at line 134 ¶
	The initial TLS handshake allows a client to specify which versions		The initial TLS handshake allows a client to specify which versions
	of TLS it supports, and the server is intended to pick the highest		of TLS it supports, and the server is intended to pick the highest
	version that it also supports. This is known as "TLS version		version that it also supports. This is known as "TLS version
	negotiation"; protocol and negotiation details are discussed in		negotiation"; protocol and negotiation details are discussed in
	Section 4.2.1 of [TLS13] and Appendix E of [TLS12]. Many TLS		Section 4.2.1 of [TLS13] and Appendix E of [TLS12]. Many TLS
	libraries provide a way for applications to specify the range of		libraries provide a way for applications to specify the range of
	versions they want, including an open interval where only the lowest		versions they want, including an open interval where only the lowest
	or highest version is specified.		or highest version is specified.
	If the application is using a TLS implementation that supports this		If the application is using a TLS implementation that supports TLS
	and if it knows that the TLS implementation will use the highest		version negotiation and if it knows that the TLS implementation will
	version supported, then clients SHOULD specify just the minimum		use the highest version supported, then clients SHOULD specify just
	version they want. This MUST be TLS 1.3 or TLS 1.2, depending on the		the minimum version they want. This MUST be TLS 1.3 or TLS 1.2,
	circumstances described in the above paragraphs.		depending on the circumstances described in the above paragraphs.
	5. Changes to RFC 9325		5. Changes to RFC 9325
	[RFC9325] provides recommendations for ensuring the security of		[RFC9325] provides recommendations for ensuring the security of
	deployed services that use TLS and, unlike this document, DTLS as		deployed services that use TLS and, unlike this document, DTLS as
	well. [RFC9325] describes availability of TLS 1.3 as "widely		well. [RFC9325] describes TLS 1.3 as "widely available", and the
	available" at the time of its publication. The transition and		transition to TLS 1.3 has further increased since publication of that
	adoption mentioned in that document has grown, and this document now		document. This document thus makes two changes to the
	makes two changes to the recommendations in Section 3.1.1 of		recommendations in Section 3.1.1 of [RFC9325]:
	[RFC9325]:
	* That section says that TLS 1.3 SHOULD be supported; this document		* That section says that TLS 1.3 SHOULD be supported; this document
	mandates that TLS 1.3 MUST be supported for new protocols using		mandates that TLS 1.3 MUST be supported for new protocols using
	TLS.		TLS.
	* That section says that TLS 1.2 MUST be supported; this document		* That section says that TLS 1.2 MUST be supported; this document
	says that TLS 1.2 MAY be supported as described above.		says that TLS 1.2 MAY be supported as described above.
	Again, these changes only apply to TLS, and not DTLS.		Again, these changes only apply to TLS, and not DTLS.
	skipping to change at line 177 ¶		skipping to change at line 174 ¶
	noted, however, that TLS 1.2 can be configured securely; it is merely		noted, however, that TLS 1.2 can be configured securely; it is merely
	much more difficult to configure it securely as opposed to using its		much more difficult to configure it securely as opposed to using its
	modern successor, TLS 1.3. See [RFC9325] for a more thorough guide		modern successor, TLS 1.3. See [RFC9325] for a more thorough guide
	on the secure deployment of TLS 1.2.		on the secure deployment of TLS 1.2.
	First, without any extensions, TLS 1.2 is vulnerable to renegotiation		First, without any extensions, TLS 1.2 is vulnerable to renegotiation
	attacks (see [RENEG1] and [RENEG2]) and the Triple Handshake attack		attacks (see [RENEG1] and [RENEG2]) and the Triple Handshake attack
	(see [TRIPLESHAKE]). Broadly, these attacks exploit the protocol's		(see [TRIPLESHAKE]). Broadly, these attacks exploit the protocol's
	support for renegotiation in order to inject a prefix chosen by the		support for renegotiation in order to inject a prefix chosen by the
	attacker into the plaintext stream. This is usually a devastating		attacker into the plaintext stream. This is usually a devastating
	threat in practice that allows, e.g., obtaining secret cookies in a		threat in practice (e.g., it allows an attacker to obtain secret
	web setting. In light of the above problems, [RFC5746] specifies an		cookies in a web setting). In light of the above problems, [RFC5746]
	extension that prevents this category of attacks. To securely deploy		specifies an extension that prevents this category of attacks. To
	TLS 1.2, either renegotiation must be disabled entirely, or this		securely deploy TLS 1.2, either renegotiation must be disabled
	extension must be used. Additionally, clients must not allow servers		entirely, or this extension must be used. Additionally, clients must
	to renegotiate the certificate during a connection.		not allow servers to renegotiate the certificate during a connection.
	Second, the original key exchange methods specified for the protocol,		Second, the original key exchange methods specified for TLS 1.2,
	namely RSA key exchange and finite field Diffie-Hellman, suffer from		namely RSA key exchange and finite field Diffie-Hellman, suffer from
	several weaknesses. To securely deploy the protocol, most of these		several weaknesses. To securely deploy the protocol, most of these
	key exchange methods must be disabled. See [KEY-EXCHANGE] for		key exchange methods must be disabled. See [KEY-EXCHANGE] for
	details.		details.
	Third, symmetric ciphers that are widely used in the protocol, namely		Third, symmetric ciphers that are widely used in TLS 1.2, namely RC4
	RC4 and Cipher Block Chaining (CBC) cipher suites, suffer from		and Cipher Block Chaining (CBC) cipher suites, suffer from several
	several weaknesses. RC4 suffers from exploitable biases in its key		weaknesses. RC4 suffers from exploitable biases in its key stream;
	stream; see [RFC7465]. CBC cipher suites have been a source of		see [RFC7465]. CBC cipher suites have been a source of
	vulnerabilities throughout the years. A straightforward		vulnerabilities throughout the years. A straightforward
	implementation of these cipher suites inherently suffers from the		implementation of these cipher suites inherently suffers from the
	Lucky13 timing attack [LUCKY13]. The first attempt to implement the		Lucky13 timing attack [LUCKY13]. The first attempt to implement the
	cipher suites in constant time introduced an even more severe		cipher suites in constant time introduced an even more severe
	vulnerability [LUCKY13FIX]. There have been further similar		vulnerability [LUCKY13FIX]. Refer to [CBCSCANNING] for another
	vulnerabilities throughout the years exploiting CBC cipher suites;		example of a vulnerability with CBC cipher suites and a survey of
	refer to [CBCSCANNING] for an example and a survey of similar works.		similar works.
	In addition, TLS 1.2 was affected by several other attacks that TLS		In addition, TLS 1.2 was affected by several other attacks that TLS
	1.3 is immune to: BEAST [BEAST], Logjam [WEAKDH], FREAK [FREAK], and		1.3 is immune to: BEAST [BEAST], Logjam [WEAKDH], FREAK [FREAK], and
	SLOTH [SLOTH].		SLOTH [SLOTH].
	Finally, while application-layer traffic is always encrypted, most of		Finally, while application-layer traffic in TLS 1.2 is always
	the handshake messages are not. Therefore, the privacy provided is		encrypted, most of the content of the handshake messages is not.
	suboptimal. This is a protocol issue that cannot be addressed by		Therefore, the privacy provided is suboptimal. This is a protocol
	configuration.		issue that cannot be addressed by configuration.
	7. IANA Considerations		7. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
End of changes. 12 change blocks.
	45 lines changed or deleted		42 lines changed or added
This html diff was produced by rfcdiff 1.48.