rfc9852.original.xml   rfc9852.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.27 (Ruby 3.3. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
6) --> -ietf-uta-require-tls13-12" number="9852" category="bcp" consensus="true" submis
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft sionType="IETF" updates="9325" obsoletes="" tocInclude="true" sortRefs="true" sy
-ietf-uta-require-tls13-12" category="bcp" consensus="true" submissionType="IETF mRefs="true" version="3" xml:lang="en">
" updates="9325" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.28.1 -->
<front> <front>
<title abbrev="require-tls1.3">New Protocols Using TLS Must Require TLS 1.3< <title abbrev="New Protocols Using TLS Must Require TLS 1.3">New Protocols U
/title> sing TLS Must Require TLS 1.3</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-uta-require-tls13-12"/> <seriesInfo name="RFC" value="9852"/>
<seriesInfo name="BCP" value="195"/>
<author fullname="Rich Salz"> <author fullname="Rich Salz">
<organization>Akamai Technologies</organization> <organization>Akamai Technologies</organization>
<address> <address>
<email>rsalz@akamai.com</email> <email>rsalz@akamai.com</email>
</address> </address>
</author> </author>
<author fullname="Nimrod Aviram"> <author fullname="Nimrod Aviram">
<organization/> <organization/>
<address> <address>
<email>nimrod.aviram@gmail.com</email> <email>nimrod.aviram@gmail.com</email>
</address> </address>
</author> </author>
<date year="2025" month="April" day="14"/> <date year="2026" month="January"/>
<area>Security</area> <area>Security</area>
<workgroup>Using TLS in Applications</workgroup> <workgroup>Using TLS in Applications</workgroup>
<keyword>TLS</keyword> <keyword>TLS</keyword>
<keyword>TLS Transition</keyword> <keyword>TLS Transition</keyword>
<keyword>TLS Support</keyword> <keyword>TLS Support</keyword>
<keyword>Interoperability</keyword> <keyword>Interoperability</keyword>
<keyword>features</keyword> <keyword>features</keyword>
<abstract> <abstract>
<?line 123?>
<t>TLS 1.3 use is widespread, it has had comprehensive security proofs, and it <t>TLS 1.3 is widely used, has had comprehensive security proofs, and
improves both security and privacy over TLS 1.2. Therefore, new protocols improves both security and privacy deficiencies in TLS 1.2. Therefore, new prot
ocols
that use TLS must require TLS 1.3. As DTLS 1.3 is not widely available or that use TLS must require TLS 1.3. As DTLS 1.3 is not widely available or
deployed, this prescription does not pertain to DTLS (in any DTLS version); deployed, this prescription does not pertain to DTLS (in any DTLS version);
it pertains to TLS only.</t> it pertains to TLS only.</t>
<t>This document updates RFC9325 and discusses post-quantum cryptography a <t>This document updates RFC 9325. It discusses post-quantum cryptography
nd the and the
security and privacy improvements over TLS 1.2 as a rationale for that update.</ security and privacy improvements in TLS 1.3 as the rationale for the update.</t
t> >
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-uta-require-tls13/"/>.
</t>
<t>
Discussion of this document takes place on the
Using TLS in Applications Working Group mailing list (<eref target="mail
to:uta@ietf.org"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/uta/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/uta/"/>
.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/richsalz/draft-use-tls13"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 134?>
<section anchor="sec-reasons"> <section anchor="sec-reasons">
<name>Introduction</name> <name>Introduction</name>
<t>This document specifies that, since TLS 1.3 use is widespread, new prot
ocols <t>This document specifies that new protocols
that use TLS must require and assume its existence. It updates <xref target="RF that use TLS must assume that TLS 1.3 is available and require its use.
C9325"/> As DTLS 1.3 is not widely available or
as described in <xref target="rfc9325-updates"/>. As DTLS 1.3 is not widely ava
ilable or
deployed, this prescription does not pertain to DTLS (in any DTLS version); deployed, this prescription does not pertain to DTLS (in any DTLS version);
it pertains to TLS only.</t> it pertains to TLS only.</t>
<t>TLS 1.3 <xref target="TLS13"/> is in widespread use and fixes most know n deficiencies with <t>TLS 1.3 <xref target="RFC9846"/> is in widespread use and fixes most kn own deficiencies with
TLS 1.2. Examples of this include encrypting more of the traffic so that it TLS 1.2. Examples of this include encrypting more of the traffic so that it
is not readable by outsiders and removing most cryptographic primitives is not readable by outsiders and removing most cryptographic primitives
now considered weak. Importantly, the protocol has had comprehensive now considered weak. Importantly, the protocol has had comprehensive
security proofs and should provide excellent security without any additional security proofs and should provide excellent security without any additional
configuration.</t> configuration.</t>
<t>TLS 1.2 <xref target="TLS12"/> is in use and can be configured such tha t it provides good <t>TLS 1.2 <xref target="RFC5246"/> is in use and can be configured such t hat it provides good
security properties. However, TLS 1.2 suffers from several deficiencies, as security properties. However, TLS 1.2 suffers from several deficiencies, as
described in <xref target="sec-considerations"/>. Addressing them usually requi res described in <xref target="sec-considerations"/>. Addressing them usually requi res
bespoke configuration.</t> bespoke configuration.</t>
<t>This document updates RFC9325 and discusses post-quantum cryptography
and fixed weaknesses in TLS 1.2 as a rationale for that update.</t>
</section>
<section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i
nterpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
only when, they
appear in all capitals, as shown here.</t>
<?line -18?>
</section> <t>This document updates <xref target="RFC9325"/>. It discusses post-quant
um cryptography
and the security and privacy improvements in TLS 1.3 as the rationale for the up
date. See <xref target="rfc9325-updates"/>.</t>
</section>
<section anchor="conventions">
<name>Conventions</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section anchor="implications-for-post-quantum-cryptography-pqc"> <section anchor="implications-for-post-quantum-cryptography-pqc">
<name>Implications for post-quantum cryptography (PQC)</name> <name>Implications for Post-Quantum Cryptography (PQC)</name>
<t>Cryptographically-relevant quantum computers (CRQC), once available, wi <t>Cryptographically Relevant Quantum Computers (CRQCs), once available, w
ll ill
have a huge impact on TLS traffic (see, e.g., <xref section="2" sectionFormat="o f" target="I-D.ietf-pquip-pqc-engineers"/>). To mitigate this, TLS applications will have a huge impact on TLS traffic (see, e.g., <xref section="2" sectionFormat="o f" target="I-D.ietf-pquip-pqc-engineers"/>). To mitigate this, TLS applications will
need to migrate to Post-Quantum Cryptography (PQC) <xref target="PQC"/>. Detail ed need to migrate to Post-Quantum Cryptography (PQC) <xref target="PQC"/>. Detail ed
considerations of when an application requires PQC or when a CRQC is a threat considerations of when an application requires PQC or when a CRQC is a threat
that an application need to protect against, are beyond the scope of this that an application needs to protect against are beyond the scope of this
document.</t> document.</t>
<t>For TLS it is important to note that the focus of these efforts within
the TLS WG is TLS 1.3 <t>It is important to note that the
or later, and that TLS 1.2 will not be supported (see <xref target="TLS12FROZEN" TLS Working Group is focusing its efforts on TLS 1.3
/>). or later; TLS 1.2 will not be supported (see <xref target="RFC9851"/>).
This is one more reason for new protocols require TLS to default to TLS 1.3, This is one more reason for new protocols to require TLS to default to TLS 1.3,
where where
PQC is actively being standardized, as this gives new applications PQC is actively being standardized, as this gives new applications
the option to use PQC.</t> the option to use PQC.</t>
</section> </section>
<section anchor="tls-use-by-other-protocols-and-applications"> <section anchor="tls-use-by-other-protocols-and-applications">
<name>TLS Use by Other Protocols and Applications</name> <name>TLS Use by Other Protocols and Applications</name>
<t>Any new protocol that uses TLS <bcp14>MUST</bcp14> specify as its defau <t>Any new protocol that uses TLS <bcp14>MUST</bcp14> specify TLS 1.3 as i
lt TLS 1.3. ts default.
For example, QUIC <xref target="QUICTLS"/> requires TLS 1.3 and specifies that e For example, QUIC <xref target="RFC9001"/> requires TLS 1.3 and specifies that e
ndpoints ndpoints
<bcp14>MUST</bcp14> terminate the connection if an older version is used.</t> <bcp14>MUST</bcp14> terminate the connection if an older version is used.</t>
<t>If deployment considerations are a concern, the protocol <bcp14>MAY</bc p14> specify TLS 1.2 as <t>If deployment considerations are a concern, the protocol <bcp14>MAY</bc p14> specify TLS 1.2 as
an additional, non-default option. an additional, non-default option.
As a counter example, the Usage Profile for DNS over TLS <xref target="DNSTLS"/> specifies As a counter example, the Usage Profile for DNS over TLS <xref target="RFC8310"/ > specifies
TLS 1.2 as the default, while also allowing TLS 1.3. TLS 1.2 as the default, while also allowing TLS 1.3.
For newer specifications that choose to support TLS 1.2, those preferences are For newer specifications that choose to support TLS 1.2, those preferences are
to be reversed.</t> to be reversed.</t>
<t>The initial TLS handshake allows a client to specify which versions of
the <t>The initial TLS handshake allows a client to specify which versions of
TLS protocol it supports and the server is intended to pick the highest TLS it supports, and the server is intended to pick the highest
version that it also supports. This is known as the "TLS version version that it also supports. This is known as "TLS version
negotiation," and protocol and negotiation details are discussed in <xref sectio negotiation"; protocol and negotiation details are discussed in <xref section="4
n="4.2.1" sectionFormat="comma" target="TLS13"/> and <xref section="E" sectionFo .2.1" sectionFormat="of" target="RFC9846"/> and <xref section="E" sectionFormat=
rmat="comma" target="TLS12"/>. Many TLS libraries provide a way "of" target="RFC5246"/>. Many TLS libraries provide a way
for applications to specify the range of versions they want, including an for applications to specify the range of versions they want, including an
open interval where only the lowest or highest version is specified.</t> open interval where only the lowest or highest version is specified.</t>
<t>If the application is using a TLS implementation that supports this,
<t>If the application is using a TLS implementation that supports TLS vers
ion negotiation
and if it knows that the TLS implementation will use the highest version and if it knows that the TLS implementation will use the highest version
supported, then supported, then
clients <bcp14>SHOULD</bcp14> specify just the minimum version they want. clients <bcp14>SHOULD</bcp14> specify just the minimum version they want.
This <bcp14>MUST</bcp14> be TLS 1.3 or TLS 1.2, depending on the circumstances d escribed This <bcp14>MUST</bcp14> be TLS 1.3 or TLS 1.2, depending on the circumstances d escribed
in the above paragraphs.</t> in the above paragraphs.</t>
</section> </section>
<section anchor="rfc9325-updates"> <section anchor="rfc9325-updates">
<name>Changes to RFC 9325</name> <name>Changes to RFC 9325</name>
<t><xref target="RFC9325"/> provides recommendations for ensuring the secu rity of deployed <t><xref target="RFC9325"/> provides recommendations for ensuring the secu rity of deployed
services that use TLS and, unlike this document, DTLS as well. services that use TLS and, unlike this document, DTLS as well.
At the time it was published, it described availability of TLS 1.3 <xref target="RFC9325"/> describes TLS 1.3
as "widely available." The transition and adoption mentioned in that as "widely available", and the transition to TLS 1.3 has further increased since
document has grown, and this document now makes two changes publication of that document.
to the recommendations in <xref section="3.1.1" sectionFormat="comma" target="RF This document thus makes two changes
C9325"/>:</t> to the recommendations in <xref section="3.1.1" sectionFormat="of" target="RFC93
25"/>:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>That section says that TLS 1.3 <bcp14>SHOULD</bcp14> be supported; this document mandates <t>That section says that TLS 1.3 <bcp14>SHOULD</bcp14> be supported; this document mandates
that TLS 1.3 <bcp14>MUST</bcp14> be supported for new TLS-using protocols.</t> that TLS 1.3 <bcp14>MUST</bcp14> be supported for new protocols using TLS.</t>
</li> </li>
<li> <li>
<t>That section says that TLS 1.2 <bcp14>MUST</bcp14> be supported; th is document says that <t>That section says that TLS 1.2 <bcp14>MUST</bcp14> be supported; th is document says that
TLS 1.2 <bcp14>MAY</bcp14> be supported as described above.</t> TLS 1.2 <bcp14>MAY</bcp14> be supported as described above.</t>
</li> </li>
</ul> </ul>
<t>Again, these changes only apply to TLS, and not DTLS.</t> <t>Again, these changes only apply to TLS, and not DTLS.</t>
</section> </section>
<section anchor="sec-considerations"> <section anchor="sec-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>TLS 1.2 was specified with several cryptographic primitives and design choices <t>TLS 1.2 was specified with several cryptographic primitives and design choices
that have, over time, become significantly weaker. The purpose of this section i s to that have, over time, become significantly weaker. The purpose of this section i s to
briefly survey several such prominent problems that have affected the protocol. briefly survey several such prominent problems that have affected the protocol.
It should be noted, however, that TLS 1.2 can be configured securely; it is It should be 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 merely much more difficult to configure it securely as opposed to using its
modern successor, TLS 1.3. See <xref target="RFC9325"/> for a more thorough guid e on the modern successor, TLS 1.3. See <xref target="RFC9325"/> for a more thorough guid e on the
secure deployment of TLS 1.2.</t> secure deployment of TLS 1.2.</t>
<t>Firstly, the TLS 1.2 protocol, without any extensions, is vulnerable to
<t>First, without any extensions, TLS 1.2 is vulnerable to
renegotiation attacks (see <xref target="RENEG1"/> and <xref target="RENEG2"/>) and the renegotiation attacks (see <xref target="RENEG1"/> and <xref target="RENEG2"/>) and the
Triple Handshake attack (see <xref target="TRIPLESHAKE"/>). Triple Handshake attack (see <xref target="TRIPLESHAKE"/>).
Broadly, these attacks Broadly, these attacks
exploit the protocol's support for renegotiation in order to inject a prefix exploit the protocol's support for renegotiation in order to inject a prefix
chosen by the attacker into the plaintext stream. This is usually a devastating chosen by the attacker into the plaintext stream. This is usually a devastating
threat in practice, that allows e.g. obtaining secret cookies in a web setting. threat in practice (e.g., it allows an attacker to obtain secret cookies in a we b setting).
In light of In light of
the above problems, <xref target="RFC5746"/> specifies an extension that prevent s this the above problems, <xref target="RFC5746"/> specifies an extension that prevent s this
category of attacks. To securely deploy TLS 1.2, either renegotiation must be category of attacks. To securely deploy TLS 1.2, either renegotiation must be
disabled entirely, or this extension must be used. Additionally, clients must disabled entirely, or this extension must be used. Additionally, clients must
not allow servers to renegotiate the certificate during a connection.</t> not allow servers to renegotiate the certificate during a connection.</t>
<t>Secondly, the original key exchange methods specified for the protocol,
namely <t>Second, the original key exchange methods specified for TLS 1.2, namely
RSA key exchange and finite field Diffie-Hellman, suffer from several RSA key exchange and finite field Diffie-Hellman, suffer from several
weaknesses. Similarly, to securely deploy the protocol, weaknesses. To securely deploy the protocol,
most of these key exchange most of these key exchange
methods must be disabled. methods must be disabled.
See <xref target="I-D.ietf-tls-deprecate-obsolete-kex"/> for details.</t> See <xref target="I-D.ietf-tls-deprecate-obsolete-kex"/> for details.</t>
<t>Thirdly, symmetric ciphers which were widely-used in the protocol, name
ly RC4 <t>Third, symmetric ciphers that are widely used in TLS 1.2, namely RC4
and CBC cipher suites, suffer from several weaknesses. RC4 suffers from and Cipher Block Chaining (CBC) cipher suites, suffer from several weaknesses. R
C4 suffers from
exploitable biases in its key stream; see <xref target="RFC7465"/>. CBC cipher s uites have exploitable biases in its key stream; see <xref target="RFC7465"/>. CBC cipher s uites have
been a source of vulnerabilities throughout the years. A straightforward been a source of vulnerabilities throughout the years. A straightforward
implementation of these cipher suites inherently suffers from the Lucky13 timing implementation of these cipher suites inherently suffers from the Lucky13 timing
attack <xref target="LUCKY13"/>. The first attempt to implement the cipher suite s in attack <xref target="LUCKY13"/>. The first attempt to implement the cipher suite s in
constant time introduced an even more severe vulnerability <xref target="LUCKY13 FIX"/>. constant time introduced an even more severe vulnerability <xref target="LUCKY13 FIX"/>.
There have been further similar vulnerabilities throughout the Refer to <xref target="CBCSCANNING"/>
years exploiting CBC cipher suites; refer to, e.g., <xref target="CBCSCANNING"/> for another example of a vulnerability with CBC cipher suites and a survey of si
for an example and a survey of similar works.</t> milar works.</t>
<t>In addition, TLS 1.2 was affected by several other attacks that <t>In addition, TLS 1.2 was affected by several other attacks that
TLS 1.3 is immune to: TLS 1.3 is immune to:
BEAST <xref target="BEAST"/>, Logjam <xref target="WEAKDH"/>, FREAK <xref target ="FREAK"/>, and SLOTH <xref target="SLOTH"/>.</t> BEAST <xref target="BEAST"/>, Logjam <xref target="WEAKDH"/>, FREAK <xref target ="FREAK"/>, and SLOTH <xref target="SLOTH"/>.</t>
<t>And finally, while <t>Finally, while
application layer traffic is always encrypted, most of the handshake application-layer traffic in TLS 1.2 is always encrypted, most of the content of
messages are not. Therefore, the privacy provided is suboptimal. the handshake
messages is not. Therefore, the privacy provided is suboptimal.
This is a protocol issue that cannot be addressed by configuration.</t> This is a protocol issue that cannot be addressed by configuration.</t>
</section> </section>
<section anchor="iana"> <section anchor="iana">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document makes no requests to IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-tls-deprecate-obsolete-kex" to="KEY-EXCHA
NGE"/>
<displayreference target="I-D.ietf-pquip-pqc-engineers" to="PQC-FOR-ENGINEER
S"/>
<displayreference target="RFC5246" to="TLS12"/>
<displayreference target="RFC9846" to="TLS13"/>
<displayreference target="RFC9851" to="TLS12FROZEN"/>
<displayreference target="RFC9001" to="QUICTLS"/>
<displayreference target="RFC8310" to="DNSTLS"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="TLS12"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52
<front> 46.xml"/>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</titl
e> <!-- [RFC9846 / TLS13]
<author fullname="T. Dierks" initials="T." surname="Dierks"/> draft-ietf-tls-rfc8446bis-14
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/> companion doc RFC 9846
<date month="August" year="2008"/> AUTH48 state as of 1/5/2026
<abstract> -->
<t>This document specifies Version 1.2 of the Transport Layer Secu <reference anchor="RFC9846" target="https://www.rfc-editor.org/info/rfc9
rity (TLS) protocol. The TLS protocol provides communications security over the 846">
Internet. The protocol allows client/server applications to communicate in a way
that is designed to prevent eavesdropping, tampering, or message forgery. [STAN
DARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5246"/>
<seriesInfo name="DOI" value="10.17487/RFC5246"/>
</reference>
<reference anchor="TLS13">
<front> <front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl e> <title>The Transport Layer Security (TLS) Protocol Version 1.3</titl e>
<author fullname="Eric Rescorla" initials="E." surname="Rescorla"> <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
<organization>Independent</organization> <organization>Independent</organization>
</author> </author>
<date day="17" month="February" year="2025"/> <date month='January' year='2026'/>
<abstract>
<t> This document specifies version 1.3 of the Transport Layer S
ecurity
(TLS) protocol. TLS allows client/server applications to communicate
over the Internet in a way that is designed to prevent eavesdropping,
tampering, and message forgery.
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.
</t>
</abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-rfc8446bis-12" <seriesInfo name="RFC" value="9846"/>
/> <seriesInfo name="DOI" value="10.17487/RFC9846"/>
</reference> </reference>
<reference anchor="TLS12FROZEN">
<!-- [RFC9851 / TLS12FROZEN]
draft-ietf-tls-tls12-frozen-08
AUTH48 state as of 1/5/2026
-->
<reference anchor="RFC9851" target="https://www.rfc-editor.org/info/rfc9
851">
<front> <front>
<title>TLS 1.2 is in Feature Freeze</title> <title>TLS 1.2 is in Feature Freeze</title>
<author fullname="Rich Salz" initials="R." surname="Salz"> <author initials="R." surname="Salz" fullname="Rich Salz">
<organization>Akamai Technologies</organization> <organization>Akamai Technologies</organization>
</author> </author>
<author fullname="Nimrod Aviram" initials="N." surname="Aviram"> <author initials="N." surname="Aviram" fullname="Nimrod Aviram">
</author> </author>
<date day="3" month="April" year="2025"/> <date month="January" year='2026'/>
<abstract>
<t> Use of TLS 1.3, which fixes some known deficiencies in TLS 1
.2, is
growing. This document specifies that outside of urgent security
fixes (as determine by TLS WG consensus), new TLS Exporter Labels, or
new Application-Layer Protocol Negotiation (ALPN) Protocol IDs, no
changes will be approved for TLS 1.2. This prescription does not
pertain to DTLS (in any DTLS version); it pertains to TLS only.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-tls12-frozen-0
8"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC9325">
<front>
<title>Recommendations for Secure Use of Transport Layer Security (T
LS) and Datagram Transport Layer Security (DTLS)</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
"/>
<author fullname="T. Fossati" initials="T." surname="Fossati"/>
<date month="November" year="2022"/>
<abstract>
<t>Transport Layer Security (TLS) and Datagram Transport Layer Sec
urity (DTLS) are used to protect data exchanged over a wide range of application
protocols and can also form the basis for secure transport protocols. Over the
years, the industry has witnessed several serious attacks on TLS and DTLS, inclu
ding attacks on the most commonly used cipher suites and their modes of operatio
n. This document provides the latest recommendations for ensuring the security o
f deployed services that use TLS and DTLS. These recommendations are applicable
to the majority of use cases.</t>
<t>RFC 7525, an earlier version of the TLS recommendations, was pu
blished when the industry was transitioning to TLS 1.2. Years later, this transi
tion is largely complete, and TLS 1.3 is widely available. This document updates
the guidance given the new environment and obsoletes RFC 7525. In addition, thi
s document updates RFCs 5288 and 6066 in view of recent attacks.</t>
</abstract>
</front> </front>
<seriesInfo name="BCP" value="195"/> <seriesInfo name="RFC" value="9851"/>
<seriesInfo name="RFC" value="9325"/> <seriesInfo name="DOI" value="10.17487/RFC9851"/>
<seriesInfo name="DOI" value="10.17487/RFC9325"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
325.xml"/>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="QUICTLS"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.57
<front> 46.xml"/>
<title>Using TLS to Secure QUIC</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.90
<author fullname="M. Thomson" initials="M." role="editor" surname="T 01.xml"/>
homson"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
<author fullname="S. Turner" initials="S." role="editor" surname="Tu 10.xml"/>
rner"/>
<date month="May" year="2021"/>
<abstract>
<t>This document describes how Transport Layer Security (TLS) is u
sed to secure QUIC.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9001"/>
<seriesInfo name="DOI" value="10.17487/RFC9001"/>
</reference>
<reference anchor="DNSTLS">
<front>
<title>Usage Profiles for DNS over TLS and DNS over DTLS</title>
<author fullname="S. Dickinson" initials="S." surname="Dickinson"/>
<author fullname="D. Gillmor" initials="D." surname="Gillmor"/>
<author fullname="T. Reddy" initials="T." surname="Reddy"/>
<date month="March" year="2018"/>
<abstract>
<t>This document discusses usage profiles, based on one or more au
thentication mechanisms, which can be used for DNS over Transport Layer Security
(TLS) or Datagram TLS (DTLS). These profiles can increase the privacy of DNS tr
ansactions compared to using only cleartext DNS. This document also specifies ne
w authentication mechanisms -- it describes several ways that a DNS client can u
se an authentication domain name to authenticate a (D)TLS connection to a DNS se
rver. Additionally, it defines (D)TLS protocol profiles for DNS clients and serv
ers implementing DNS over (D)TLS. This document updates RFC 7858.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8310"/>
<seriesInfo name="DOI" value="10.17487/RFC8310"/>
</reference>
<reference anchor="PQC" target="https://www.nist.gov/cybersecurity/what- post-quantum-cryptography"> <reference anchor="PQC" target="https://www.nist.gov/cybersecurity/what- post-quantum-cryptography">
<front> <front>
<title>What Is Post-Quantum Cryptography?</title> <title>What Is Post-Quantum Cryptography?</title>
<author> <author>
<organization/> <organization>NIST</organization>
</author> </author>
<date year="2024" month="August"/> <date year="2025" month="June"/>
</front> </front>
</reference> </reference>
<reference anchor="TRIPLESHAKE" target="https://mitls.org/pages/attacks/
3SHAKE"> <reference anchor="TRIPLESHAKE" target="https://web.archive.org/web/2025
0804151857/https://mitls.org/pages/attacks/3SHAKE">
<front> <front>
<title>Triple Handshakes Considered Harmful Breaking and Fixing Auth entication over TLS</title> <title>Triple Handshakes Considered Harmful: Breaking and Fixing Aut hentication over TLS</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date>
</front> </front>
<refcontent>Wayback Machine archive</refcontent>
</reference> </reference>
<reference anchor="RENEG1" target="https://web.archive.org/web/200912310 34700/http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.ht ml"> <reference anchor="RENEG1" target="https://web.archive.org/web/200912310 34700/http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.ht ml">
<front> <front>
<title>Understanding the TLS Renegotiation Attack</title> <title>Understanding the TLS Renegotiation Attack</title>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla"> <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date day="5" month="11" year="2009"/>
</front> </front>
<refcontent>Wayback Machine archive</refcontent>
</reference> </reference>
<reference anchor="RENEG2" target="https://web.archive.org/web/200912280 61844/http://extendedsubset.com/?p=8"> <reference anchor="RENEG2" target="https://web.archive.org/web/200912280 61844/http://extendedsubset.com/?p=8">
<front> <front>
<title>Authentication Gap in TLS Renegotiation</title> <title>Authentication Gap in TLS Renegotiation</title>
<author initials="M." surname="Ray" fullname="Marsh Ray"> <author initials="M." surname="Ray" fullname="Marsh Ray">
<organization/> <organization/>
</author> </author>
<date>n.d.</date>
</front> </front>
<refcontent>Wayback Machine archive</refcontent>
</reference> </reference>
<reference anchor="LUCKY13" target="http://www.isg.rhul.ac.uk/tls/TLStim ing.pdf"> <reference anchor="LUCKY13" target="http://www.isg.rhul.ac.uk/tls/TLStim ing.pdf">
<front> <front>
<title>Lucky Thirteen: Breaking the TLS and DTLS record protocols</t itle> <title>Lucky Thirteen: Breaking the TLS and DTLS record protocols</t itle>
<author initials="N. J." surname="Al Fardan"> <author initials="N. J." surname="Al Fardan">
<organization/> <organization/>
</author> </author>
<author initials="K. G." surname="Paterson"> <author initials="K. G." surname="Paterson">
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date month="2" year="2013"/>
</front> </front>
</reference> </reference>
<reference anchor="LUCKY13FIX" target="https://nds.rub.de/media/nds/vero effentlichungen/2016/10/19/tls-attacker-ccs16.pdf"> <reference anchor="LUCKY13FIX" target="https://nds.rub.de/media/nds/vero effentlichungen/2016/10/19/tls-attacker-ccs16.pdf">
<front> <front>
<title>Systematic fuzzing and testing of TLS libraries</title> <title>Systematic Fuzzing and Testing of TLS Libraries</title>
<author initials="J." surname="Somorovsky" fullname="Juraj Somorovsk y"> <author initials="J." surname="Somorovsky" fullname="Juraj Somorovsk y">
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date month="10" year="2016"/>
</front> </front>
<refcontent>CCS '16: Proceedings of the 2016 ACM SIGSAC Conference on
Computer and Communications Security, pp. 1492-1504</refcontent>
<seriesInfo name="DOI" value="10.1145/2976749.2978411"/>
</reference> </reference>
<reference anchor="CBCSCANNING" target="https://www.usenix.org/system/fi les/sec19-merget.pdf"> <reference anchor="CBCSCANNING" target="https://www.usenix.org/system/fi les/sec19-merget.pdf">
<front> <front>
<title>Scalable Scanning and Automatic Classification of TLS Padding Oracle Vulnerabilities</title> <title>Scalable Scanning and Automatic Classification of TLS Padding Oracle Vulnerabilities</title>
<author initials="R." surname="Merget" fullname="Robert Merget"> <author initials="R." surname="Merget" fullname="Robert Merget">
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Somorovsky" fullname="Juraj Somorovsk y"> <author initials="J." surname="Somorovsky" fullname="Juraj Somorovsk y">
<organization/> <organization/>
</author> </author>
<author initials="N." surname="Aviram" fullname="Nimrod Aviram"> <author initials="N." surname="Aviram" fullname="Nimrod Aviram">
<organization/> <organization/>
</author> </author>
<author initials="C." surname="Young" fullname="Craig Young"> <author initials="C." surname="Young" fullname="Craig Young">
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Fliegenschmidt" fullname="Janis Flieg enschmidt"> <author initials="J." surname="Fliegenschmidt" fullname="Janis Flieg enschmidt">
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Schwenk" fullname="Jörg Schwenk"> <author initials="J." surname="Schwenk" fullname="Jorg Schwenk">
<organization/> <organization/>
</author> </author>
<author initials="Y." surname="Shavitt" fullname="Yuval Shavitt"> <author initials="Y." surname="Shavitt" fullname="Yuval Shavitt">
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date month="8" year="2019"/>
</front> </front>
<refcontent>28th USENIX Security Symposium (USENIX Security 19)</refco ntent>
</reference> </reference>
<reference anchor="BEAST" target="http://www.hpcc.ecs.soton.ac.uk/dan/ta lks/bullrun/Beast.pdf"> <reference anchor="BEAST" target="http://www.hpcc.ecs.soton.ac.uk/dan/ta lks/bullrun/Beast.pdf">
<front> <front>
<title>Here come the xor ninjas</title> <title>Here Come the XOR Ninjas</title>
<author initials="T." surname="Duong" fullname="Thai Duong"> <author initials="T." surname="Duong" fullname="Thai Duong">
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Rizzo" fullname="Juliano Rizzo"> <author initials="J." surname="Rizzo" fullname="Juliano Rizzo">
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date month="5" year="2011"/>
</front> </front>
</reference> </reference>
<reference anchor="WEAKDH" target="https://dl.acm.org/doi/pdf/10.1145/28 10103.2813707"> <reference anchor="WEAKDH" target="https://dl.acm.org/doi/pdf/10.1145/28 10103.2813707">
<front> <front>
<title>Imperfect forward secrecy: How Diffie-Hellman fails in practi ce</title> <title>Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practi ce</title>
<author initials="D." surname="Adrian"> <author initials="D." surname="Adrian">
<organization/> <organization/>
</author> </author>
<author initials="K." surname="Bhargavan"> <author initials="K." surname="Bhargavan">
<organization/> <organization/>
</author> </author>
<author initials="Z." surname="Durumeric"> <author initials="Z." surname="Durumeric">
<organization/> <organization/>
</author> </author>
<author initials="P." surname="Gaudry"> <author initials="P." surname="Gaudry">
skipping to change at line 461 skipping to change at line 388
</author> </author>
<author initials="J. A." surname="Halderman"> <author initials="J. A." surname="Halderman">
<organization/> <organization/>
</author> </author>
<author initials="N." surname="Heninger"> <author initials="N." surname="Heninger">
<organization/> <organization/>
</author> </author>
<author initials="D." surname="Springall"> <author initials="D." surname="Springall">
<organization/> <organization/>
</author> </author>
<author initials="E." surname="Thomé"> <author initials="E." surname="Thome">
<organization/> <organization/>
</author> </author>
<author initials="L." surname="Valenta"> <author initials="L." surname="Valenta">
<organization/> <organization/>
</author> </author>
<author initials="B." surname="VanderSloot"> <author initials="B." surname="VanderSloot">
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <author initials="E." surname="Wustrow">
<organization/>
</author>
<author initials="S." surname="Zanella-Beguelin">
<organization/>
</author>
<author initials="P." surname="Zimmerman">
<organization/>
</author>
<date month="10" year="2015"/>
</front> </front>
<refcontent>CCS '15: Proceedings of the 22nd ACM SIGSAC Conference on
Computer and Communications Security, pp. 5-17</refcontent>
<seriesInfo name="DOI" value="10.1145/2810103.2813707"/>
</reference> </reference>
<reference anchor="FREAK" target="https://inria.hal.science/hal-01114250 /file/messy-state-of-the-union-oakland15.pdf"> <reference anchor="FREAK" target="https://inria.hal.science/hal-01114250 /file/messy-state-of-the-union-oakland15.pdf">
<front> <front>
<title>A messy state of the union: Taming the composite state machin es of TLS</title> <title>A Messy State of the Union: Taming the Composite State Machin es of TLS</title>
<author initials="B." surname="Beurdouche" fullname="Benjamin Beurdo uche"> <author initials="B." surname="Beurdouche" fullname="Benjamin Beurdo uche">
<organization/> <organization/>
</author> </author>
<author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhar gavan"> <author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhar gavan">
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Delignat-Lavaud" fullname="Antoine De lignat-Lavaud"> <author initials="A." surname="Delignat-Lavaud" fullname="Antoine De lignat-Lavaud">
<organization/> <organization/>
</author> </author>
<author initials="C." surname="Fournet" fullname="Cédric Fournet"> <author initials="C." surname="Fournet" fullname="Cedric Fournet">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Kohlweiss" fullname="Markulf Kohlweis s"> <author initials="M." surname="Kohlweiss" fullname="Markulf Kohlweis s">
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Pironti" fullname="Alfredo Pironti"> <author initials="A." surname="Pironti" fullname="Alfredo Pironti">
<organization/> <organization/>
</author> </author>
<author initials="P.-Y." surname="Strub" fullname="Pierre-Yves Strub "> <author initials="P.-Y." surname="Strub" fullname="Pierre-Yves Strub ">
<organization/> <organization/>
</author> </author>
<author initials="J. K." surname="Zinzindohoue" fullname="Jean Karim Zinzindohoue"> <author initials="J. K." surname="Zinzindohoue" fullname="Jean Karim Zinzindohoue">
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date month="5" year="2015"/>
</front> </front>
<refcontent>IEEE Symposium on Security &amp; Privacy 2015</refcontent>
<seriesInfo name="HAL ID:" value="hal-01114250"/>
</reference> </reference>
<reference anchor="SLOTH" target="https://inria.hal.science/hal-01244855 /file/SLOTH_NDSS16.pdf"> <reference anchor="SLOTH" target="https://inria.hal.science/hal-01244855 /file/SLOTH_NDSS16.pdf">
<front> <front>
<title>Transcript collision attacks: Breaking authentication in TLS, IKE, and SSH</title> <title>Transcript Collision Attacks: Breaking Authentication in TLS, IKE, and SSH</title>
<author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhar gavan"> <author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhar gavan">
<organization/> <organization/>
</author> </author>
<author initials="G." surname="Leurent" fullname="Gaëtan Leurent"> <author initials="G." surname="Leurent" fullname="Gaetan Leurent">
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date month="2" year="2016"/>
</front>
</reference>
<reference anchor="I-D.ietf-pquip-pqc-engineers">
<front>
<title>Post-Quantum Cryptography for Engineers</title>
<author fullname="Aritra Banerjee" initials="A." surname="Banerjee">
<organization>Nokia</organization>
</author>
<author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy
.K">
<organization>Nokia</organization>
</author>
<author fullname="Dimitrios Schoinianakis" initials="D." surname="Sc
hoinianakis">
<organization>Nokia</organization>
</author>
<author fullname="Tim Hollebeek" initials="T." surname="Hollebeek">
<organization>DigiCert</organization>
</author>
<author fullname="Mike Ounsworth" initials="M." surname="Ounsworth">
<organization>Entrust Limited</organization>
</author>
<date day="13" month="February" year="2025"/>
<abstract>
<t> The advent of a cryptographically relevant quantum computer
(CRQC)
would render state-of-the-art, traditional public-key algorithms
deployed today obsolete, as the mathematical assumptions underpinning
their security would no longer hold. To address this, protocols and
infrastructure must transition to post-quantum algorithms, which are
designed to resist both traditional and quantum attacks. This
document explains why engineers need to be aware of and understand
post-quantum cryptography (PQC), detailing the impact of CRQCs on
existing systems and the challenges involved in transitioning to
post-quantum algorithms. Unlike previous cryptographic updates, this
shift may require significant protocol redesign due to the unique
properties of post-quantum algorithms.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pquip-pqc-engineer
s-09"/>
</reference>
<reference anchor="RFC5746">
<front>
<title>Transport Layer Security (TLS) Renegotiation Indication Exten
sion</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="M. Ray" initials="M." surname="Ray"/>
<author fullname="S. Dispensa" initials="S." surname="Dispensa"/>
<author fullname="N. Oskov" initials="N." surname="Oskov"/>
<date month="February" year="2010"/>
<abstract>
<t>Secure Socket Layer (SSL) and Transport Layer Security (TLS) re
negotiation are vulnerable to an attack in which the attacker forms a TLS connec
tion with the target server, injects content of his choice, and then splices in
a new TLS connection from a client. The server treats the client's initial TLS h
andshake as a renegotiation and thus believes that the initial data transmitted
by the attacker is from the same entity as the subsequent client data. This spec
ification defines a TLS extension to cryptographically tie renegotiations to the
TLS connections they are being performed over, thus preventing this attack. [ST
ANDARDS-TRACK]</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="5746"/> <refcontent>Network and Distributed System Security Symposium - NDSS 2
<seriesInfo name="DOI" value="10.17487/RFC5746"/> 016</refcontent>
<seriesInfo name="DOI" value="10.14722/ndss.2016.23418"/>
<seriesInfo name="HAL ID:" value="hal-01244855"/>
</reference> </reference>
<reference anchor="I-D.ietf-tls-deprecate-obsolete-kex"> <!-- [I-D.ietf-pquip-pqc-engineers]
<front> draft-ietf-pquip-pqc-engineers-14
<title>Deprecating Obsolete Key Exchange Methods in TLS 1.2</title> IESG State: EDIT as of 1/5/2026
<author fullname="Carrick Bartle" initials="C." surname="Bartle">
<organization>Roblox</organization>
</author>
<author fullname="Nimrod Aviram" initials="N." surname="Aviram">
</author>
<date day="3" month="September" year="2024"/>
<abstract>
<t> This document deprecates the use of RSA key exchange and Dif
fie
Hellman over a finite field in TLS 1.2, and discourages the use of
static elliptic curve Diffie Hellman cipher suites.
Note that these prescriptions apply only to TLS 1.2 since TLS 1.0 and LONG WAY for author name
1.1 are deprecated by RFC 8996 and TLS 1.3 either does not use the -->
affected algorithm or does not share the relevant configuration
options.
This document updates RFCs 9325, 4346, 5246, 4162, 6347, 5932, 5288, <reference anchor="I-D.ietf-pquip-pqc-engineers" target="https://datatracker.iet
6209, 6367, 8422, 5289, 5469, 4785, 4279, 5487, 6655, and 7905. f.org/doc/html/draft-ietf-pquip-pqc-engineers-14">
<front>
<title>Post-Quantum Cryptography for Engineers</title>
<author fullname="Aritra Banerjee" initials="A." surname="Banerjee">
<organization>Nokia</organization>
</author>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization>Nokia</organization>
</author>
<author fullname="Dimitrios Schoinianakis" initials="D." surname="Schoinianakis"
>
<organization>Nokia</organization>
</author>
<author fullname="Tim Hollebeek" initials="T." surname="Hollebeek">
<organization>DigiCert</organization>
</author>
<author fullname="Mike Ounsworth" initials="M." surname="Ounsworth">
<organization>Entrust Limited</organization>
</author>
<date day="25" month="August" year="2025"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pquip-pqc-engineers-14"/>
</reference>
</t> <!-- [I-D.ietf-tls-deprecate-obsolete-kex]
</abstract> draft-ietf-tls-deprecate-obsolete-kex-06
</front> IESG State: IESG Evaluation as of 1/5/2026
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-deprecate-obso -->
lete-kex-05"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
</reference> ietf-tls-deprecate-obsolete-kex.xml"/>
<reference anchor="RFC7465"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<front> 465.xml"/>
<title>Prohibiting RC4 Cipher Suites</title>
<author fullname="A. Popov" initials="A." surname="Popov"/>
<date month="February" year="2015"/>
<abstract>
<t>This document requires that Transport Layer Security (TLS) clie
nts and servers never negotiate the use of RC4 cipher suites when they establish
connections. This applies to all TLS versions. This document updates RFCs 5246,
4346, and 2246.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7465"/>
<seriesInfo name="DOI" value="10.17487/RFC7465"/>
</reference>
</references> </references>
</references> </references>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA81a3XLbRpa+76foVS42mSJBUZIdW5kdh5ZkW2NZVkR5Ms7U
VKoJNMmOADSnG5BEu3S1L7K3W3u/DzD7Yvud0w0QoORKUrUXm0oisNE/5/98
5zSGw6GoTJXrQ7lzrm/lhbOVTW3u5QdvyoW8OpvKd7Wv5KX+R22c5oFxsr8j
1Gzm9A2WufBmWOWeX6Sq0gvr1odylq5Evcrw2x/K5/t7T4TIbFqqAqdlTs2r
odHVfFhXatjdZH843hO+nhXGe2PLar3C/NOTq1eirIuZdoeCtjwUqS29Ln2N
zStXawFi9oVyWoGoqU5rZ6r1jri17nrhbL3C6IYnU8rJapUbEIsj/I641mvM
zA6FHNKE+EdeOVV6Q3OakWm9WllX0c/TstLOrrRTM5PjMBqba1XVTntxo8sa
REr5Gw6XMjC58yOIpVmvaQ2NF8rkGIeIvidZJdYtaHhhqmU9I+GbdOlV/mkU
5Fn7KMIdIVRdLS2ENcT8eZ3nQe6XWCCnWIFRbKZK84mpOJSTa4XT5JVOl6XN
7cKACSl1oMDRId8rnpKkttja9dwUzmZycmOcKjarSh5OFA9/v6BBXixK6woc
e8MCgkjGe6Ds1dGTvYOncWAfKh8eJx0zAV9DN0+fHRw8nRnfrHt1+f6nk/NH
J5Mg9oZzZz/pUghTzruH/vDh9Agb8LHPd3fHGDo+nzYjz/bHuxi5+OGI5kI9
yi10dSiXVbXyh6PR7e1tUhpfJQt7M0rXMEofDW50u1TVcGV9NfxHrcqqLoap
W68qu3BqtVzzbmy+cmdSL+BZA7m3u3ewE44JnvgjtpCnXl7QLj+EXeRRZ5cX
xP3l6cXZyfTN5O3J4zQW2MyTwYxWaqH9SFWVSq/9aJ/XdM+7cmaVa/lGlZlf
qmvt5RHM0mTa6QyjroCi5Us4FtsmZslX5o4eJzAxXVbRkKW90S44j7w8OT95
PT7snvKhxIa+wnJaioXsC5e6RLSoTNhhwjTyqsZ8Jf8TzOwE5o4VPrUuV48r
Rs8S5dIltMys4/dob3f3+XgPGt0/+HZ3d0RTowp1VlO0yha19p4CBa+h+aPx
eFR3Cf4ZBP8Mgf7sIsHJsiryhtO9HqdbYnmtVuTyD7h9hM1hZPSdcn4pL9X6
dzK592z36Rge0jCp7yoNLjJEU68r8r3Ri9W/PcOuZx+O3n6El3Xp3jmr0+u1
vFoaV2mNkNDqvNEW6f6YHpyGDjK5atLFzgNCo4iNXyRuWeeJSpP6egQJjrC+
MgW2TVbZ/FEhmBIx/TyRf07kJJevlMtU2X/5NpGvE3kB5TnPkoz8vDr9a5+l
6dpXmtw+Rbj69KkxYKSkip7tnPnKzcwph4j3kA8SOPwicfUsyfSo0JlRNDCC
sVs9n0PRiOTLulzoEloYPx2Nd0fj58TpMLicdsM09eOnX2A3aPzPtVO/yKkt
rLM3/poUf/TyaHo0OT8/PX/d42maqlzN4LB4KMuGIxidDXwe5QqJc956ZWDx
QmXseO+dSrH2L3VeNokrRPrHoxwySmnu2Mw8i3I0NzmiCeLd+Pmw0LTii3qM
KcciPlbyHc/devcI293X23ml++7IKbOQHy0kv70pspqXr3KjoROfLguTPTj3
f/79n//tFhDh8laX11tvP9Y3KpfTJRJXRStfnkymV327eoPgKOFPmn3jzjok
u/IX9WVHWK7SNNGpTzxcpozuALseVSpHVJ4hl7q6HL3Uyv+aQK+WyNPHtX3I
eJ0bVVok+U+fLN79eDJ5e/ymT/hpAcAy12klkQ9v4VoSqoQ7A6+9sbfy2Mzn
Rg/f6DwvVCnnSNmeotcKZgPj0o87SEb+XbCVZNaMQD68IBmPD56M9p6NdxF6
E/zd/3b32y/7+zGcPXPmEU9/ucRx6mb7zU8JhOBq2KBJ+28uEB1Unbl1f/gd
hh0CW3+UgkzyRuUI9sX2EYhBbzS5mHYPiJ2uHF6oPO+/OUmgH1vAvv6z/+Is
kX9ROcKF6o+/pHFKNdPcWrK2V5dQW19pE1kgQ60lslGlyaPJ6OqScduVKpoQ
DXsE8jCYEiYWCkmiRD4PMeBx3ZkSQk+WKk98anSZ6hGeh7tjaG/vyS67+4hP
H/KmQwt0tdRDPn1o1XUO4sdPfsVkX2o4B+jEQ+0yW6dLvTXjrXLV0gCGw+oe
KjzMmZSVBT/yWOdmUQJnnWFSnW0HBpJ9RlDhla1d+SDmILle1/lcvrXL/Faj
yNg+JZ8D+Fh5YRyqD7P19sJoh0Ll4w3EOkXdMdv2QQ0GwIwp5E+mRMLJ7NLW
xO307P3VljNyeZECflXQXZ4bqndkBGqd9Kv6gCKAiYE8fXsy4Ng/nb75fbrd
Ozh49uRJ0C2T9fP58XT6xRT1e3T0WkH8/wXUJM+galAtxHA4lGrmKwohQsQK
UiKzSITpW+BMvwKn2UCaSi6Vx38Zm7LT4NoD5cgGXRPgsHMfuDaVMJhkSRMz
Wy03s+gtvPNGpesWlOLMvQSweYnAjcinB7JEvdsCGFER6CaaaG5BJa/rl7xY
PPEB/RD5IL20FZOf48QbBEpOytaJTK9yu9ZgCNLyOEMHHZPuMqvDQkThSkGT
lQ17fo1nVa7DD9BMpvDNd8K0Mz1NpZe2zNcJ5Eh7o55GACxBeaizuZxBpc0i
yIxPa+8x2q1HZLceCWAIzvio7KJ46QDfE6SElpR0bI6IaZRKZBAgk5EEnSPv
ZrkW4iuqlJHH65RF8PkrHIaKXwG5+fttRvxKpwAvIJo2HEhUzWmrg8eM5req
kRgDMMIpsBwv9R3qN3IJ6PV0I7/Pn6ME7+8FmMxYdTPUQVDP58+oP+ndMM6+
v/9/ZxSRkM+fuYi+vyeSsMlGYCwcksXc3OHUApYhr0t7Cyo0MCNFCRL+ramW
YuM2J3eqQI3oQ+7hPdO8zrTEdDInilLAcG1ugq8DR6TS22AX5KuBRaKBZTKD
b9YVl5meCXK6sDdhI9DUsVLsA4tEPYtQ4AVolemmPr1FjEwkUI2FQIDF1wMm
oLGIxwOK2AoofL5HnM65prkxxNldChDEJtlMJqGAZlYJwelg/tSImptFHdyh
VcJeVMJeq4RG8oDtckbZOiwDEx4JsRFUQ4CXC2uzHqWkdCgH+gBU07CHQeuQ
vkYpAkHOnS1AMN4BwXY1ipjpxZY5kx82ogy9qGDRWQbr9BFVFKC7BsxZN57k
xQy2ZK83HLSM/1+EJNEYZ9At4AtNjwX0b4o9X1H/4oYSJjgKNSsEUbK6PFGp
JXKYpH6flzvvPkyvdgbhrzx/z8+XJz98OL08Oabn6ZvJ2Vn7IOKM6Zv3H86O
N0+blUfv3707OT8OizEqe0Ni593k405IYDvvL65O359PznaIvaonPAVfgmvD
TAx1GWG6lc4eqPDl0cU//2N8AFX+C6S8Nx4/h7GFH8/G3x7gxy0sPpxGESL+
hFYh5tVKK0e7QLmwyZVBJcJmQp6AeECZEtL8w99IMn8/lH+cpavxwZ/iADHc
G2xk1htkmT0cebA4CPGRoUeOaaXZG9+SdJ/eycfe70buncE/vsgJWQ7Hz178
SXDKKjYdWraxL+fQry9+OPpGiKNuxCKHQY7LNRBSJdtlCEI19Szk10eXWDSA
VpDd2kQxQIhBQYHCE4NyWS805WDAJsxj+2/i6tdeY7JOFskA+p7qkFn3EH7F
C2qFchN0BXdd4f/pUJcLcIdz7++/IRBkJUXTBdUIZHYhjKhOTzrQgSUZWWFh
wFXFBvnFnmSQgvwb/v93HHGskZ5ynYl+fKH8QDYIi+ye14YWarkiW8Y5koRE
wVOBTCSOKqT3rbUNlRTyqa5VC0qMgA7kQzO9tgHiSJ8igDYJTDSeBgt/ZQOw
QeylQN2kEtoTGUuH6EI7zLEmpkCNWK7nsIsq5EpTiqZJ9uNr2iZmYoG9c2pT
DSLUwlZNICMZc06El/twrQBOSLVN6gjdbVJaiK3418JKOdMGAMWm2YNAPdwK
FpAEVJ1XDVAATQNxS74tLqJwU0qsCA4zTSGfO57KZeYTgRXlQ2BaUO7lg7pm
wjzbAGKwPyU4bMohmM764DnNv8cs17la4nZVdxcxQULtMiEbGBfkyPEmAMM1
UUT4rWGrQeesRR1gyoDb+xBi7PIjDrYG1iAkzvg9rAksk61QX1Ze8IFQGirW
4COc68roZmZOJmipY9CAMpIjyM3A+ulcBqzHcXzL/MkkFQ2m2pVbSAVRqmVy
k+sEWXuLNQB3UXU3vAfJJ2LiedOaMsVGBrT5B68QQyB6KvXYVo7Ppxso//lz
uPSAgFpZiE6epS3iYQhNS9oDOcJSxrC3zXVWK31oEPvGjZpAwpJNl9Z6jh/R
zhsGiUp6g/wG+EJwnGUkQupzhGOCVClpcwoHrKG1y+ayItDCAsiNDl7bSBEU
A1dFFTWOy/y1QofPR5J8UwsBPjkSEIO20D/n8GLSa369NAu4fyUa1Te4jSXT
bMalZvDYgK6jNHc6SF50LgMGO7HyinTRj+7NSMbxNBhQA6IiimOkPxBNEjgA
YB9DobRDDCMDcjcwYu7kCSO8d4Rge43vFvYqeavWgiyllw86UiU2nCoXHEtb
4RKmwNIShhJqg9CYFoi5ZcAw1FPlwBOgCG0DzUGSFPCjULv+1FhkdCqa3w37
7HF8SAjeZPTkcuEtK6XVLCc5BpbwXRMKHr+J64+s59hM8ayj8VZvbbBmJytF
sDwvI2RpBPULlZ+0HmHEFMiXG4uJsophncPNbFPlWrfxD8QSHa7MwkKZGofM
RVGanKWFg8KE12oG75Yr5RTnZR/w8JL0xVoENOS7eJTh29WsEJ3qd1OG0F1P
AclkHTBE9+6uaTu2JYptQp+musXdmLQJrU1FDhUMZF3m5lr3Ae8g1LjwkltU
XQhpQXKV4XIdwoKF1rPc+KUOjaINDo7oia/gm9sOyrxYsrNdiSc71AEiGBWv
9UNbIIs5rAhFQ/AsIryFCVxHLhw8uUnkXbRONWnBN6fVrUW0Y2lTEGNf2ZIf
O22U80A2brufjMltD4UYUoOfq05+4dXad3HDfmNmXdTw3RZBBeXwSsd+SLOw
sbMN2GjQA2YMgze1OCL5VUr2Hm64TUe7pM0qlOV6JPS6LGy9OHlCGG4QcVaU
ZwgbFALWEcwEVRCCIuNhS28+/GivsKPQQ9Npq9jdlOpkX228YUDXFtFfakSE
elZ7sygpv5GtB2kTeh+EHEvmOwC7fFFEMzkxUpeCa1vtEjbHVe1WlAWb5koj
cEMeK2aIz3OsgMfdIG40dHHPANpCcCFJ4wn2XUQFhQpiTvc8OuvBjEScVk2r
A3oggAuHWjb9hJ56H2lUkHjhUd8FsCwKTb9kQbQwKs3o/iiNeLNdyGk2LiWF
2xXxmwXMSFYHRCcKC82UxBdE6W3b3NhPoFUdy9oYnDg/hROpUW3rxVIuaspf
IUqGtonuIrE2MuwR5DfOt72iht1GRINeo4fv0DnHDUghN/HiNCc4I1zv84XY
uW8gfPgIok3F4UsBgHnZdl23v7yIO7Q1wOYbD64BXjqrski1byZ7oe/ApKl6
av5X30ItklWfTkQg6wi9Qv6m/IWLJoZg5k6khMdKgu2cTeINNmXwEM1WuaJs
fgeFVihBiqTFOU2bSEHqN4oui6BZEQq37hViNLKI26iGlXZGzUyuPugykmCz
vTah7QNAomcYr2g7WG8J0LJYkj5FJ99F66dq+AV9SfTtwdMuqCXA3ioynL8i
dFlGcNB+tUZmEuWaUJ3cWm2wpE1e1oarmr5gueE80wIIjSwkk5RPaPlAcpfK
+A4VcXKoG6jpFjE+zW4QBc0RFOBYWhGZch7fHBzrE+oNMuyG1YfcrDpFC2we
oRGlcGP01pkFqpucW2H6LsRYJEAYftaNhaG9pjvOQfc8+VpcTif9taFvV9L1
I1YivPTvkgexR9lrUYpNiw9ejtCaK8cUPpR8jwjBPeK2Eu/SIRoeGvk2ykhE
CCObBgl9o4HdkaD5YnPmba7xcK3vYoiJqDu0Nh3Lzq+Ryyu6XUzNaknKCFXG
LQHbADfoM7yIIB7KTV4eHTASPXp5FLeAYCA0/6iAZFdAWNpr9DaeH/rpRsVG
KZXHJJHgoN/JEEzILeAVT6gAeHA2Jwwx09x18bZ2aUD3/a9EqAtDoZZCI/G2
1sqBrAmdpMgp4ycFYgtMt3rqn2lKqgY4G/ba17Q1f4o03pfhSyER4+Lnz/E7
H2KCMuec4jg5rC5WnHLakyNW7p/H3ajQ22FgGa+lCHggPiAchJTCstc97teb
s1+d/hXHC75JDImW5TavHUcEH6z4V2QnWHYyKpC89YFOvpNcFIOrTaev803Q
/X2o0sqm4g9QtoEJkHlDCX3ZRjZ8uukkbC4OCPm0QGG2gReWmWkyWgfC7Ycm
WVGXlAEPBX8cA9L47/39QJ7ZxS+qwEj4/ISG+JMGjPBfGuBba7p4pu4l/SWJ
ikmIICEEcrtBdCu+XK1JHLEFSp2r/JbwZbyDIhzTCQubFoGgzxfoG0iunhFN
k+41cHDScOEZa56My896RlVBofJN8011Ggfe17E1SJ9hhS6eCjcnQZLbtyNf
ydPJ+eQhMDWqVA+uQUM1UVpuXKH25JhP6+Pd6oy+k/xfvvRLZ74tAAA=
</rfc> </rfc>
 End of changes. 81 change blocks. 
510 lines changed or deleted 241 lines changed or added

This html diff was produced by rfcdiff 1.48.