rfc9325.original.xml   rfc9325.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.6.16 (Ruby 2.6. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" number="9325"
8) --> docName="draft-ietf-uta-rfc7525bis-11" category="bcp" consensus="true" submissio
<?rfc rfcedstyle="yes"?> nType="IETF" obsoletes="7525" updates="5288, 6066" tocInclude="true" sortRefs="t
<?rfc tocindent="yes"?> rue" symRefs="true" version="3">
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="o-*+"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-uta-rfc7525bis-11" category="bcp" consensus="true" submissionType="IETF" o
bsoletes="7525" updates="5288, 6066" tocInclude="true" sortRefs="true" symRefs="
true" version="3">
<!-- xml2rfc v2v3 conversion 3.14.0 --> <!-- xml2rfc v2v3 conversion 3.14.0 -->
<front> <front>
<title abbrev="TLS Recommendations">Recommendations for Secure Use of Transp <title abbrev="TLS/DTLS Recommendations">Recommendations for Secure Use of T
ort Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title> ransport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</titl
<seriesInfo name="Internet-Draft" value="draft-ietf-uta-rfc7525bis-11"/> e>
<seriesInfo name="RFC" value="9325"/>
<seriesInfo name="BCP" value="195"/>
<author initials="Y." surname="Sheffer" fullname="Yaron Sheffer"> <author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
<organization>Intuit</organization> <organization>Intuit</organization>
<address> <address>
<email>yaronf.ietf@gmail.com</email> <email>yaronf.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre"> <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>independent</organization> <organization>independent</organization>
<address> <address>
<email>stpeter@stpeter.im</email> <email>stpeter@stpeter.im</email>
</address> </address>
</author> </author>
<author initials="T." surname="Fossati" fullname="Thomas Fossati"> <author initials="T." surname="Fossati" fullname="Thomas Fossati">
<organization>arm</organization> <organization>ARM Limited</organization>
<address> <address>
<email>thomas.fossati@arm.com</email> <email>thomas.fossati@arm.com</email>
</address> </address>
</author> </author>
<date year="2022" month="August" day="16"/> <date year="2022" month="November"/>
<area>Applications</area> <area>Applications</area>
<workgroup>UTA Working Group</workgroup> <workgroup>UTA</workgroup>
<keyword>Internet-Draft</keyword>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<abstract> <abstract>
<t>Transport Layer Security (TLS) and Datagram Transport Layer Security (D <t>Transport Layer Security (TLS) and Datagram Transport Layer Security (D
TLS) are used to protect data exchanged over a wide range of application protoco TLS) are used to protect data exchanged over a wide range of application protoco
ls, and can also form the basis for secure transport protocols. Over the years, ls and can also form the basis for secure transport protocols. Over the years,
the industry has witnessed several serious attacks on TLS and DTLS, including a the industry has witnessed several serious attacks on TLS and DTLS, including at
ttacks on the most commonly used cipher suites and their modes of operation. Th tacks on the most commonly used cipher suites and their modes of operation. Thi
is document provides the latest recommendations for ensuring the security of dep s document provides the latest recommendations for ensuring the security of depl
loyed services that use TLS and DTLS. These recommendations are applicable to th oyed services that use TLS and DTLS. These recommendations are applicable to the
e majority of use cases.</t> majority of use cases.</t>
<t>An earlier version of this document was published as RFC 7525 when the <t>RFC 7525, an earlier version of the TLS recommendations, was published
industry was in the midst of its transition to TLS 1.2. Years later this transit when the industry was transitioning to TLS 1.2. Years later, this transition is
ion is largely complete and TLS 1.3 is widely available. This document updates t largely complete, and TLS 1.3 is widely available. This document updates the gui
he guidance given the new environment and obsoletes RFC 7525. In addition, the d dance given the new environment and obsoletes RFC 7525. In addition, this docume
ocument updates RFC 5288 and RFC 6066 in view of recent attacks.</t> nt updates RFCs 5288 and 6066 in view of recent attacks.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>Transport Layer Security (TLS) and Datagram Transport Layer Security (D <t>Transport Layer Security (TLS) and Datagram Transport Layer Security (D
TLS) are used to protect data exchanged over a wide variety of application proto TLS) are used to protect data exchanged over a wide variety of application proto
cols, including HTTP <xref target="HTTP1.1"/> <xref target="HTTP2"/>, IMAP <xref cols, including HTTP <xref target="RFC9112"/> <xref target="RFC9113"/>, IMAP <xr
target="RFC9051"/>, POP <xref target="STD53"/>, SIP <xref target="RFC3261"/>, S ef target="RFC9051"/>, Post Office Protocol (POP) <xref target="STD53"/>, SIP <x
MTP <xref target="RFC5321"/>, and XMPP <xref target="RFC6120"/>. Such protocols ref target="RFC3261"/>, SMTP <xref target="RFC5321"/>, and the Extensible Messag
use both the TLS or DTLS handshake protocol and the TLS or DTLS record layer. ing and Presence Protocol (XMPP) <xref target="RFC6120"/>. Such protocols use b
Although the TLS handshake protocol can also be used with different record layer oth the TLS or DTLS handshake protocol and the TLS or DTLS record layer.
s to define secure transport protocols - the most prominent example is QUIC <xre
f target="RFC9000"/> - such transport protocols are not directly in scope for th <!-- [rfced] FYI: We've replaced hyphens in the following paragraph with parenth
is document; nevertheless, many of the recommendations here might apply insofar eses to add clarity to the sentence. Please let us know if this is not preferred
as such protocols use the TLS handshake protocol.</t> .
<t>Over the years leading to 2015, the industry had witnessed serious atta
cks on TLS and DTLS, including attacks on the most commonly used cipher suites a Original:
nd their modes of operation. For instance, both the AES-CBC <xref target="RFC36 Although the TLS handshake protocol can also be used with different
02"/> and RC4 <xref target="RFC7465"/> encryption algorithms, which together wer record layers to define secure transport protocols - the most prominent
e once the most widely deployed ciphers, were attacked in the context of TLS. D example is QUIC [RFC9000] - such transport protocols are not directly in scop
etailed information about the attacks known prior to 2015 is provided in a compa e
nion document (<xref target="RFC7457"/>) to the previous version of this specifi for this document; nevertheless, many of the recommendations here might apply
cation, which will help the reader understand the rationale behind the recommend insofar as such protocols use the TLS handshake protocol.
ations provided here. That document has not been updated in concert with this on
e; instead, newer attacks are described in this document, as are mitigations for Updated:
those attacks.</t> Although the TLS handshake protocol can also be used with different
record layers to define secure transport protocols (the most prominent exampl
e
is QUIC [RFC9000]), such transport protocols are not directly in scope for
this document; nevertheless, many of the recommendations here might apply
insofar as such protocols use the TLS handshake protocol.
-->
Although the TLS handshake protocol can also be used with different record
layers to define secure transport protocols (the most prominent example is QUIC
<xref target="RFC9000"/>), such transport protocols are not directly in scope f
or this document; nevertheless, many of the recommendations here might apply ins
ofar as such protocols use the TLS handshake protocol.</t>
<t>Over the years leading to 2015, the industry had witnessed serious atta
cks on TLS and DTLS, including attacks on the most commonly used cipher suites a
nd their modes of operation. For instance, both the AES-CBC <xref target="RFC36
02"/> and RC4 <xref target="RFC7465"/> encryption algorithms, which together wer
e once the most widely deployed ciphers, were attacked in the context of TLS. D
etailed information about the attacks known prior to 2015 is provided in a compa
nion document <xref target="RFC7457"/> to the previous version of the TLS recomm
endations <xref target="RFC7525"/>, which will help the reader understand the ra
tionale behind the recommendations provided here. That document has not been upd
ated in concert with this one; instead, newer attacks are described in this docu
ment, as are mitigations for those attacks.</t>
<t>The TLS community reacted to the attacks described in <xref target="RFC 7457"/> in several ways:</t> <t>The TLS community reacted to the attacks described in <xref target="RFC 7457"/> in several ways:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Detailed guidance was published on the use of TLS 1.2 <xref target=" RFC5246"/> and DTLS 1.2 <xref target="RFC6347"/>, along with earlier protocol ve rsions. This guidance is included in the original <xref target="RFC7525"/> and m ostly retained in this revised version; note that this guidance was mostly adopt ed by the industry since the publication of RFC 7525 in 2015.</li> <li>Detailed guidance was published on the use of TLS 1.2 <xref target=" RFC5246"/> and DTLS 1.2 <xref target="RFC6347"/> along with earlier protocol ver sions. This guidance is included in the original <xref target="RFC7525"/> and mo stly retained in this revised version; note that this guidance was mostly adopte d by the industry since the publication of RFC 7525 in 2015.</li>
<li>Versions of TLS earlier than 1.2 were deprecated <xref target="RFC89 96"/>.</li> <li>Versions of TLS earlier than 1.2 were deprecated <xref target="RFC89 96"/>.</li>
<li>Version 1.3 of TLS <xref target="RFC8446"/> was released, followed b y version 1.3 of DTLS <xref target="RFC9147"/>; these versions largely mitigate or resolve the described attacks.</li> <li>Version 1.3 of TLS <xref target="RFC8446"/> was released, followed b y version 1.3 of DTLS <xref target="RFC9147"/>; these versions largely mitigate or resolve the described attacks.</li>
</ul> </ul>
<t>Those who implement and deploy TLS and TLS-based protocols need guidanc e on how they can be used securely. This document provides guidance for deploye d services as well as for software implementations, assuming the implementer exp ects their code to be deployed in the environments defined in <xref target="appl icability"/>. Concerning deployment, this document targets a wide audience -- na mely, all deployers who wish to add authentication (be it one-way only or mutual ), confidentiality, and data integrity protection to their communications.</t> <t>Those who implement and deploy TLS and TLS-based protocols need guidanc e on how they can be used securely. This document provides guidance for deploye d services as well as for software implementations, assuming the implementer exp ects their code to be deployed in the environments defined in <xref target="appl icability"/>. Concerning deployment, this document targets a wide audience, name ly all deployers who wish to add authentication (be it one-way only or mutual), confidentiality, and data integrity protection to their communications.</t>
<t>The recommendations herein take into consideration the security of vari ous mechanisms, their technical maturity and interoperability, and their prevale nce in implementations at the time of writing. Unless it is explicitly called o ut that a recommendation applies to TLS alone or to DTLS alone, each recommendat ion applies to both TLS and DTLS.</t> <t>The recommendations herein take into consideration the security of vari ous mechanisms, their technical maturity and interoperability, and their prevale nce in implementations at the time of writing. Unless it is explicitly called o ut that a recommendation applies to TLS alone or to DTLS alone, each recommendat ion applies to both TLS and DTLS.</t>
<t>This document attempts to minimize new guidance to TLS 1.2 implementati ons, and the overall approach is to encourage systems to move to TLS 1.3. Howeve r, this is not always practical. Newly discovered attacks, as well as ecosystem changes, necessitated some new requirements that apply to TLS 1.2 environments. Those are summarized in <xref target="diff-rfc"/>.</t> <t>This document attempts to minimize new guidance to TLS 1.2 implementati ons, and the overall approach is to encourage systems to move to TLS 1.3. Howeve r, this is not always practical. Newly discovered attacks, as well as ecosystem changes, necessitated some new requirements that apply to TLS 1.2 environments. Those are summarized in <xref target="diff-rfc"/>.</t>
<t>Naturally, future attacks are likely, and this document does not addres s them. Those who implement and deploy TLS/DTLS and protocols based on TLS/DTLS are strongly advised to pay attention to future developments. In particular, a lthough it is known that the creation of quantum computers will have a significa nt impact on the security of cryptographic primitives and the technologies that use them, currently post-quantum cryptography is a work in progress and it is to o early to make recommendations; once the relevant specifications are standardiz ed in the IETF or elsewhere, this document should be updated to reflect best pra ctices at that time.</t> <t>Naturally, future attacks are likely, and this document cannot address them. Those who implement and deploy TLS/DTLS and protocols based on TLS/DTLS a re strongly advised to pay attention to future developments. In particular, alt hough it is known that the creation of quantum computers will have a significant impact on the security of cryptographic primitives and the technologies that us e them, currently post-quantum cryptography is a work in progress and it is too early to make recommendations; once the relevant specifications are standardized in the IETF or elsewhere, this document should be updated to reflect best pract ices at that time.</t>
<t>As noted, the TLS 1.3 specification resolves many of the vulnerabilitie s listed in this document. A system that deploys TLS 1.3 should have fewer vulne rabilities than TLS 1.2 or below. Therefore, this document replaces <xref target ="RFC7525"/>, with an explicit goal to encourage migration of most uses of TLS 1 .2 to TLS 1.3.</t> <t>As noted, the TLS 1.3 specification resolves many of the vulnerabilitie s listed in this document. A system that deploys TLS 1.3 should have fewer vulne rabilities than TLS 1.2 or below. Therefore, this document replaces <xref target ="RFC7525"/>, with an explicit goal to encourage migration of most uses of TLS 1 .2 to TLS 1.3.</t>
<t>These are minimum recommendations for the use of TLS in the vast majori ty of implementation and deployment scenarios, with the exception of unauthentic ated TLS (see <xref target="applicability"/>). Other specifications that referen ce this document can have stricter requirements related to one or more aspects o f the protocol, based on their particular circumstances (e.g., for use with a pa rticular application protocol); when that is the case, implementers are advised to adhere to those stricter requirements. Furthermore, this document provides a floor, not a ceiling: where feasible, administrators of services are encouraged to go beyond the minimum support available in implementations to provide the str ongest security possible. For example, based on knowledge about the deployed bas e for an existing application protocol and a cost-benefit analysis regarding sec urity strength vs. interoperability, a given service provider might decide to di sable TLS 1.2 entirely and offer only TLS 1.3.</t> <t>These are minimum recommendations for the use of TLS in the vast majori ty of implementation and deployment scenarios, with the exception of unauthentic ated TLS (see <xref target="applicability"/>). Other specifications that referen ce this document can have stricter requirements related to one or more aspects o f the protocol, based on their particular circumstances (e.g., for use with a sp ecific application protocol); when that is the case, implementers are advised to adhere to those stricter requirements. Furthermore, this document provides a fl oor, not a ceiling: where feasible, administrators of services are encouraged to go beyond the minimum support available in implementations to provide the stron gest security possible. For example, based on knowledge about the deployed base for an existing application protocol and a cost-benefit analysis regarding secur ity strength vs. interoperability, a given service provider might decide to disa ble TLS 1.2 entirely and offer only TLS 1.3.</t>
<t>Community knowledge about the strength of various algorithms and feasib le attacks can change quickly, and experience shows that a Best Current Practice (BCP) document about security is a point-in-time statement. Readers are advise d to seek out any errata or updates that apply to this document.</t> <t>Community knowledge about the strength of various algorithms and feasib le attacks can change quickly, and experience shows that a Best Current Practice (BCP) document about security is a point-in-time statement. Readers are advise d to seek out any errata or updates that apply to this document.</t>
<t>This document updates <xref target="RFC5288"/> in view of the <xref tar get="Boeck2016"/> attack. See <xref target="nonce-reuse"/> for the details.</t> <t>This document updates <xref target="RFC5288"/> in view of the <xref tar get="Boeck2016"/> attack. See <xref target="nonce-reuse"/> for the details.</t>
<t>This document updates <xref target="RFC6066"/> in view of the <xref tar get="ALPACA"/> attack. See <xref target="sni"/> for the details.</t> <t>This document updates <xref target="RFC6066"/> in view of the <xref tar get="ALPACA"/> attack. See <xref target="sni"/> for the details.</t>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>A number of security-related terms in this document are used in the sen se defined in <xref target="RFC4949"/>, <t>A number of security-related terms in this document are used in the sen se defined in <xref target="RFC4949"/>,
including "attack", "authentication", "certificate", "cipher", "compromise", "co nfidentiality", including "attack", "authentication", "certificate", "cipher", "compromise", "co nfidentiality",
"credential", "data integrity", "encryption", "forward secrecy", "key", "key len gth", "self-signed certificate", "credential", "data integrity", "encryption", "forward secrecy", "key", "key len gth", "self-signed certificate",
"strength", and "strong".</t> "strength", and "strong".</t>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
only when, they target="RFC8174"/> when, and only when, they appear in all capitals, as shown
appear in all capitals, as shown here.</t> here.</t>
</section> </section>
<section anchor="rec"> <section anchor="rec">
<name>General Recommendations</name> <name>General Recommendations</name>
<t>This section provides general recommendations on the secure use of TLS. Recommendations related to cipher suites are discussed in the following section .</t> <t>This section provides general recommendations on the secure use of TLS. Recommendations related to cipher suites are discussed in the following section .</t>
<section anchor="protocol-versions"> <section anchor="protocol-versions">
<name>Protocol Versions</name> <name>Protocol Versions</name>
<section anchor="rec-versions"> <section anchor="rec-versions">
<name>SSL/TLS Protocol Versions</name> <name>SSL/TLS Protocol Versions</name>
<t>It is important both to stop using old, less secure versions of SSL /TLS and to start using modern, more secure versions; therefore, the following a re the recommendations concerning TLS/SSL protocol versions:</t> <t>It is important both to stop using old, less secure versions of SSL /TLS and to start using modern, more secure versions; therefore, the following a re the recommendations concerning TLS/SSL protocol versions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Implementations <bcp14>MUST NOT</bcp14> negotiate SSL version 2 . </t> <t>Implementations <bcp14>MUST NOT</bcp14> negotiate SSL version 2 . </t>
<t> <t>
Rationale: Today, SSLv2 is considered insecure <xref target="RFC6176"/>.</t> Rationale: Today, SSLv2 is considered insecure <xref target="RFC6176"/>.</t>
</li> </li>
<li> <li>
<t>Implementations <bcp14>MUST NOT</bcp14> negotiate SSL version 3 . </t> <t>Implementations <bcp14>MUST NOT</bcp14> negotiate SSL version 3 . </t>
<t> <t>
Rationale: SSLv3 <xref target="RFC6101"/> was an improvement over SSLv2 and plug ged some significant security holes but did not support strong cipher suites. SS Lv3 does not support TLS extensions, some of which (e.g., renegotiation_info <xr ef target="RFC5746"/>) are security-critical. In addition, with the emergence o f the POODLE attack <xref target="POODLE"/>, SSLv3 is now widely recognized as f undamentally insecure. See <xref target="DEP-SSLv3"/> for further details.</t> Rationale: SSLv3 <xref target="RFC6101"/> was an improvement over SSLv2 and plug ged some significant security holes but did not support strong cipher suites. SS Lv3 does not support TLS extensions, some of which (e.g., renegotiation_info <xr ef target="RFC5746"/>) are security critical. In addition, with the emergence o f the Padding Oracle On Downgraded Legacy Encryption (POODLE) attack <xref targe t="POODLE"/>, SSLv3 is now widely recognized as fundamentally insecure. See <xr ef target="RFC7568"/> for further details.</t>
</li> </li>
<li> <li>
<t>Implementations <bcp14>MUST NOT</bcp14> negotiate TLS version 1 .0 <xref target="RFC2246"/>. </t> <t>Implementations <bcp14>MUST NOT</bcp14> negotiate TLS version 1 .0 <xref target="RFC2246"/>. </t>
<t> <t>
Rationale: TLS 1.0 (published in 1999) does not support many modern, strong ciph er suites. In addition, TLS 1.0 lacks a per-record Initialization Vector (IV) fo r CBC-based cipher suites and does not warn against common padding errors. This and other recommendations in this section are in line with <xref target="RFC8996 "/>.</t> Rationale: TLS 1.0 (published in 1999) does not support many modern, strong ciph er suites. In addition, TLS 1.0 lacks a per-record Initialization Vector (IV) fo r cipher suites based on cipher block chaining (CBC) and does not warn against c ommon padding errors. This and other recommendations in this section are in line with <xref target="RFC8996"/>.</t>
</li> </li>
<li> <li>
<t>Implementations <bcp14>MUST NOT</bcp14> negotiate TLS version 1 .1 <xref target="RFC4346"/>. </t> <t>Implementations <bcp14>MUST NOT</bcp14> negotiate TLS version 1 .1 <xref target="RFC4346"/>. </t>
<t> <t>
Rationale: TLS 1.1 (published in 2006) is a security improvement over TLS 1.0 bu t still does not support certain stronger cipher suites that were introduced wit h the standardization of TLS 1.2 in 2008, including the cipher suites recommende d for TLS 1.2 by this document (see <xref target="rec-cipher"/> below).</t> Rationale: TLS 1.1 (published in 2006) is a security improvement over TLS 1.0 bu t still does not support certain stronger cipher suites that were introduced wit h the standardization of TLS 1.2 in 2008, including the cipher suites recommende d for TLS 1.2 by this document (see <xref target="rec-cipher"/> below).</t>
</li> </li>
<li> <li>
<t>Implementations <bcp14>MUST</bcp14> support TLS 1.2 <xref targe t="RFC5246"/>. </t> <t>Implementations <bcp14>MUST</bcp14> support TLS 1.2 <xref targe t="RFC5246"/>. </t>
<t> <t>
Rationale: TLS 1.2 is implemented and deployed more widely than TLS 1.3 at this time and, when the recommendations in this document are followed to mitigate kno wn attacks, the use of TLS 1.2 is as safe as the use of TLS 1.3. In most applic ation protocols that re-use TLS and DTLS, there is no immediate need to migrate solely to TLS 1.3 and proactively deprecate TLS 1.2, especially because the exis tence of large numbers of application clients dependent on TLS libraries or oper ating systems that do not yet support TLS 1.3 would introduce significant intero perability issues, thus harming security more than helping it. Nevertheless, it is expected that a future version of this BCP will deprecate the use of TLS 1.2 when it is appropriate to do so.</t> Rationale: TLS 1.2 is implemented and deployed more widely than TLS 1.3 at this time, and when the recommendations in this document are followed to mitigate kno wn attacks, the use of TLS 1.2 is as safe as the use of TLS 1.3. In most applic ation protocols that reuse TLS and DTLS, there is no immediate need to migrate s olely to TLS 1.3. Indeed, because many application clients are dependent on TLS libraries or operating systems that do not yet support TLS 1.3, proactively depr ecating TLS 1.2 would introduce significant interoperability issues, thus harmin g security more than helping it. Nevertheless, it is expected that a future ver sion of this BCP will deprecate the use of TLS 1.2 when it is appropriate to do so.</t>
</li> </li>
<li> <li>
<t>Implementations <bcp14>SHOULD</bcp14> support TLS 1.3 <xref tar get="RFC8446"/> and, if implemented, <bcp14>MUST</bcp14> prefer to negotiate TLS 1.3 over earlier versions of TLS. </t> <t>Implementations <bcp14>SHOULD</bcp14> support TLS 1.3 <xref tar get="RFC8446"/> and, if implemented, <bcp14>MUST</bcp14> prefer to negotiate TLS 1.3 over earlier versions of TLS. </t>
<t> <t>
Rationale: TLS 1.3 is a major overhaul to the protocol and resolves many of the security issues with TLS 1.2. To the extent that an implementation supports TLS 1.2 (even if it defaults to TLS 1.3), it <bcp14>MUST</bcp14> follow the recommen dations regarding TLS 1.2 specified in this document.</t> Rationale: TLS 1.3 is a major overhaul to the protocol and resolves many of the security issues with TLS 1.2. To the extent that an implementation supports TLS 1.2 (even if it defaults to TLS 1.3), it <bcp14>MUST</bcp14> follow the recommen dations regarding TLS 1.2 specified in this document.</t>
</li> </li>
<li> <li>
<t>New transport protocols that integrate the TLS/DTLS handshake p rotocol and/or record layer <bcp14>MUST</bcp14> use only TLS/DTLS 1.3 (for insta nce, QUIC <xref target="RFC9001"/> took this approach). New application protocol s that employ TLS/DTLS for channel or session encryption <bcp14>MUST</bcp14> int egrate with both TLS/DTLS versions 1.2 and 1.3; nevertheless, in rare cases wher e broad interoperability is not a concern, application protocol designers <bcp14 >MAY</bcp14> choose to forego TLS 1.2. </t> <t>New transport protocols that integrate the TLS/DTLS handshake p rotocol and/or record layer <bcp14>MUST</bcp14> use only TLS/DTLS 1.3 (for insta nce, QUIC <xref target="RFC9001"/> took this approach). New application protocol s that employ TLS/DTLS for channel or session encryption <bcp14>MUST</bcp14> int egrate with both TLS/DTLS versions 1.2 and 1.3; nevertheless, in rare cases wher e broad interoperability is not a concern, application protocol designers <bcp14 >MAY</bcp14> choose to forego TLS 1.2. </t>
<t> <t>
Rationale: Secure deployment of TLS 1.3 is significantly easier and less error-p rone than secure deployment of TLS 1.2. When designing a new secure transport pr otocol such as QUIC, there is no reason to support TLS 1.2. By contrast, new app lication protocols that re-use TLS <bcp14>MAY</bcp14> support both TLS 1.3 and T LS 1.2 in order to take advantage of underlying library or operating system supp ort for both versions.</t> Rationale: Secure deployment of TLS 1.3 is significantly easier and less error p rone than secure deployment of TLS 1.2. When designing a new secure transport pr otocol such as QUIC, there is no reason to support TLS 1.2. By contrast, new app lication protocols that reuse TLS need to support both TLS 1.3 and TLS 1.2 in or der to take advantage of underlying library or operating system support for both versions.</t>
</li> </li>
</ul> </ul>
<t>This BCP applies to TLS 1.3, TLS 1.2, and earlier versions. It is n ot safe for readers to assume that the recommendations in this BCP apply to any future version of TLS.</t> <t>This BCP applies to TLS 1.3, TLS 1.2, and earlier versions. It is n ot safe for readers to assume that the recommendations in this BCP apply to any future version of TLS.</t>
</section> </section>
<section anchor="dtls-protocol-versions"> <section anchor="dtls-protocol-versions">
<name>DTLS Protocol Versions</name> <name>DTLS Protocol Versions</name>
<t>DTLS, an adaptation of TLS for UDP datagrams, was introduced when T LS 1.1 was published. The following are the recommendations with respect to DTL S:</t> <t>DTLS, an adaptation of TLS for UDP datagrams, was introduced when T LS 1.1 was published. The following are the recommendations with respect to DTL S:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Implementations <bcp14>MUST NOT</bcp14> negotiate DTLS version 1.0 <xref target="RFC4347"/>. </t> <t>Implementations <bcp14>MUST NOT</bcp14> negotiate DTLS version 1.0 <xref target="RFC4347"/>. </t>
<t> <t>
Version 1.0 of DTLS correlates to version 1.1 of TLS (see above).</t> Version 1.0 of DTLS correlates to version 1.1 of TLS (see above).</t>
</li> </li>
<li> <li>
<t>Implementations <bcp14>MUST</bcp14> support DTLS 1.2 <xref targ et="RFC6347"/>. </t> <t>Implementations <bcp14>MUST</bcp14> support DTLS 1.2 <xref targ et="RFC6347"/>. </t>
<t> <t>
skipping to change at line 154 skipping to change at line 175
</li> </li>
<li> <li>
<t>Implementations <bcp14>SHOULD</bcp14> support DTLS 1.3 <xref ta rget="RFC9147"/> and, if implemented, <bcp14>MUST</bcp14> prefer to negotiate DT LS version 1.3 over earlier versions of DTLS. </t> <t>Implementations <bcp14>SHOULD</bcp14> support DTLS 1.3 <xref ta rget="RFC9147"/> and, if implemented, <bcp14>MUST</bcp14> prefer to negotiate DT LS version 1.3 over earlier versions of DTLS. </t>
<t> <t>
Version 1.3 of DTLS correlates to version 1.3 of TLS (see above).</t> Version 1.3 of DTLS correlates to version 1.3 of TLS (see above).</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="rec-fallback"> <section anchor="rec-fallback">
<name>Fallback to Lower Versions</name> <name>Fallback to Lower Versions</name>
<t>TLS/DTLS 1.2 clients <bcp14>MUST NOT</bcp14> fall back to earlier T LS versions, since those versions have been deprecated <xref target="RFC8996"/>. We note that as a result of that, the downgrade-protection SCSV (Signaling Ciph er Suite Value) mechanism <xref target="RFC7507"/> is no longer needed for clien ts. In addition, TLS 1.3 implements a new version negotiation mechanism.</t> <t>TLS/DTLS 1.2 clients <bcp14>MUST NOT</bcp14> fall back to earlier T LS versions, since those versions have been deprecated <xref target="RFC8996"/>. As a result, the downgrade-protection Signaling Cipher Suite Value (SCSV) mecha nism <xref target="RFC7507"/> is no longer needed for clients. In addition, TLS 1.3 implements a new version-negotiation mechanism.</t>
</section> </section>
</section> </section>
<section anchor="strict-tls"> <section anchor="strict-tls">
<name>Strict TLS</name> <name>Strict TLS</name>
<t>The following recommendations are provided to help prevent SSL Stripp ing and STARTTLS Command Injection (attacks that are summarized in <xref target= "RFC7457"/>):</t> <t>The following recommendations are provided to help prevent "SSL Strip ping" and STARTTLS command injection (attacks that are summarized in <xref targe t="RFC7457"/>):</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Many existing application protocols were designed before the use o f TLS became common. These protocols typically support TLS in one of two ways: e ither via a separate port for TLS-only communication (e.g., port 443 for HTTPS) or via a method for dynamically upgrading a channel from unencrypted to TLS-prot ected (e.g., STARTTLS, which is used in protocols such as IMAP and XMPP). Regard less of the mechanism for protecting the communication channel (TLS-only port or dynamic upgrade), what matters is the end state of the channel. When a protocol defines both a dynamic upgrade method and a separate TLS-only method, then the separate TLS-only method <bcp14>MUST</bcp14> be supported by implementations and <bcp14>MUST</bcp14> be configured by administrators to be used in preference to the dynamic upgrade method. When a protocol supports only a dynamic upgrade, i mplementations <bcp14>MUST</bcp14> provide a way for administrators to set a str ict local policy that forbids use of plaintext in the absence of a negotiated TL S channel, and administrators <bcp14>MUST</bcp14> use this policy.</li> <li>Many existing application protocols were designed before the use o f TLS became common. These protocols typically support TLS in one of two ways: e ither via a separate port for TLS-only communication (e.g., port 443 for HTTPS) or via a method for dynamically upgrading a channel from unencrypted to TLS prot ected (e.g., STARTTLS, which is used in protocols such as IMAP and XMPP). Regard less of the mechanism for protecting the communication channel (TLS-only port or dynamic upgrade), what matters is the end state of the channel. When a protocol defines both a dynamic upgrade method and a separate TLS-only method, then the separate TLS-only method <bcp14>MUST</bcp14> be supported by implementations and <bcp14>MUST</bcp14> be configured by administrators to be used in preference to the dynamic upgrade method. When a protocol supports only a dynamic upgrade me thod, implementations <bcp14>MUST</bcp14> provide a way for administrators to se t a strict local policy that forbids use of plaintext in the absence of a negoti ated TLS channel, and administrators <bcp14>MUST</bcp14> use this policy.</li>
<li>HTTP client and server implementations intended for use in the Wor ld Wide Web (see <li>HTTP client and server implementations intended for use in the Wor ld Wide Web (see
<xref target="applicability"/>) <bcp14>MUST</bcp14> support the HTTP Strict Tran sport Security (HSTS) header <xref target="applicability"/>) <bcp14>MUST</bcp14> support the HTTP Strict Tran sport Security (HSTS) header
field <xref target="RFC6797"/>, so that Web servers can advertise that they are willing to field <xref target="RFC6797"/> so that web servers can advertise that they are w illing to
accept TLS-only clients. Web servers <bcp14>SHOULD</bcp14> use HSTS to indicate that they are accept TLS-only clients. Web servers <bcp14>SHOULD</bcp14> use HSTS to indicate that they are
willing to accept TLS-only clients, unless they are deployed in such a way that willing to accept TLS-only clients, unless they are deployed in such a way that
using HSTS would in fact weaken overall security (e.g., it can be problematic to using HSTS would in fact weaken overall security (e.g., it can be problematic to
use HSTS with self-signed certificates, as described in <xref section="11.3" sec tionFormat="of" target="RFC6797"/>). use HSTS with self-signed certificates, as described in <xref section="11.3" sec tionFormat="of" target="RFC6797"/>).
Similar technologies exist for non-HTTP application protocols, such as MTA-STS f or Similar technologies exist for non-HTTP application protocols, such as Mail Tran sfer Agent Strict Transport Security (MTA-STS) for
mail transfer agents <xref target="RFC8461"/> and methods based on DNS-Based Aut hentication of mail transfer agents <xref target="RFC8461"/> and methods based on DNS-Based Aut hentication of
Named Entities (DANE) <xref target="RFC6698"/> for SMTP <xref target="DANE-SMTP" /> and XMPP <xref target="RFC7712"/>.</li> Named Entities (DANE) <xref target="RFC6698"/> for SMTP <xref target="RFC7672"/> and XMPP <xref target="RFC7712"/>.</li>
</ul> </ul>
<t>Rationale: Combining unprotected and TLS-protected communication open s the way to SSL Stripping and similar attacks, since an initial part of the com munication is not integrity protected and therefore can be manipulated by an att acker whose goal is to keep the communication in the clear.</t> <t>Rationale: Combining unprotected and TLS-protected communication open s the way to SSL Stripping and similar attacks, since an initial part of the com munication is not integrity protected and therefore can be manipulated by an att acker whose goal is to keep the communication in the clear.</t>
</section> </section>
<section anchor="compression"> <section anchor="compression">
<name>Compression</name> <name>Compression</name>
<t anchor="rec-compress">In order to help prevent compression-related at tacks (summarized in <xref section="2.6" sectionFormat="of" target="RFC7457"/>), when using TLS 1.2 implementations and deployments <bcp14>SHOULD NOT</bcp14> su pport <t anchor="rec-compress">In order to help prevent compression-related at tacks (summarized in <xref section="2.6" sectionFormat="of" target="RFC7457"/>) when using TLS 1.2, implementations and deployments <bcp14>SHOULD NOT</bcp14> su pport
TLS-level compression (<xref section="6.2.2" sectionFormat="of" target="RFC5246" />); the only exception is when TLS-level compression (<xref section="6.2.2" sectionFormat="of" target="RFC5246" />); the only exception is when
the application protocol in question has been proved not to be open to such atta the application protocol in question has been proven not to be open to such atta
cks, cks.
however even in this case extreme caution is warranted because of the potential However, even in this case, extreme caution is warranted because of the potentia
for l for
future attacks related to TLS compression. More specifically, the HTTP protocol future attacks related to TLS compression. More specifically, the HTTP pr
is known to be vulnerable to compression-related attacks. Note: this recommendat otocol is known to be vulnerable to compression-related attacks. (This recommend
ion applies to TLS 1.2 only, because compression has been removed from TLS 1.3.< ation applies to TLS 1.2 only, because compression has been removed from TLS 1.3
/t> .)</t>
<t>Rationale: TLS compression has been subject to security attacks, such
as the CRIME attack.</t> <t>Rationale: TLS compression has been subject to security attacks such as the C
<t>Implementers should note that compression at higher protocol levels c ompression Ratio Info-leak Made Easy (CRIME) attack.</t>
an allow an active attacker to extract cleartext information from the connection <t>Implementers should note that compression at higher protocol levels c
. The BREACH attack is one such case. These issues can only be mitigated outside an allow an active attacker to extract cleartext information from the connection
of TLS and are thus outside the scope of this document. See <xref section="2.6" . The Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypert
sectionFormat="of" target="RFC7457"/> for further details.</t> ext (BREACH) attack is one such case. These issues can only be mitigated outside
of TLS and are thus outside the scope of this document. See <xref section="2.6"
sectionFormat="of" target="RFC7457"/> for further details.</t>
<section anchor="certificate-compression"> <section anchor="certificate-compression">
<name> Certificate Compression</name> <name>Certificate Compression</name>
<t>Certificate chains often take up the majority of the bytes transmit <t>Certificate chains often take up most of the bytes transmitted duri
ted during ng
the handshake. In order to manage their size, some or all of the following the handshake. In order to manage their size, some or all of the following
methods can be employed (see also <xref section="4" sectionFormat="of" target="R FC9191"/> for further suggestions):</t> methods can be employed (see also <xref section="4" sectionFormat="of" target="R FC9191"/> for further suggestions):</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Limit the number of names or extensions;</li> <li>Limit the number of names or extensions.</li>
<li>Use keys with small public key representations, like ECDSA;</li> <li>Use keys with small public key representations, like the Ellipti
c Curve Digital Signature Algorithm (ECDSA).</li>
<li>Use certificate compression.</li> <li>Use certificate compression.</li>
</ul> </ul>
<t>To achieve the latter, TLS 1.3 defines the <tt>compress_certificate </tt> extension in <t>To achieve the latter, TLS 1.3 defines the <tt>compress_certificate </tt> extension in
<xref target="RFC8879"/>. See also <xref section="5" sectionFormat="of" target= "RFC8879"/> for security and privacy <xref target="RFC8879"/>. See also <xref section="5" sectionFormat="of" target= "RFC8879"/> for security and privacy
considerations associated with its use. For the avoidance of doubt, CRIME-style attacks on TLS considerations associated with its use. For the avoidance of doubt, CRIME-style attacks on TLS
compression do not apply to certificate compression.</t> compression do not apply to certificate compression.</t>
<t>Due to the strong likelihood of middlebox interference, <t>Due to the strong likelihood of middlebox interference,
RFC8879-style compression has not been made available in compression in the style of <xref target="RFC8879"/> has not been made available in
TLS 1.2. In theory, the <tt>cached_info</tt> extension defined in <xref target= "RFC7924"/> could TLS 1.2. In theory, the <tt>cached_info</tt> extension defined in <xref target= "RFC7924"/> could
be used, but it is not widely enough supported to be considered a practical be used, but it is not supported widely enough to be considered a practical
alternative.</t> alternative.</t>
</section> </section>
</section> </section>
<section anchor="rec-resume"> <section anchor="rec-resume">
<name>TLS Session Resumption</name> <name>TLS Session Resumption</name>
<t>Session resumption drastically reduces the number of full TLS handsha kes and thus is an essential <t>Session resumption drastically reduces the number of full TLS handsha kes and thus is an essential
performance feature for most deployments.</t> performance feature for most deployments.</t>
<t>Stateless session resumption with session tickets is a popular strate gy. For TLS 1.2, it is specified in <t>Stateless session resumption with session tickets is a popular strate gy. For TLS 1.2, it is specified in
<xref target="RFC5077"/>. For TLS 1.3, a more secure PSK-based mechanism is des cribed in <xref target="RFC5077"/>. For TLS 1.3, a more secure mechanism based on the use of a pre-shared key (PSK) is described in
<xref section="4.6.1" sectionFormat="of" target="RFC8446"/>. See <xref target="S pringall16"/> for a quantitative study of the risks induced by TLS cryptographic "shortcuts", including session resumption.</t> <xref section="4.6.1" sectionFormat="of" target="RFC8446"/>. See <xref target="S pringall16"/> for a quantitative study of the risks induced by TLS cryptographic "shortcuts", including session resumption.</t>
<t>When it is used, the resumption information <bcp14>MUST</bcp14> <t>When it is used, the resumption information <bcp14>MUST</bcp14>
be authenticated and encrypted to prevent modification or eavesdropping by an at tacker. be authenticated and encrypted to prevent modification or eavesdropping by an at tacker.
Further recommendations apply to session tickets:</t> Further recommendations apply to session tickets:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>A strong cipher <bcp14>MUST</bcp14> be used when encrypting the ti cket (at least as strong as the main TLS cipher suite).</li> <li>A strong cipher <bcp14>MUST</bcp14> be used when encrypting the ti cket (at least as strong as the main TLS cipher suite).</li>
<li>Ticket-encryption keys <bcp14>MUST</bcp14> be changed regularly, e .g., once every week, so as not to negate the benefits of forward secrecy (see < xref target="sec-pfs"/> for details on forward secrecy). Old ticket-encryption k eys <bcp14>MUST</bcp14> be destroyed at the end of the validity period.</li> <li>Ticket-encryption keys <bcp14>MUST</bcp14> be changed regularly, e .g., once every week, so as not to negate the benefits of forward secrecy (see < xref target="sec-pfs"/> for details on forward secrecy). Old ticket-encryption k eys <bcp14>MUST</bcp14> be destroyed at the end of the validity period.</li>
<li>For similar reasons, session ticket validity <bcp14>MUST</bcp14> b e limited to a reasonable duration (e.g., half as long as ticket-encryption key validity).</li> <li>For similar reasons, session ticket validity <bcp14>MUST</bcp14> b e limited to a reasonable duration (e.g., half as long as ticket-encryption key validity).</li>
<li>TLS 1.2 does not roll the session key forward within a single sess ion. Thus, to prevent an attack where the server's ticket-encryption key is stol en and used to decrypt the entire content of a session (negating the concept of forward secrecy), a TLS 1.2 server <bcp14>SHOULD NOT</bcp14> resume sessions tha t are too old, e.g. sessions that have been open longer than two ticket-encrypti on key rotation periods.</li> <li>TLS 1.2 does not roll the session key forward within a single sess ion. Thus, to prevent an attack where the server's ticket-encryption key is stol en and used to decrypt the entire content of a session (negating the concept of forward secrecy), a TLS 1.2 server <bcp14>SHOULD NOT</bcp14> resume sessions tha t are too old, e.g., sessions that have been open longer than two ticket-encrypt ion key rotation periods.</li>
</ul> </ul>
<t>Rationale: session resumption is another kind of TLS handshake, and t herefore must be as secure as the initial handshake. This document (<xref target ="detail"/>) recommends the use of cipher suites that provide forward secrecy, i .e. that prevent an attacker who gains momentary access to the TLS endpoint (eit her client or server) and its secrets from reading either past or future communi cation. The tickets must be managed so as not to negate this security property.< /t> <t>Rationale: Session resumption is another kind of TLS handshake and th erefore must be as secure as the initial handshake. This document (<xref target= "detail"/>) recommends the use of cipher suites that provide forward secrecy, i. e., that prevent an attacker who gains momentary access to the TLS endpoint (eit her client or server) and its secrets from reading either past or future communi cation. The tickets must be managed so as not to negate this security property.< /t>
<t>TLS 1.3 provides the powerful option of forward secrecy even within a long-lived connection <t>TLS 1.3 provides the powerful option of forward secrecy even within a long-lived connection
that is periodically resumed. <xref section="2.2" sectionFormat="of" target="RFC 8446"/> recommends that clients <bcp14>SHOULD</bcp14> that is periodically resumed. <xref section="2.2" sectionFormat="of" target="RFC 8446"/> recommends that clients <bcp14>SHOULD</bcp14>
send a "key_share" when initiating session resumption. send a "key_share" when initiating session resumption.
In order to gain forward secrecy, this document recommends that server implement ations <bcp14>SHOULD</bcp14> In order to gain forward secrecy, this document recommends that server implement ations <bcp14>SHOULD</bcp14>
select the "psk_dhe_ke" PSK key exchange mode and select the "psk_dhe_ke" PSK key exchange mode and
respond with a "key_share", to complete an ECDHE exchange on each session resump tion. respond with a "key_share" to complete an Ephemeral Elliptic Curve Diffie-Hellma n (ECDHE) exchange on each session resumption.
As a more performant alternative, server implementations <bcp14>MAY</bcp14> refr ain from responding with a As a more performant alternative, server implementations <bcp14>MAY</bcp14> refr ain from responding with a
"key_share" until a certain amount of time (e.g., measured in hours) has passed since the last "key_share" until a certain amount of time (e.g., measured in hours) has passed since the last
ECDHE exchange; this implies that the "key_share" operation would not occur for the presumed ECDHE exchange; this implies that the "key_share" operation would not occur for the presumed
majority of session resumption requests occurring within a few hours, while stil l ensuring majority of session resumption requests (which would occur within a few hours) w hile still ensuring
forward secrecy for longer-lived sessions.</t> forward secrecy for longer-lived sessions.</t>
<t>TLS session resumption introduces potential privacy issues where the server is able <t>TLS session resumption introduces potential privacy issues where the server is able
to track the client, in some cases indefinitely. See <xref target="Sy2018"/> for more details.</t> to track the client, in some cases indefinitely. See <xref target="Sy2018"/> for more details.</t>
</section> </section>
<section anchor="renegotiation-in-tls-12"> <section anchor="renegotiation-in-tls-12">
<name>Renegotiation in TLS 1.2</name> <name>Renegotiation in TLS 1.2</name>
<t>The recommendations in this section apply to TLS 1.2 only, because re negotiation has been removed from TLS 1.3.</t> <t>The recommendations in this section apply to TLS 1.2 only, because re negotiation has been removed from TLS 1.3.</t>
<t>Renegotiation in TLS 1.2 is a handshake that establishes new cryptogr aphic parameters for an existing session. The mechanism existed in TLS 1.2 and i n earlier protocol versions, and was improved following several major attacks in cluding a plaintext injection attack, CVE-2009-3555 <xref target="CVE"/>.</t> <t>Renegotiation in TLS 1.2 is a handshake that establishes new cryptogr aphic parameters for an existing session. The mechanism existed in TLS 1.2 and i n earlier protocol versions and was improved following several major attacks inc luding a plaintext injection attack, CVE-2009-3555 <xref target="CVE"/>.</t>
<t>TLS 1.2 clients and servers <bcp14>MUST</bcp14> implement the <tt>ren egotiation_info</tt> extension, as defined in <xref target="RFC5746"/>.</t> <t>TLS 1.2 clients and servers <bcp14>MUST</bcp14> implement the <tt>ren egotiation_info</tt> extension, as defined in <xref target="RFC5746"/>.</t>
<t>TLS 1.2 clients <bcp14>MUST</bcp14> send <tt>renegotiation_info</tt> in the Client Hello. If the server does not acknowledge the extension, the clie nt <bcp14>MUST</bcp14> generate a fatal <tt>handshake_failure</tt> alert prior t o terminating the connection.</t> <t>TLS 1.2 clients <bcp14>MUST</bcp14> send <tt>renegotiation_info</tt> in the Client Hello. If the server does not acknowledge the extension, the clie nt <bcp14>MUST</bcp14> generate a fatal <tt>handshake_failure</tt> alert prior t o terminating the connection.</t>
<t>Rationale: It is not safe for a client to connect to a TLS 1.2 server <t>Rationale: It is not safe for a client to connect to a TLS 1.2 server
that does not support <tt>renegotiation_info</tt>, regardless of whether either that does not support <tt>renegotiation_info</tt> regardless of whether either
endpoint actually implements renegotiation. See also <xref section="4.1" secti endpoint actually implements renegotiation. See also <xref section="4.1" sectio
onFormat="of" target="RFC5746"/>.</t> nFormat="of" target="RFC5746"/>.</t>
<t>A related attack resulting from TLS session parameters not being prop <t>A related attack resulting from TLS session parameters not being prop
erly authenticated is Triple Handshake <xref target="triple-handshake"/>. To add erly authenticated is a Triple Handshake <xref target="Triple-Handshake"/>. To a
ress this attack, TLS 1.2 implementations <bcp14>MUST</bcp14> support the <tt>ex ddress this attack, TLS 1.2 implementations <bcp14>MUST</bcp14> support the <tt>
tended_master_secret</tt> extension defined in <xref target="RFC7627"/>.</t> extended_master_secret</tt> extension defined in <xref target="RFC7627"/>.</t>
</section> </section>
<section anchor="post-handshake-authentication"> <section anchor="post-handshake-authentication">
<name>Post-Handshake Authentication</name> <name>Post-Handshake Authentication</name>
<t>Renegotiation in TLS 1.2 was (partially) replaced in TLS 1.3 by separ ate post-handshake authentication and key update mechanisms. In the context of protocols that multiplex requests over a single connection (such as HTTP/2 <xref target="HTTP2"/>), post-handshake authentication has the same problems as TLS 1 .2 renegotiation. Multiplexed protocols <bcp14>SHOULD</bcp14> follow the advice provided for HTTP/2 in <xref section="9.3.2" sectionFormat="of" target="HTTP2"/ >.</t> <t>Renegotiation in TLS 1.2 was (partially) replaced in TLS 1.3 by separ ate post-handshake authentication and key update mechanisms. In the context of protocols that multiplex requests over a single connection (such as HTTP/2 <xref target="RFC9113"/>), post-handshake authentication has the same problems as TLS 1.2 renegotiation. Multiplexed protocols <bcp14>SHOULD</bcp14> follow the advic e provided for HTTP/2 in <xref section="9.2.3" sectionFormat="of" target="RFC911 3"/>.</t>
</section> </section>
<section anchor="sni"> <section anchor="sni">
<name>Server Name Indication (SNI)</name> <name>Server Name Indication (SNI)</name>
<t>TLS implementations <bcp14>MUST</bcp14> support the Server Name Indic ation (SNI) extension defined in <xref section="3" sectionFormat="of" target="RF C6066"/> for those higher-level protocols that would benefit from it, including HTTPS. However, the actual use of SNI in particular circumstances is a matter of local policy. At the time of writing, a technology for encrypting the SNI (cal led Encrypted Client Hello) is being worked on in the TLS Working Group <xref ta rget="I-D.ietf-tls-esni"/>. Once that method has been standardized and widely i mplemented, it will likely be appropriate to recommend its usage in a future ver sion of this BCP.</t> <t>TLS implementations <bcp14>MUST</bcp14> support the Server Name Indic ation (SNI) extension defined in <xref section="3" sectionFormat="of" target="RF C6066"/> for those higher-level protocols that would benefit from it, including HTTPS. However, the actual use of SNI in particular circumstances is a matter of local policy. At the time of writing, a technology for encrypting the SNI (cal led Encrypted Client Hello) is being worked on in the TLS Working Group <xref ta rget="I-D.ietf-tls-esni"/>. Once that method has been standardized and widely i mplemented, it will likely be appropriate to recommend its usage in a future ver sion of this BCP.</t>
<t>Rationale: SNI supports deployment of multiple TLS-protected virtual servers on a single <t>Rationale: SNI supports deployment of multiple TLS-protected virtual servers on a single
address, and therefore enables fine-grained security for these virtual ser vers, address, and therefore enables fine-grained security for these virtual ser vers,
by allowing each one to have its own certificate. However, SNI also leaks the by allowing each one to have its own certificate. However, SNI also leaks the
target domain for a given connection; this information leak will be closed by target domain for a given connection; this information leak will be closed by
use of TLS Encrypted Client Hello once that method has been standardized.< /t> use of TLS Encrypted Client Hello once that method has been standardized.< /t>
<t>In order to prevent the attacks described in <xref target="ALPACA"/>, a server that does not <t>In order to prevent the attacks described in <xref target="ALPACA"/>, a server that does not
recognize the presented server name <bcp14>SHOULD NOT</bcp14> continue the hands hake and recognize the presented server name <bcp14>SHOULD NOT</bcp14> continue the hands hake and
instead <bcp14>SHOULD</bcp14> fail with a fatal-level <tt>unrecognized_name(112) </tt> alert. Note that this instead <bcp14>SHOULD</bcp14> fail with a fatal-level <tt>unrecognized_name(112) </tt> alert. Note that this
recommendation updates <xref section="3" sectionFormat="of" target="RFC6066"/>: recommendation updates <xref section="3" sectionFormat="of" target="RFC6066"/>,
"If the server understood the which stated:</t>
<blockquote>If the server understood the
ClientHello extension but does not recognize the server name, the server <bcp14> SHOULD</bcp14> ClientHello extension but does not recognize the server name, the server <bcp14> SHOULD</bcp14>
take one of two actions: either abort the handshake by sending a fatal-level take one of two actions: either abort the handshake by sending a fatal-level
<tt>unrecognized_name(112)</tt> alert or continue the handshake." <tt>unrecognized_name(112)</tt> alert or continue the handshake.</blockquote>
Clients <bcp14>SHOULD</bcp14> abort the handshake if the server acknowledges the
SNI extension, but presents a certificate with a different hostname than the on <t>
e sent by the client.</t> Clients <bcp14>SHOULD</bcp14> abort the handshake if the server acknowledges the
SNI extension but presents a certificate with a different hostname than the one
sent by the client.</t>
</section> </section>
<section anchor="rec-alpn"> <section anchor="rec-alpn">
<name>Application-Layer Protocol Negotiation (ALPN)</name> <name>Application-Layer Protocol Negotiation (ALPN)</name>
<t>TLS implementations (both client- and server-side) <bcp14>MUST</bcp14 > support the <t>TLS implementations (both client- and server-side) <bcp14>MUST</bcp14 > support the
Application-Layer Protocol Negotiation (ALPN) extension <xref target="RFC7301"/> .</t> Application-Layer Protocol Negotiation (ALPN) extension <xref target="RFC7301"/> .</t>
<t>In order to prevent "cross-protocol" attacks resulting from failure t o ensure <t>In order to prevent "cross-protocol" attacks resulting from failure t o ensure
that a message intended for use in one protocol cannot be mistaken for a that a message intended for use in one protocol cannot be mistaken for a
message for use in another protocol, servers are advised to strictly enforce the message for use in another protocol, servers are advised to strictly enforce the
behavior prescribed in <xref section="3.2" sectionFormat="of" target="RFC7301"/> behavior prescribed in <xref section="3.2" sectionFormat="of" target="RFC7301"/>
: "In the event that the :
</t>
<blockquote> In the event that the
server supports no protocols that the client advertises, then the server <bcp14> SHALL</bcp14> server supports no protocols that the client advertises, then the server <bcp14> SHALL</bcp14>
respond with a fatal <tt>no_application_protocol</tt> alert." Clients <bcp14>SH respond with a fatal '<tt>no_application_protocol</tt>' alert.</blockquote>
OULD</bcp14>
abort the handshake if the server acknowledges the ALPN extension, <t>
Clients <bcp14>SHOULD</bcp14>
abort the handshake if the server acknowledges the ALPN extension
but does not select a protocol from the client list. Failure to do so can but does not select a protocol from the client list. Failure to do so can
result in attacks such those described in <xref target="ALPACA"/>.</t> result in attacks such those described in <xref target="ALPACA"/>.</t>
<t>Protocol developers are strongly encouraged to register an ALPN ident ifier <t>Protocol developers are strongly encouraged to register an ALPN ident ifier
for their protocols. This applies both to new protocols and to well-established for their protocols. This applies both to new protocols and to well-established
protocols; however, because the latter might have a large deployed base, protocols; however, because the latter might have a large deployed base,
strict enforcement of ALPN usage may not be feasible when an ALPN strict enforcement of ALPN usage may not be feasible when an ALPN
identifier is registered for a well-established protocol.</t> identifier is registered for a well-established protocol.</t>
</section> </section>
<section anchor="multi-server-deployment"> <section anchor="multi-server-deployment">
<name>Multi-Server Deployment</name> <name>Multi-Server Deployment</name>
<t>Deployments that involve multiple servers or services can increase th e size of the attack surface for TLS. Two scenarios are of interest:</t> <t>Deployments that involve multiple servers or services can increase th e size of the attack surface for TLS. Two scenarios are of interest:</t>
<ol spacing="normal" type="1"><li>Deployments in which multiple services handle the same domain name via different <ol spacing="normal" type="1"><li>Deployments in which multiple services handle the same domain name via different
protocols (e.g., HTTP and IMAP). In this case an attacker might be able to direc t protocols (e.g., HTTP and IMAP). In this case, an attacker might be able to dire ct
a connecting endpoint to the service offering a different protocol and mount a a connecting endpoint to the service offering a different protocol and mount a
cross-protocol attack. In a cross-protocol attack, the client and server believe cross-protocol attack. In a cross-protocol attack, the client and server believe
they are using different protocols, which the attacker might exploit if messages they are using different protocols, which the attacker might exploit if messages
sent in one protocol are interpreted as messages in the other protocol with sent in one protocol are interpreted as messages in the other protocol with
undesirable effects (see <xref target="ALPACA"/> for more detailed information a bout this class undesirable effects (see <xref target="ALPACA"/> for more detailed information a bout this class
of attacks). To mitigate this threat, service providers <bcp14>SHOULD</bcp14> de ploy ALPN (see of attacks). To mitigate this threat, service providers <bcp14>SHOULD</bcp14> de ploy ALPN (see
<xref target="rec-alpn"/> immediately above) and to the extent possible ensure t <xref target="rec-alpn"/>). In addition, to the extent possible, they <bcp14>SHO
hat multiple ULD</bcp14> ensure that multiple
services handling the same domain name provide equivalent levels of security services handling the same domain name provide equivalent levels of security tha
(including both the TLS configuration and protections against compromise of t are consistent with the recommendations in this document; such measures <bcp14
server credentials) that are consistent with the recommendations in this documen >SHOULD</bcp14> include the handling of configurations across multiple TLS serve
t.</li> rs and protections against compromise of credentials held by those servers.</li>
<li>Deployments in which multiple servers providing the same service h ave different <li>Deployments in which multiple servers providing the same service h ave different
TLS configurations. In this case, an attacker might be able to direct a connecti ng TLS configurations. In this case, an attacker might be able to direct a connecti ng
endpoint to a server with a TLS configuration that is more easily exploitable (s ee endpoint to a server with a TLS configuration that is more easily exploitable (s ee
<xref target="DROWN"/> for more detailed information about this class of attacks ). To mitigate <xref target="DROWN"/> for more detailed information about this class of attacks ). To mitigate
this threat, service providers <bcp14>SHOULD</bcp14> ensure that all servers pro viding the same this threat, service providers <bcp14>SHOULD</bcp14> ensure that all servers pro viding the same
service provide equivalent levels of security that are consistent with the service provide equivalent levels of security that are consistent with the
recommendations in this document.</li> recommendations in this document.</li>
</ol> </ol>
</section> </section>
<section anchor="zero-round-trip-time-0-rtt-data-in-tls-13"> <section anchor="zero-round-trip-time-0-rtt-data-in-tls-13">
<name>Zero Round Trip Time (0-RTT) Data in TLS 1.3</name> <name>Zero Round-Trip Time (0-RTT) Data in TLS 1.3</name>
<t>The 0-RTT early data feature is new in TLS 1.3. It provides reduced l atency <t>The 0-RTT early data feature is new in TLS 1.3. It provides reduced l atency
when TLS connections are resumed, at the potential cost of certain security prop erties. when TLS connections are resumed, at the potential cost of certain security prop erties.
As a result, it requires special attention from implementers on both As a result, it requires special attention from implementers on both
the server and the client side. Typically, this extends to both the the server and the client side. Typically, this extends to the
TLS library as well as protocol layers above it.</t> TLS library as well as protocol layers above it.</t>
<t>For use in HTTP-over-TLS, readers are referred to <xref target="RFC84 <t>For HTTP over TLS, refer to <xref target="RFC8470"/> for guidance.</t
70"/> for guidance.</t> >
<t>For QUIC-on-TLS, refer to <xref section="9.2" sectionFormat="of" targ <t>For QUIC on TLS, refer to <xref section="9.2" sectionFormat="of" targ
et="RFC9001"/>.</t> et="RFC9001"/>.</t>
<t>For other protocols, generic guidance is given in Section <xref targe t="RFC8446" section="8" sectionFormat="bare"/> and Appendix <xref target="RFC844 6" section="E.5" sectionFormat="bare"/> of <xref target="RFC8446"/>. <t>For other protocols, generic guidance is given in Section <xref targe t="RFC8446" section="8" sectionFormat="bare"/> and Appendix <xref target="RFC844 6" section="E.5" sectionFormat="bare"/> of <xref target="RFC8446"/>.
To paraphrase Appendix E.5, applications <bcp14>MUST</bcp14> avoid this feature unless To paraphrase Appendix <xref target="RFC8446" sectionFormat="bare" section="E.5" />, applications <bcp14>MUST</bcp14> avoid this feature unless
an explicit specification exists for the application protocol in question to cla rify an explicit specification exists for the application protocol in question to cla rify
when 0-RTT is appropriate and secure. This can take the form of an IETF RFC, when 0-RTT is appropriate and secure. This can take the form of an IETF RFC,
a non-IETF standard, or even documentation associated with a non-standard protoc ol.</t> a non-IETF standard, or documentation associated with a non-standard protocol.</ t>
</section> </section>
</section> </section>
<section anchor="detail"> <section anchor="detail">
<name>Recommendations: Cipher Suites</name> <name>Recommendations: Cipher Suites</name>
<t>TLS 1.2 provided considerable flexibility in the selection of cipher su ites. Unfortunately, the security of some of these cipher suites has degraded ov er time to the point where some are known to be insecure (this is one reason why TLS 1.3 restricted such flexibility). Incorrectly configuring a server leads to no or reduced security. This section includes recommendations on the selection and negotiation of cipher suites.</t> <t>TLS 1.2 provided considerable flexibility in the selection of cipher su ites. Unfortunately, the security of some of these cipher suites has degraded ov er time to the point where some are known to be insecure (this is one reason why TLS 1.3 restricted such flexibility). Incorrectly configuring a server leads to no or reduced security. This section includes recommendations on the selection and negotiation of cipher suites.</t>
<section anchor="rec-cipher-guidelines"> <section anchor="rec-cipher-guidelines">
<name>General Guidelines</name> <name>General Guidelines</name>
<t>Cryptographic algorithms weaken over time as cryptanalysis improves: algorithms that were once considered strong become weak. Consequently, they need to be phased out over time and replaced with more secure cipher suites. This he lps to ensure that the desired security properties still hold. SSL/TLS has been in existence for almost 20 years and many of the cipher suites that have been re commended in various versions of SSL/TLS are now considered weak or at least not as strong as desired. Therefore, this section modernizes the recommendations co ncerning cipher suite selection.</t> <t>Cryptographic algorithms weaken over time as cryptanalysis improves: algorithms that were once considered strong become weak. Consequently, cipher su ites using weak algorithms need to be phased out and replaced with more secure c ipher suites. This helps to ensure that the desired security properties still ho ld. SSL/TLS has been in existence for well over 20 years and many of the cipher suites that have been recommended in various versions of SSL/TLS are now conside red weak or at least not as strong as desired. Therefore, this section modernize s the recommendations concerning cipher suite selection.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Implementations <bcp14>MUST NOT</bcp14> negotiate the cipher suit es with NULL encryption. </t> <t>Implementations <bcp14>MUST NOT</bcp14> negotiate the cipher suit es with NULL encryption. </t>
<t> <t>
Rationale: The NULL cipher suites do not encrypt traffic and Rationale: The NULL cipher suites do not encrypt traffic and
so provide no confidentiality services. Any entity in the so provide no confidentiality services. Any entity in the
network with access to the connection can view the plaintext network with access to the connection can view the plaintext
of contents being exchanged by the client and server.<br/> of contents being exchanged by the client and server. Nevertheless,
Nevertheless, this document does not discourage software from this document does not discourage software from
implementing NULL cipher suites, since they can be useful for implementing NULL cipher suites, since they can be useful for
testing and debugging.</t> testing and debugging.</t>
</li> </li>
<li> <li>
<t>Implementations <bcp14>MUST NOT</bcp14> negotiate RC4 cipher suit es. </t> <t>Implementations <bcp14>MUST NOT</bcp14> negotiate RC4 cipher suit es. </t>
<t> <t>
Rationale: The RC4 stream cipher has a variety of cryptographic Rationale: The RC4 stream cipher has a variety of cryptographic
weaknesses, as documented in <xref target="RFC7465"/>. weaknesses, as documented in <xref target="RFC7465"/>.
Note that DTLS specifically forbids the use of RC4 already.</t> Note that DTLS specifically forbids the use of RC4 already.</t>
</li> </li>
<li> <li>
<t>Implementations <bcp14>MUST NOT</bcp14> negotiate cipher suites o ffering less <t>Implementations <bcp14>MUST NOT</bcp14> negotiate cipher suites o ffering less
than 112 bits of security, including so-called "export-level" than 112 bits of security, including so-called "export-level"
encryption (which provide 40 or 56 bits of security). </t> encryption (which provides 40 or 56 bits of security). </t>
<t> <t>
Rationale: Based on <xref target="RFC3766"/>, at least 112 bits Rationale: Based on <xref target="RFC3766"/>, at least 112 bits
of security is needed. 40-bit and 56-bit security (found in of security is needed. 40-bit and 56-bit security (found in
so-called "export ciphers") are considered so-called "export ciphers") are considered
insecure today.</t> insecure today.</t>
</li> </li>
<li> <li>
<t>Implementations <bcp14>SHOULD NOT</bcp14> negotiate cipher suites that use <t>Implementations <bcp14>SHOULD NOT</bcp14> negotiate cipher suites that use
algorithms offering less than 128 bits of security. </t> algorithms offering less than 128 bits of security. </t>
<t> <t>
Rationale: Cipher suites that offer 112 or more bits but less than 128 bits Rationale: Cipher suites that offer 112 or more bits but less than 128 bits
of security are not considered weak at this time; however, it is of security are not considered weak at this time; however, it is
expected that their useful lifespan is short enough to justify expected that their useful lifespan is short enough to justify
supporting stronger cipher suites at this time. 128-bit ciphers supporting stronger cipher suites at this time. 128-bit ciphers
are expected to remain secure for at least several years, and are expected to remain secure for at least several years and
256-bit ciphers until the next fundamental technology 256-bit ciphers until the next fundamental technology
breakthrough. Note that, because of so-called breakthrough. Note that, because of so-called
"meet-in-the-middle" attacks <xref target="Multiple-Encryption"/>, "meet-in-the-middle" attacks <xref target="Multiple-Encryption"/>,
some legacy cipher suites (e.g., 168-bit 3DES) have an effective some legacy cipher suites (e.g., 168-bit Triple DES (3DES)) have an effective
key length that is smaller than their nominal key length (112 key length that is smaller than their nominal key length (112
bits in the case of 3DES). Such cipher suites should be bits in the case of 3DES). Such cipher suites should be
evaluated according to their effective key length.</t> evaluated according to their effective key length.</t>
</li> </li>
<li> <li>
<t>Implementations <bcp14>SHOULD NOT</bcp14> negotiate cipher suites based on <t>Implementations <bcp14>SHOULD NOT</bcp14> negotiate cipher suites based on
RSA key transport, a.k.a. "static RSA". </t> RSA key transport, a.k.a. "static RSA". </t>
<t> <t>
Rationale: These cipher suites, which have assigned values starting Rationale: These cipher suites, which have assigned values starting
with the string "TLS_RSA_WITH_*", have several drawbacks, especiall y with the string "TLS_RSA_WITH_*", have several drawbacks, especiall y
the fact that they do not support forward secrecy.</t> the fact that they do not support forward secrecy.</t>
</li> </li>
<li> <li>
<t>Implementations <bcp14>SHOULD NOT</bcp14> negotiate cipher suites based on <t>Implementations <bcp14>SHOULD NOT</bcp14> negotiate cipher suites based on
non-ephemeral (static) finite-field Diffie-Hellman key agreement. S imilarly, implementations <bcp14>SHOULD NOT</bcp14> negotiate non-ephemeral elli ptic curve DH key agreement. </t> non-ephemeral (static) finite-field Diffie-Hellman (DH) key agreeme nt. Similarly, implementations <bcp14>SHOULD NOT</bcp14> negotiate non-ephemeral Elliptic Curve DH key agreement. </t>
<t> <t>
Rationale: The former cipher suites, which have assigned values prefixed by "TLS _DH_*", have several drawbacks, especially Rationale: The former cipher suites, which have assigned values prefixed by "TLS _DH_*", have several drawbacks, especially
the fact that they do not support forward secrecy. The latter ("TLS _ECDH_*") also lack forward secrecy, and are subject to invalid curve attacks <x ref target="Jager2015"/>.</t> the fact that they do not support forward secrecy. The latter ("TLS _ECDH_*") also lack forward secrecy and are subject to invalid curve attacks <xr ef target="Jager2015"/>.</t>
</li> </li>
<li> <li>
<t>Implementations <bcp14>MUST</bcp14> support and prefer to negotia te cipher suites <t>Implementations <bcp14>MUST</bcp14> support and prefer to negotia te cipher suites
offering forward secrecy. However, TLS 1.2 implementations <bcp14> SHOULD NOT</bcp14> negotiate offering forward secrecy. However, TLS 1.2 implementations <bcp14> SHOULD NOT</bcp14> negotiate
cipher suites based on ephemeral finite-field Diffie-Hellman key cipher suites based on ephemeral finite-field Diffie-Hellman key
agreement (i.e., "TLS_DHE_*" suites). This is justified by the kno wn fragility agreement (i.e., "TLS_DHE_*" suites). This is justified by the kno wn fragility
of the construction (see <xref target="RACCOON"/>) and the limitati on around of the construction (see <xref target="RACCOON"/>) and the limitati on around
negotiation -- including using <xref target="RFC7919"/>, which has seen very negotiation, including using <xref target="RFC7919"/>, which has se en very
limited uptake. </t> limited uptake. </t>
<t> <t>
Rationale: Forward secrecy (sometimes called "perfect forward Rationale: Forward secrecy (sometimes called "perfect forward
secrecy") prevents the recovery of information that was encrypted secrecy") prevents the recovery of information that was encrypted
with older session keys, thus limiting how far back in time data with older session keys, thus limiting how far back in time data
can be decrypted when an attack is successful. See <xref target="s can be decrypted when an attack is successful. See Sections <xref
ec-pfs"/> target="sec-pfs" format="counter"/>
and <xref target="sec-dhe"/> for a detailed discussion.</t> and <xref target="sec-dhe" format="counter"/> for a detailed discus
sion.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="rec-cipher"> <section anchor="rec-cipher">
<name>Cipher Suites for TLS 1.2</name> <name>Cipher Suites for TLS 1.2</name>
<t>Given the foregoing considerations, implementation and deployment of the following cipher suites is <bcp14>RECOMMENDED</bcp14>:</t> <t>Given the foregoing considerations, implementation and deployment of the following cipher suites is <bcp14>RECOMMENDED</bcp14>:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</li> <li>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</li>
<li>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384</li> <li>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384</li>
<li>TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256</li> <li>TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256</li>
<li>TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384</li> <li>TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384</li>
</ul> </ul>
<t>As these are authenticated encryption (AEAD) algorithms <xref target= <t>As these are Authenticated Encryption with Associated Data (AEAD) alg
"RFC5116"/>, these cipher suites are supported only in TLS 1.2 and not in earlie orithms <xref target="RFC5116"/>, these cipher suites are supported only in TLS
r protocol versions.</t> 1.2 and not in earlier protocol versions.</t>
<t>Typically, in order to prefer these suites, the order of suites needs <t>Typically, to prefer these suites, the order of suites needs to be ex
to be explicitly configured in server software. It would be ideal if server so plicitly configured in server software. It would be ideal if server software im
ftware implementations were to prefer these suites by default.</t> plementations were to prefer these suites by default.</t>
<t>Some devices have hardware support for AES-CCM but not AES-GCM, so th <t>Some devices have hardware support for AES Counter Mode with CBC-MAC
ey are unable to follow the foregoing recommendations regarding cipher suites. (AES-CCM) but not AES Galois/Counter Mode (AES-GCM), so they are unable to follo
There are even devices that do not support public key cryptography at all, but t w the foregoing recommendations regarding cipher suites. There are even devices
hese are out of scope entirely.</t> that do not support public key cryptography at all, but these are out of scope
entirely.</t>
<t>A cipher suite that operates in CBC (cipher block chaining) mode (e.g ., <t>A cipher suite that operates in CBC (cipher block chaining) mode (e.g .,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) <bcp14>SHOULD NOT</bcp14> be used unless the TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) <bcp14>SHOULD NOT</bcp14> be used unless the
encrypt_then_mac extension <xref target="RFC7366"/> is also successfully negotia ted. <tt>encrypt_then_mac</tt> extension <xref target="RFC7366"/> is also successfull y negotiated.
This requirement applies to both client and server implementations.</t> This requirement applies to both client and server implementations.</t>
<t>When using ECDSA signatures for authentication of TLS peers, it is <b cp14>RECOMMENDED</bcp14> that implementations use the NIST curve P-256. In addit ion, to avoid predictable or repeated nonces (that would allow revealing the lon g term signing key), it is <bcp14>RECOMMENDED</bcp14> that implementations imple ment "deterministic ECDSA" as specified in <xref target="RFC6979"/> and in line with the recommendations in <xref target="RFC8446"/>.</t> <t>When using ECDSA signatures for authentication of TLS peers, it is <b cp14>RECOMMENDED</bcp14> that implementations use the NIST curve P-256. In addit ion, to avoid predictable or repeated nonces (which could reveal the long-term s igning key), it is <bcp14>RECOMMENDED</bcp14> that implementations implement "de terministic ECDSA" as specified in <xref target="RFC6979"/> and in line with the recommendations in <xref target="RFC8446"/>.</t>
<t>Note that implementations of "deterministic ECDSA" may be vulnerable to certain <t>Note that implementations of "deterministic ECDSA" may be vulnerable to certain
side-channel and fault injection attacks precisely because of their side-channel and fault injection attacks precisely because of their
determinism. While most fault attacks described in the literature assume determinism. While most fault injection attacks described in the literature ass
physical access to the device (and therefore are more relevant in IoT ume
physical access to the device (and therefore are more relevant in Internet of Th
ings (IoT)
deployments with poor or non-existent physical security), some can be carried deployments with poor or non-existent physical security), some can be carried
out remotely <xref target="Poddebniak2017"/>, e.g., as Rowhammer <xref target="K im2014"/> variants. In out remotely <xref target="Poddebniak2017"/>, e.g., as Rowhammer <xref target="K im2014"/> variants. In
deployments where side-channel attacks and fault injection attacks are a deployments where side-channel attacks and fault injection attacks are a
concern, implementation strategies combining both randomness and determinism concern, implementation strategies combining both randomness and determinism
(for example, as described in <xref target="I-D.mattsson-cfrg-det-sigs-with-nois e"/>) can (for example, as described in <xref target="I-D.mattsson-cfrg-det-sigs-with-nois e"/>) can
be used to avoid the risk of successful extraction of the signing key.</t> be used to avoid the risk of successful extraction of the signing key.</t>
<section anchor="detail-neg"> <section anchor="detail-neg">
<name>Implementation Details</name> <name>Implementation Details</name>
<t>Clients <bcp14>SHOULD</bcp14> include TLS_ECDHE_RSA_WITH_AES_128_GC M_SHA256 as the first proposal to any server. Servers <bcp14>MUST</bcp14> prefe r this cipher suite over weaker cipher suites whenever it is proposed, even if i t is not the first proposal. Clients are of course free to offer stronger ciphe r suites, e.g., using AES-256; when they do, the server <bcp14>SHOULD</bcp14> pr efer the stronger cipher suite unless there are compelling reasons (e.g., seriou sly degraded performance) to choose otherwise.</t> <t>Clients <bcp14>SHOULD</bcp14> include TLS_ECDHE_RSA_WITH_AES_128_GC M_SHA256 as the first proposal to any server. Servers <bcp14>MUST</bcp14> prefe r this cipher suite over weaker cipher suites whenever it is proposed, even if i t is not the first proposal. Clients are of course free to offer stronger ciphe r suites, e.g., using AES-256; when they do, the server <bcp14>SHOULD</bcp14> pr efer the stronger cipher suite unless there are compelling reasons (e.g., seriou sly degraded performance) to choose otherwise.</t>
<t>The previous version of this document implicitly allowed the old RF <t>The previous version of the TLS recommendations <xref target="RFC75
C 5246 mandatory-to-implement cipher suite, TLS_RSA_WITH_AES_128_CBC_SHA. At the 25"/> implicitly allowed the old RFC 5246 mandatory-to-implement cipher suite, T
time of writing, this cipher suite does not provide additional interoperability LS_RSA_WITH_AES_128_CBC_SHA. At the time of writing, this cipher suite does not
, except with very old clients. As with other cipher suites that do not provide provide additional interoperability, except with very old clients. As with other
forward secrecy, implementations <bcp14>SHOULD NOT</bcp14> support this cipher s cipher suites that do not provide forward secrecy, implementations <bcp14>SHOUL
uite. Other application protocols specify other cipher suites as mandatory to im D NOT</bcp14> support this cipher suite. Other application protocols specify oth
plement (MTI).</t> er cipher suites as mandatory to implement (MTI).</t>
<t><xref target="RFC8422"/> allows clients and servers to negotiate EC <t><xref target="RFC8422"/> allows clients and servers to negotiate EC
DH parameters (curves). Both clients and servers <bcp14>SHOULD</bcp14> include DH parameters (curves). Both clients and servers <bcp14>SHOULD</bcp14> include t
the "Supported Elliptic Curves" extension <xref target="RFC8422"/>. Clients and he "Supported Elliptic Curves Extension" <xref target="RFC8422"/>. Clients and
servers <bcp14>SHOULD</bcp14> support the NIST P-256 (secp256r1) <xref target=" servers <bcp14>SHOULD</bcp14> support the NIST P&nbhy;256 (secp256r1) <xref targ
RFC8422"/> and X25519 (x25519) <xref target="RFC7748"/> curves. Note that <xref et="RFC8422"/> and X25519 (x25519) <xref target="RFC7748"/> curves. Note that <
target="RFC8422"/> deprecates all but the uncompressed point format. Therefore xref target="RFC8422"/> deprecates all but the uncompressed point format. There
, if the client sends an ec_point_formats extension, the ECPointFormatList <bcp1 fore, if the client sends an <tt>ec_point_formats</tt> extension, the ECPointFor
4>MUST</bcp14> contain a single element, "uncompressed".</t> matList <bcp14>MUST</bcp14> contain a single element, "uncompressed".</t>
</section> </section>
</section> </section>
<section anchor="cipher-suites-for-tls-13"> <section anchor="cipher-suites-for-tls-13">
<name>Cipher Suites for TLS 1.3</name> <name>Cipher Suites for TLS 1.3</name>
<t>This document does not specify any cipher suites for TLS 1.3. Readers <t>This document does not specify any cipher suites for TLS 1.3. Readers
are referred to <xref section="9.1" sectionFormat="of" target="RFC8446"/> for ci pher suite recommendations.</t> are referred to <xref section="9.1" sectionFormat="of" target="RFC8446"/> for ci pher suite recommendations.</t>
</section> </section>
<section anchor="limits-on-key-usage"> <section anchor="limits-on-key-usage">
<name>Limits on Key Usage</name> <name>Limits on Key Usage</name>
<t>All ciphers have an upper limit on the amount of traffic that can be securely <t>All ciphers have an upper limit on the amount of traffic that can be securely
protected with any given key. In the case of AEAD cipher suites, two separate protected with any given key. In the case of AEAD cipher suites, two separate
limits are maintained for each key:</t> limits are maintained for each key:</t>
<ol spacing="normal" type="1"><li>Confidentiality limit (CL), i.e., the number of records that can be <ol spacing="normal" type="1"><li>Confidentiality limit (CL), i.e., the number of records that can be
encrypted.</li> encrypted.</li>
<li>Integrity limit (IL), i.e., the number of records that are allowed to fail <li>Integrity limit (IL), i.e., the number of records that are allowed to fail
authentication.</li> authentication.</li>
</ol> </ol>
skipping to change at line 478 skipping to change at line 515
both versions.</t> both versions.</t>
<t>For all AES-GCM cipher suites recommended for DTLS 1.2, IL (obtained from the <t>For all AES-GCM cipher suites recommended for DTLS 1.2, IL (obtained from the
same inequalities referenced above) is 2<sup>28</sup>.</t> same inequalities referenced above) is 2<sup>28</sup>.</t>
</section> </section>
<section anchor="rec-keylength"> <section anchor="rec-keylength">
<name>Public Key Length</name> <name>Public Key Length</name>
<t>When using the cipher suites recommended in this document, two public keys are <t>When using the cipher suites recommended in this document, two public keys are
normally used in the TLS handshake: one for the Diffie-Hellman key agreeme nt normally used in the TLS handshake: one for the Diffie-Hellman key agreeme nt
and one for server authentication. Where a client certificate is used, a t hird and one for server authentication. Where a client certificate is used, a t hird
public key is added.</t> public key is added.</t>
<t>With a key exchange based on modular exponential (MODP) Diffie-Hellma
n groups ("DHE" cipher suites), DH key lengths of at least 2048 bits are <bcp14> <t>With a key exchange based on modular exponential (MODP) Diffie-Hellman
REQUIRED</bcp14>.</t> groups ("DHE" cipher suites), DH key lengths of at least 2048 bits are <bcp14>RE
QUIRED</bcp14>.</t>
<t>Rationale: For various reasons, in practice, DH keys are typically ge nerated in lengths <t>Rationale: For various reasons, in practice, DH keys are typically ge nerated in lengths
that are powers of two (e.g., 2<sup>10</sup> = 1024 bits, 2<sup>11</sup> = 2048 bits, 2<sup>12</sup> = 4096 bits). that are powers of two (e.g., 2<sup>10</sup> = 1024 bits, 2<sup>11</sup> = 2048 bits, 2<sup>12</sup> = 4096 bits).
Because a DH key of 1228 bits would be roughly equivalent to only an 80-bit sym metric key Because a DH key of 1228 bits would be roughly equivalent to only an 80-bit sym metric key
<xref target="RFC3766"/>, it is better to use keys longer than that for the "DHE " family of cipher suites. <xref target="RFC3766"/>, it is better to use keys longer than that for the "DHE " family of cipher suites.
A DH key of 1926 bits would be roughly equivalent to a 100-bit symmetric key <xr ef target="RFC3766"/>. A DH key of 1926 bits would be roughly equivalent to a 100-bit symmetric key <xr ef target="RFC3766"/>.
A DH key of 2048 bits (equivalent to a 112-bit symmetric key) A DH key of 2048 bits (equivalent to a 112-bit symmetric key)
is the minimum allowed by the latest revision of <xref target="NIST.SP.800-56A"/ is the minimum allowed by the latest revision of <xref target="NIST.SP.800-56A"/
>, as of this writing > as of this writing
(see in particular Appendix D).</t> (see in particular Appendix D of that document).</t>
<t>As noted in <xref target="RFC3766"/>, correcting for the emergence of <t>As noted in <xref target="RFC3766"/>, correcting for the emergence of
a TWIRL machine <xref target="TWIRL"/> would imply that 1024-bit DH keys yield The Weizmann Institute Relation Locator (TWIRL) machine <xref target="TWIRL"/>
about 61 bits of equivalent strength and that a 2048-bit DH key would yield abou would imply that 1024-bit DH keys yield about 61 bits of equivalent strength and
t 92 bits of equivalent strength. that a 2048-bit DH key would yield about 92 bits of equivalent strength.
The Logjam attack <xref target="Logjam"/> further demonstrates that 1024-bit Dif fie-Hellman parameters The Logjam attack <xref target="Logjam"/> further demonstrates that 1024-bit Dif fie-Hellman parameters
should be avoided.</t> should be avoided.</t>
<t>With regard to ECDH keys, implementers are referred to the IANA "Supp <t>With regard to ECDH keys, implementers are referred to the IANA "TLS
orted Groups Registry" (former "EC Named Curve Supported Groups" registry (formerly known as the "EC Named Curve
Registry"), within the Registry") within the
"Transport Layer Security (TLS) Parameters" registry <xref target="IANA_TLS"/ "Transport Layer Security (TLS) Parameters" registry <xref target="IANA_TLS"/
>, and in particular to the "recommended" > and in particular to the "recommended"
groups. Curves of less than 224 bits <bcp14>MUST NOT</bcp14> be used. This r groups. Curves of less than 224 bits <bcp14>MUST NOT</bcp14> be used. This r
ecommendation is in-line with the latest ecommendation is in line with the latest
revision of <xref target="NIST.SP.800-56A"/>.</t> revision of <xref target="NIST.SP.800-56A"/>.</t>
<t>When using RSA, servers <bcp14>MUST</bcp14> authenticate using certif icates with at least a 2048-bit modulus for the public key. In addition, the us e of the SHA-256 hash algorithm is <bcp14>RECOMMENDED</bcp14> and SHA-1 or MD5 < bcp14>MUST NOT</bcp14> be used (<xref target="RFC9155"/>, and see <xref target=" CAB-Baseline"/> for more details). Clients <bcp14>MUST</bcp14> indicate to serve rs that they request SHA-256, by using the "Signature Algorithms" extension defi ned in TLS 1.2. For TLS 1.3, the same requirement is already specified by <xref target="RFC8446"/>.</t> <t>When using RSA, servers <bcp14>MUST</bcp14> authenticate using certificates w ith at least a 2048-bit modulus for the public key. In addition, the use of the SHA-256 hash algorithm is <bcp14>RECOMMENDED</bcp14> and SHA-1 or MD5 <bcp14>MUS T NOT</bcp14> be used <xref target="RFC9155"/> (for more details, see also <xref target="CAB-Baseline"/>, for which the current version at the time of writing i s 1.8.4). Clients <bcp14>MUST</bcp14> indicate to servers that they request SHA- 256 by using the "Signature Algorithms" extension defined in TLS 1.2. For TLS 1. 3, the same requirement is already specified by <xref target="RFC8446"/>.</t>
<t><cref anchor="live-ref-question">Note to RFC Editor: we are looking f or advice on how to best handle this constantly updated guidance from the CA/Bro wser Forum. In particular: which URL to use, which (if any) version to referenc e</cref></t> <t><cref anchor="live-ref-question">Note to RFC Editor: we are looking f or advice on how to best handle this constantly updated guidance from the CA/Bro wser Forum. In particular: which URL to use, which (if any) version to referenc e</cref></t>
</section> </section>
<section anchor="truncated-hmac"> <section anchor="truncated-hmac">
<name>Truncated HMAC</name> <name>Truncated HMAC</name>
<t>Implementations <bcp14>MUST NOT</bcp14> use the Truncated HMAC extens <t>Implementations <bcp14>MUST NOT</bcp14> use the Truncated HMAC Extens
ion, defined in <xref section="7" sectionFormat="of" target="RFC6066"/>.</t> ion, defined in <xref section="7" sectionFormat="of" target="RFC6066"/>.</t>
<t>Rationale: the extension does not apply to the AEAD <t>Rationale: The extension does not apply to the AEAD
cipher suites recommended above. However, it does apply to most other TLS cipher suites. Its use cipher suites recommended above. However, it does apply to most other TLS cipher suites. Its use
has been shown to be insecure in <xref target="PatersonRS11"/>.</t> has been shown to be insecure in <xref target="PatersonRS11"/>.</t>
</section> </section>
</section> </section>
<section anchor="applicability"> <section anchor="applicability">
<name>Applicability Statement</name> <name>Applicability Statement</name>
<t>The recommendations of this document primarily apply to the implementat ion and deployment of application protocols that are most commonly used with TLS and DTLS on the Internet today. Examples include, but are not limited to:</t> <t>The recommendations of this document primarily apply to the implementat ion and deployment of application protocols that are most commonly used with TLS and DTLS on the Internet today. Examples include, but are not limited to:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Web software and services that wish to protect HTTP traffic with TLS .</li> <li>Web software and services that wish to protect HTTP traffic with TLS .</li>
<li>Email software and services that wish to protect IMAP, POP3, or SMTP traffic with TLS.</li> <li>Email software and services that wish to protect IMAP, Post Office P rotocol version 3 (POP3), or SMTP traffic with TLS.</li>
<li>Instant-messaging software and services that wish to protect Extensi ble Messaging and Presence Protocol (XMPP) or Internet Relay Chat (IRC) traffic with TLS.</li> <li>Instant-messaging software and services that wish to protect Extensi ble Messaging and Presence Protocol (XMPP) or Internet Relay Chat (IRC) traffic with TLS.</li>
<li>Realtime media software and services that wish to protect Secure Rea ltime Transport Protocol (SRTP) traffic with DTLS.</li> <li>Realtime media software and services that wish to protect Secure Rea ltime Transport Protocol (SRTP) traffic with DTLS.</li>
</ul> </ul>
<t>This document does not modify the implementation and deployment recomme ndations (e.g., mandatory-to-implement cipher suites) prescribed by existing app lication protocols that employ TLS or DTLS. If the community that uses such an a pplication protocol wishes to modernize its usage of TLS or DTLS to be consisten t with the best practices recommended here, it needs to explicitly update the ex isting application protocol definition (one example is <xref target="RFC7590"/>, which updates <xref target="RFC6120"/>).</t> <t>This document does not modify the implementation and deployment recomme ndations (e.g., mandatory-to-implement cipher suites) prescribed by existing app lication protocols that employ TLS or DTLS. If the community that uses such an a pplication protocol wishes to modernize its usage of TLS or DTLS to be consisten t with the best practices recommended here, it needs to explicitly update the ex isting application protocol definition (one example is <xref target="RFC7590"/>, which updates <xref target="RFC6120"/>).</t>
<t>Designers of new application protocols developed through the Internet <t>Designers of new application protocols developed through the Internet
Standards Process <xref target="RFC2026"/> are expected at minimum to conform to the best Standards Process <xref target="RFC2026"/> are expected at minimum to conform to the best
practices recommended here, unless they provide documentation of practices recommended here, unless they provide documentation of
compelling reasons that would prevent such conformance (e.g., compelling reasons that would prevent such conformance (e.g.,
widespread deployment on constrained devices that lack support for widespread deployment on constrained devices that lack support for
the necessary algorithms).</t> the necessary algorithms).</t>
<t>Although many of the recommendations provided here might also apply to QUIC insofar <t>Although many of the recommendations provided here might also apply to QUIC insofar
it uses the TLS 1.3 handshake protocol, QUIC and other such secure transport pro tocols that it uses the TLS 1.3 handshake protocol, QUIC and other such secure transpor t protocols
are out of scope of this document. For QUIC specifically, readers are are out of scope of this document. For QUIC specifically, readers are
referred to <xref section="9.2" sectionFormat="of" target="RFC9001"/>.</t> referred to <xref section="9.2" sectionFormat="of" target="RFC9001"/>.</t>
<t>This document does not address the use of TLS in constrained-node netwo rks <t>This document does not address the use of TLS in constrained-node netwo rks
<xref target="RFC7228"/>. For recommendations regarding the profiling of TLS an d DTLS for <xref target="RFC7228"/>. For recommendations regarding the profiling of TLS an d DTLS for
small devices with severe constraints on power, memory, and processing small devices with severe constraints on power, memory, and processing
resources, the reader is referred to <xref target="RFC7925"/> and resources, the reader is referred to <xref target="RFC7925"/> and
<xref target="I-D.ietf-uta-tls13-iot-profile"/>.</t> <xref target="I-D.ietf-uta-tls13-iot-profile"/>.</t>
<section anchor="security-services"> <section anchor="security-services">
<name>Security Services</name> <name>Security Services</name>
<t>This document provides recommendations for an audience that wishes to secure their communication with TLS to achieve the following:</t> <t>This document provides recommendations for an audience that wishes to secure their communication with TLS to achieve the following:</t>
<ul spacing="normal">
<li>Confidentiality: all application-layer communication is encrypted <dl>
with the goal that no party should be able to decrypt it except the intended rec
eiver.</li> <dt>Confidentiality:
<li>Data integrity: any changes made to the communication in transit a </dt>
re detectable by the receiver.</li> <dd>all application-layer communication is encrypted with the goal
<li>Authentication: an endpoint of the TLS communication is authentica that no party should be able to decrypt it except the intended receiver.
ted as the intended entity to communicate with.</li> </dd>
</ul>
<t>With regard to authentication, TLS enables authentication of one or b <dt>Data integrity:
oth endpoints in the communication. In the context of opportunistic security <x </dt>
ref target="RFC7435"/>, TLS is sometimes used without authentication. As discuss <dd>any changes made to the communication in transit are detectable
ed in <xref target="oppsec"/>, considerations for opportunistic security are not by the receiver.
in scope for this document.</t> </dd>
<dt>Authentication:
</dt>
<dd>an endpoint of the TLS communication is authenticated as the
intended entity to communicate with.
</dd>
</dl>
<t>With regard to authentication, TLS enables authentication of one or both endp
oints in the communication. In the context of opportunistic security <xref targ
et="RFC7435"/>, TLS is sometimes used without authentication. As discussed in <x
ref target="oppsec"/>, considerations for opportunistic security are not in scop
e for this document.</t>
<t>If deployers deviate from the recommendations given in this document, they need to be aware that they might lose access to one of the foregoing secur ity services.</t> <t>If deployers deviate from the recommendations given in this document, they need to be aware that they might lose access to one of the foregoing secur ity services.</t>
<t>This document applies only to environments where confidentiality is r equired. It requires algorithms and configuration options that enforce secrecy o f the data in transit.</t> <t>This document applies only to environments where confidentiality is r equired. It requires algorithms and configuration options that enforce secrecy o f the data in transit.</t>
<t>This document also assumes that data integrity protection is always o ne of the goals of a deployment. In cases where integrity is not required, it do es not make sense to employ TLS in the first place. There are attacks against co nfidentiality-only protection that utilize the lack of integrity to also break c onfidentiality (see, for instance, <xref target="DegabrieleP07"/> in the context of IPsec).</t> <t>This document also assumes that data integrity protection is always o ne of the goals of a deployment. In cases where integrity is not required, it do es not make sense to employ TLS in the first place. There are attacks against co nfidentiality-only protection that utilize the lack of integrity to also break c onfidentiality (see, for instance, <xref target="DegabrieleP07"/> in the context of IPsec).</t>
<t>This document addresses itself to application protocols that are most <t>This document addresses itself to application protocols that are most
commonly used on the Internet with TLS and DTLS. Typically, all communication b commonly used on the Internet with TLS and DTLS. Typically, all communication b
etween TLS clients and TLS servers requires all three of the above security serv etween TLS clients and TLS servers requires all three of the above security serv
ices. This is particularly true where TLS clients are user agents like Web brows ices. This is particularly true where TLS clients are user agents like web brows
ers or email software.</t> ers or email clients.</t>
<t>This document does not address the rarer deployment scenarios where o <t>This document does not address the rarer deployment scenarios where o
ne of the above three properties is not desired, such as the use case described ne of the above three properties is not desired, such as the use case described
in <xref target="oppsec"/> below. As another scenario where confidentiality is in <xref target="oppsec"/>. As another scenario where confidentiality is not ne
not needed, consider a monitored network where the authorities in charge of the eded, consider a monitored network where the authorities in charge of the respec
respective traffic domain require full access to unencrypted (plaintext) traffic tive traffic domain require full access to unencrypted (plaintext) traffic and w
, and where users collaborate and send their traffic in the clear.</t> here users collaborate and send their traffic in the clear.</t>
</section> </section>
<section anchor="oppsec"> <section anchor="oppsec">
<name>Opportunistic Security</name> <name>Opportunistic Security</name>
<t>There are several important scenarios in which the use of TLS is opti onal, i.e., the client decides dynamically ("opportunistically") whether to use TLS with a particular server or to connect in the clear. This practice, often c alled "opportunistic security", is described at length in <xref target="RFC7435" /> and is often motivated by a desire for backward compatibility with legacy dep loyments.</t> <t>There are several important scenarios in which the use of TLS is opti onal, i.e., the client decides dynamically ("opportunistically") whether to use TLS with a particular server or to connect in the clear. This practice, often c alled "opportunistic security", is described at length in <xref target="RFC7435" /> and is often motivated by a desire for backward compatibility with legacy dep loyments.</t>
<t>In these scenarios, some of the recommendations in this document migh t be too strict, since adhering to them could cause fallback to cleartext, a wor se outcome than using TLS with an outdated protocol version or cipher suite.</t> <t>In these scenarios, some of the recommendations in this document migh t be too strict, since adhering to them could cause fallback to cleartext, a wor se outcome than using TLS with an outdated protocol version or cipher suite.</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t> <t>This document has no IANA actions.</t>
skipping to change at line 556 skipping to change at line 612
<section anchor="oppsec"> <section anchor="oppsec">
<name>Opportunistic Security</name> <name>Opportunistic Security</name>
<t>There are several important scenarios in which the use of TLS is opti onal, i.e., the client decides dynamically ("opportunistically") whether to use TLS with a particular server or to connect in the clear. This practice, often c alled "opportunistic security", is described at length in <xref target="RFC7435" /> and is often motivated by a desire for backward compatibility with legacy dep loyments.</t> <t>There are several important scenarios in which the use of TLS is opti onal, i.e., the client decides dynamically ("opportunistically") whether to use TLS with a particular server or to connect in the clear. This practice, often c alled "opportunistic security", is described at length in <xref target="RFC7435" /> and is often motivated by a desire for backward compatibility with legacy dep loyments.</t>
<t>In these scenarios, some of the recommendations in this document migh t be too strict, since adhering to them could cause fallback to cleartext, a wor se outcome than using TLS with an outdated protocol version or cipher suite.</t> <t>In these scenarios, some of the recommendations in this document migh t be too strict, since adhering to them could cause fallback to cleartext, a wor se outcome than using TLS with an outdated protocol version or cipher suite.</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="sec"> <section anchor="sec">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This entire document discusses the security practices directly affectin g applications <t>This entire document discusses the security practices directly affectin g applications
using the TLS protocol. This section contains broader security consideration s related using the TLS protocol. This section contains broader security consideration s related
to technologies used in conjunction with or by TLS. to technologies used in conjunction with or by TLS.
The reader is referred to the Security Considerations sections of TLS 1.3 The reader is referred to the Security Considerations sections of TLS 1.3
<xref target="RFC8446"/>, DTLS 1.3 <xref target="RFC9147"/>, TLS 1.2 <xref t arget="RFC5246"/> and DTLS 1.2 <xref target="RFC6347"/> <xref target="RFC8446"/>, DTLS 1.3 <xref target="RFC9147"/>, TLS 1.2 <xref t arget="RFC5246"/>, and DTLS 1.2 <xref target="RFC6347"/>
for further context.</t> for further context.</t>
<section anchor="host-name-validation"> <section anchor="host-name-validation">
<name>Host Name Validation</name> <name>Host Name Validation</name>
<t>Application authors should take note that some TLS implementations <t>Application authors should take note that some TLS implementations
do not validate host names. If the TLS implementation they are do not validate host names. If the TLS implementation they are
using does not validate host names, authors might need to write their using does not validate host names, authors might need to write their
own validation code or consider using a different TLS implementation.</t> own validation code or consider using a different TLS implementation.</t>
<t>It is noted that the requirements regarding host name validation (and <t>It is noted that the requirements regarding host name validation (and, in g
, in general, binding between the TLS layer and the protocol that runs above it) eneral, binding between the TLS layer and the protocol that runs above it) vary
vary between different protocols. For HTTPS, these requirements are defined by between different protocols. For HTTPS, these requirements are defined by Sectio
Sections 4.3.3, 4.3.4 and 4.3.5 of <xref target="HTTP-SEMA"/>.</t> ns
<t>Host name validation is security-critical for all common TLS use case
s. Without it, TLS ensures that the certificate is valid and guarantees possessi <xref target="RFC9110" section="4.3.3" sectionFormat="bare" />, <xref target=
on of the private key, but does not ensure that the connection terminates at the "RFC9110"
desired endpoint. Readers are referred to <xref target="RFC6125"/> for further sectionFormat="bare" section="4.3.4" />, and <xref target="RFC9110"
details regarding generic host name validation in the TLS context. In addition, sectionFormat="bare" section="4.3.5" /> of <xref target="RFC9110"/>.</t>
that RFC contains a long list of example protocols, some of which implement a po <t>Host name validation is security-critical for all common TLS use case
licy very different from HTTPS.</t> s. Without it, TLS ensures that the certificate is valid and guarantees possessi
<t>If the host name is discovered indirectly and insecurely (e.g., by a on of the private key but does not ensure that the connection terminates at the
clear-text DNS query for an SRV or MX record), it <bcp14>SHOULD NOT</bcp14> be u desired endpoint. Readers are referred to <xref target="RFC6125"/> for further d
sed as a reference identifier <xref target="RFC6125"/> even when it matches the etails regarding generic host name validation in the TLS context. In addition, t
presented certificate. This proviso does not apply if the host name is discover hat RFC contains a long list of application protocols, some of which implement a
ed securely (for further discussion, see <xref target="DANE-SRV"/> and <xref tar policy very different from HTTPS.</t>
get="DANE-SMTP"/>).</t> <t>If the host name is discovered indirectly and insecurely (e.g., by a
cleartext DNS query for an SRV or Mail Exchange (MX) record), it <bcp14>SHOULD N
OT</bcp14> be used as a reference identifier <xref target="RFC6125"/> even when
it matches the presented certificate. This proviso does not apply if the host n
ame is discovered securely (for further discussion, see <xref target="RFC7673"/>
and <xref target="RFC7672"/>).</t>
<t>Host name validation typically applies only to the leaf "end entity" certificate. Naturally, in order to ensure proper authentication in the context of the PKI, application clients need to verify the entire certification path in accordance with <xref target="RFC5280"/>.</t> <t>Host name validation typically applies only to the leaf "end entity" certificate. Naturally, in order to ensure proper authentication in the context of the PKI, application clients need to verify the entire certification path in accordance with <xref target="RFC5280"/>.</t>
</section> </section>
<section anchor="sec-aes"> <section anchor="sec-aes">
<name>AES-GCM</name> <name>AES-GCM</name>
<t><xref target="rec-cipher"/> above recommends the use of the AES-GCM a uthenticated encryption algorithm. Please refer to <xref section="6" sectionForm at="of" target="RFC5288"/> for security considerations that apply specifically t o AES-GCM when used with TLS.</t> <t><xref target="rec-cipher"/> recommends the use of the AES-GCM authent icated encryption algorithm. Please refer to <xref section="6" sectionFormat="of " target="RFC5288"/> for security considerations that apply specifically to AES- GCM when used with TLS.</t>
<section anchor="nonce-reuse"> <section anchor="nonce-reuse">
<name> Nonce Reuse in TLS 1.2</name> <name> Nonce Reuse in TLS 1.2</name>
<t>The existence of deployed TLS stacks that mistakenly reuse the AES- GCM nonce is <t>The existence of deployed TLS stacks that mistakenly reuse the AES- GCM nonce is
documented in <xref target="Boeck2016"/>, showing there is an actual risk of AES -GCM getting documented in <xref target="Boeck2016"/>, showing there is an actual risk of AES -GCM getting
implemented insecurely and thus making TLS sessions that use an implemented insecurely and thus making TLS sessions that use an
AES-GCM cipher suite vulnerable to attacks such as <xref target="Joux2006"/>. ( See <xref target="CVE"/> AES-GCM cipher suite vulnerable to attacks such as <xref target="Joux2006"/>. ( See <xref target="CVE"/>
records: CVE-2016-0270, CVE-2016-10213, CVE-2016-10212, CVE-2017-5933.)</t> records: CVE-2016-0270, CVE-2016-10213, CVE-2016-10212, and CVE-2017-5933.)</t>
<t>While this problem has been fixed in TLS 1.3, which enforces a dete rministic <t>While this problem has been fixed in TLS 1.3, which enforces a dete rministic
method to generate nonces from record sequence numbers and shared secrets for method to generate nonces from record sequence numbers and shared secrets for
all of its AEAD cipher suites (including AES-GCM), TLS 1.2 implementations all its AEAD cipher suites (including AES-GCM), TLS 1.2 implementations
could still choose their own (potentially insecure) nonce generation methods.</t > could still choose their own (potentially insecure) nonce generation methods.</t >
<t>It is therefore <bcp14>RECOMMENDED</bcp14> that TLS 1.2 implementat ions use the 64-bit <t>It is therefore <bcp14>RECOMMENDED</bcp14> that TLS 1.2 implementat ions use the 64-bit
sequence number to populate the <tt>nonce_explicit</tt> part of the GCM nonce, a s sequence number to populate the <tt>nonce_explicit</tt> part of the GCM nonce, a s
described in the first two paragraphs of <xref section="5.3" sectionFormat="of" described in the first two paragraphs of <xref section="5.3" sectionFormat="of"
target="RFC8446"/>. This stronger recommendation updates <xref section="3" secti target="RFC8446"/>. This stronger recommendation updates <xref section="3" secti
onFormat="of" target="RFC5288"/>, which specified that the use of 64-bit sequenc onFormat="of" target="RFC5288"/>, which specifies that the use of 64-bit sequenc
e numbers to populate the <tt>nonce_explicit</tt> field was optional.</t> e numbers to populate the <tt>nonce_explicit</tt> field is optional.</t>
<t>We note that at the time of writing there are no cipher suites defi <t>We note that at the time of writing, there are no cipher suites def
ned for nonce ined for nonce-reuse-resistant algorithms such as AES-GCM-SIV <xref target="RFC8
reuse resistant algorithms such as AES-GCM-SIV <xref target="RFC8452"/>.</t> 452"/>.</t>
</section> </section>
</section> </section>
<section anchor="sec-pfs"> <section anchor="sec-pfs">
<name>Forward Secrecy</name> <name>Forward Secrecy</name>
<t>Forward secrecy (also called "perfect forward secrecy" or "PFS" and d efined in <xref target="RFC4949"/>) is a defense against an attacker who records encrypted conversations where the session keys are only encrypted with the comm unicating parties' long-term keys.</t> <t>Forward secrecy (also called "perfect forward secrecy" or "PFS" and d efined in <xref target="RFC4949"/>) is a defense against an attacker who records encrypted conversations where the session keys are only encrypted with the comm unicating parties' long-term keys.</t>
<t>Should the attacker be able to obtain these long-term keys at some po int later in time, the session keys and thus the entire conversation could be de crypted.</t> <t>Should the attacker be able to obtain these long-term keys at some po int later in time, the session keys and thus the entire conversation could be de crypted.</t>
<t>In the context of TLS and DTLS, such compromise of long-term keys is not entirely implausible. It can happen, for example, due to:</t> <t>In the context of TLS and DTLS, such compromise of long-term keys is not entirely implausible. It can happen, for example, due to:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>A client or server being attacked by some other attack vector, and the private key retrieved.</li> <li>A client or server being attacked by some other attack vector, and the private key retrieved.</li>
<li>A long-term key retrieved from a device that has been sold or othe rwise decommissioned without prior wiping.</li> <li>A long-term key retrieved from a device that has been sold or othe rwise decommissioned without prior wiping.</li>
<li>A long-term key used on a device as a default key <xref target="He ninger2012"/>.</li> <li>A long-term key used on a device as a default key <xref target="He ninger2012"/>.</li>
<li>A key generated by a trusted third party like a CA, and later retr <li>A key generated by a trusted third party like a CA and later retri
ieved from it either by extortion or compromise <xref target="Soghoian2011"/>.</ eved from it by either extortion or compromise <xref target="Soghoian2011"/>.</l
li> i>
<li>A cryptographic break-through, or the use of asymmetric keys with <li>A cryptographic breakthrough or the use of asymmetric keys with in
insufficient length <xref target="Kleinjung2010"/>.</li> sufficient length <xref target="Kleinjung2010"/>.</li>
<li>Social engineering attacks against system administrators.</li> <li>Social engineering attacks against system administrators.</li>
<li>Collection of private keys from inadequately protected backups.</l i> <li>Collection of private keys from inadequately protected backups.</l i>
</ul> </ul>
<t>Forward secrecy ensures in such cases that it is not feasible for an attacker to determine the session keys even if the attacker has obtained the lon g-term keys some time after the conversation. It also protects against an attack er who is in possession of the long-term keys but remains passive during the con versation.</t> <t>Forward secrecy ensures in such cases that it is not feasible for an attacker to determine the session keys even if the attacker has obtained the lon g-term keys some time after the conversation. It also protects against an attack er who is in possession of the long-term keys but remains passive during the con versation.</t>
<t>Forward secrecy is generally achieved by using the Diffie-Hellman sch eme to derive session keys. The Diffie-Hellman scheme has both parties maintain private secrets and send parameters over the network as modular powers over cert ain cyclic groups. The properties of the so-called Discrete Logarithm Problem (D LP) allow the parties to derive the session keys without an eavesdropper being a ble to do so. There is currently no known attack against DLP if sufficiently lar ge parameters are chosen. A variant of the Diffie-Hellman scheme uses elliptic c urves instead of the originally proposed modular arithmetic. Given the current s tate of the art, elliptic-curve Diffie-Hellman appears to be more efficient, per mits shorter key lengths, and allows less freedom for implementation errors than finite-field Diffie-Hellman.</t> <t>Forward secrecy is generally achieved by using the Diffie-Hellman sch eme to derive session keys. The Diffie-Hellman scheme has both parties maintain private secrets and send parameters over the network as modular powers over cert ain cyclic groups. The properties of the so-called Discrete Logarithm Problem (D LP) allow the parties to derive the session keys without an eavesdropper being a ble to do so. There is currently no known attack against DLP if sufficiently lar ge parameters are chosen. A variant of the Diffie-Hellman scheme uses elliptic c urves instead of the originally proposed modular arithmetic. Given the current s tate of the art, Elliptic Curve Diffie-Hellman appears to be more efficient, per mits shorter key lengths, and allows less freedom for implementation errors than finite-field Diffie-Hellman.</t>
<t>Unfortunately, many TLS/DTLS cipher suites were defined that do not f eature forward secrecy, e.g., TLS_RSA_WITH_AES_256_CBC_SHA256. This document th erefore advocates strict use of forward-secrecy-only ciphers.</t> <t>Unfortunately, many TLS/DTLS cipher suites were defined that do not f eature forward secrecy, e.g., TLS_RSA_WITH_AES_256_CBC_SHA256. This document th erefore advocates strict use of forward-secrecy-only ciphers.</t>
</section> </section>
<section anchor="sec-dhe"> <section anchor="sec-dhe">
<name>Diffie-Hellman Exponent Reuse</name> <name>Diffie-Hellman Exponent Reuse</name>
<t>For performance reasons, it is not uncommon for TLS implementations t o reuse Diffie-Hellman and Elliptic Curve Diffie-Hellman exponents across multip le connections. Such reuse can result in major security issues:</t> <t>For performance reasons, it is not uncommon for TLS implementations t o reuse Diffie-Hellman and Elliptic Curve Diffie-Hellman exponents across multip le connections. Such reuse can result in major security issues:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If exponents are reused for too long (in some cases, even as littl e as a few hours), an attacker who gains access to the host can decrypt previous connections. In other words, exponent reuse negates the effects of forward secr ecy.</li> <li>If exponents are reused for too long (in some cases, even as littl e as a few hours), an attacker who gains access to the host can decrypt previous connections. In other words, exponent reuse negates the effects of forward secr ecy.</li>
<li>TLS implementations that reuse exponents should test the DH public key they receive for group membership, in order to avoid some known attacks. Th ese tests are not standardized in TLS at the time of writing, although general g uidance in this area is provided by <xref target="NIST.SP.800-56A"/> and availab le in many protocol implementations.</li> <li>TLS implementations that reuse exponents should test the DH public key they receive for group membership, in order to avoid some known attacks. Th ese tests are not standardized in TLS at the time of writing, although general g uidance in this area is provided by <xref target="NIST.SP.800-56A"/> and availab le in many protocol implementations.</li>
<li>Under certain conditions, the use of static finite-field DH keys, or of ephemeral finite-field DH keys that are reused across multiple connections , can lead to timing attacks (such as those described in <xref target="RACCOON"/ >) on the shared secrets used in Diffie-Hellman key exchange.</li> <li>Under certain conditions, the use of static finite-field DH keys, or of ephemeral finite-field DH keys that are reused across multiple connections , can lead to timing attacks (such as those described in <xref target="RACCOON"/ >) on the shared secrets used in Diffie-Hellman key exchange.</li>
<li>An "invalid curve" attack can be mounted against elliptic-curve DH if the victim does not verify that the received point lies on the correct curve . If the victim is reusing the DH secrets, the attacker can repeat the probe va rying the points to recover the full secret (see <xref target="Antipa2003"/> and <xref target="Jager2015"/>).</li> <li>An "invalid curve" attack can be mounted against Elliptic Curve DH if the victim does not verify that the received point lies on the correct curve . If the victim is reusing the DH secrets, the attacker can repeat the probe va rying the points to recover the full secret (see <xref target="Antipa2003"/> and <xref target="Jager2015"/>).</li>
</ul> </ul>
<t>To address these concerns:</t> <t>To address these concerns:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>TLS implementations <bcp14>SHOULD NOT</bcp14> use static finite-fi eld DH keys and <bcp14>SHOULD NOT</bcp14> reuse ephemeral finite-field DH keys a cross multiple connections.</li> <li>TLS implementations <bcp14>SHOULD NOT</bcp14> use static finite-fi eld DH keys and <bcp14>SHOULD NOT</bcp14> reuse ephemeral finite-field DH keys a cross multiple connections.</li>
<li>Server implementations that want to reuse elliptic-curve DH keys < bcp14>SHOULD</bcp14> either use a "safe curve" <xref target="SAFECURVES"/> (e.g. , X25519), or perform the checks described in <xref target="NIST.SP.800-56A"/> o n the received points.</li> <li>Server implementations that want to reuse Elliptic Curve DH keys < bcp14>SHOULD</bcp14> either use a "safe curve" <xref target="SAFECURVES"/> (e.g. , X25519) or perform the checks described in <xref target="NIST.SP.800-56A"/> on the received points.</li>
</ul> </ul>
</section> </section>
<section anchor="certificate-revocation"> <section anchor="certificate-revocation">
<name>Certificate Revocation</name> <name>Certificate Revocation</name>
<t>The following considerations and recommendations represent the curren t state of the art regarding certificate revocation, even though no complete and efficient solution exists for the problem of checking the revocation status of common public key certificates <xref target="RFC5280"/>:</t> <t>The following considerations and recommendations represent the curren t state of the art regarding certificate revocation, even though no complete and efficient solution exists for the problem of checking the revocation status of common public key certificates <xref target="RFC5280"/>:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Certificate revocation is an important tool when recovering from a ttacks on the TLS implementation, as well as cases of misissued certificates. TL S implementations <bcp14>MUST</bcp14> implement a strategy to distrust revoked c ertificates.</li> <li>Certificate revocation is an important tool when recovering from a ttacks on the TLS implementation as well as cases of misissued certificates. TLS implementations <bcp14>MUST</bcp14> implement a strategy to distrust revoked ce rtificates.</li>
<li>Although Certificate Revocation Lists (CRLs) are the most widely s upported mechanism for distributing revocation information, they have known scal ing challenges that limit their usefulness, despite workarounds such as partitio ned CRLs and delta CRLs. The more modern <xref target="CRLite"/> and the follow- on Let's Revoke <xref target="LetsRevoke"/> build on the availability of Certifi cate Transparency <xref target="RFC9162"/> logs and aggressive compression to al low practical use of the CRL infrastructure, but at the time of writing, neither solution is deployed for client-side revocation processing at scale.</li> <li>Although Certificate Revocation Lists (CRLs) are the most widely s upported mechanism for distributing revocation information, they have known scal ing challenges that limit their usefulness, despite workarounds such as partitio ned CRLs and delta CRLs. The more modern <xref target="CRLite"/> and the follow- on Let's Revoke <xref target="LetsRevoke"/> build on the availability of Certifi cate Transparency <xref target="RFC9162"/> logs and aggressive compression to al low practical use of the CRL infrastructure, but at the time of writing, neither solution is deployed for client-side revocation processing at scale.</li>
<li>Proprietary mechanisms that embed revocation lists in the Web brow <li>Proprietary mechanisms that embed revocation lists in the web brow
ser's configuration database cannot scale beyond the few, most heavily used Web ser's configuration database cannot scale beyond the few most heavily used web s
servers.</li> ervers.</li>
<li>The On-Line Certification Status Protocol (OCSP) <xref target="RFC <li>The Online Certification Status Protocol (OCSP) <xref target="RFC6
6960"/> in its basic form presents both scaling and privacy issues. In addition, 960"/> in its basic form presents both scaling and privacy issues. In addition,
clients typically "soft-fail", meaning that they do not abort the TLS connectio clients typically "soft-fail", meaning that they do not abort the TLS connection
n if the OCSP server does not respond. (However, this might be a workaround to a if the OCSP server does not respond. (However, this might be a workaround to av
void denial-of-service attacks if an OCSP responder is taken offline.). For an u oid denial-of-service attacks if an OCSP responder is taken offline.) For a rece
p-to-date survey of the status of OCSP deployment in the Web PKI see <xref targe nt survey of the status of OCSP deployment in the web PKI, see <xref target="Chu
t="Chung18"/>.</li> ng18"/>.</li>
<li>The TLS Certificate Status Request extension (<xref section="8" se <li>The TLS Certificate Status Request extension (<xref section="8" se
ctionFormat="of" target="RFC6066"/>), commonly called "OCSP stapling", resolves ctionFormat="of" target="RFC6066"/>), commonly called "OCSP stapling", resolves
the operational issues with OCSP. However, it is still ineffective in the presen the operational issues with OCSP. However, it is still ineffective in the presen
ce of a MITM attacker because the attacker can simply ignore the client's reques ce of an active on-path attacker because the attacker can simply ignore the clie
t for a stapled OCSP response.</li> nt's request for a stapled OCSP response.</li>
<li> <li>
<xref target="RFC7633"/> defines a certificate extension that indica tes that clients must expect stapled OCSP responses for the certificate and must abort the handshake ("hard-fail") if such a response is not available.</li> <xref target="RFC7633"/> defines a certificate extension that indica tes that clients must expect stapled OCSP responses for the certificate and must abort the handshake ("hard-fail") if such a response is not available.</li>
<li>OCSP stapling as used in TLS 1.2 does not extend to intermediate c <li>OCSP stapling as used in TLS 1.2 does not extend to intermediate c
ertificates within a certificate chain. The Multiple Certificate Status extensio ertificates within a certificate chain. The Multiple Certificate Status extensio
n <xref target="RFC6961"/> addresses this shortcoming, but it has seen little de n <xref target="RFC6961"/> addresses this shortcoming, but it has seen little de
ployment and had been deprecated by <xref target="RFC8446"/>. As a result, we no ployment and had been deprecated by <xref target="RFC8446"/>. As a result, altho
longer recommend this extension for TLS 1.2.</li> ugh this extension was recommended for TLS 1.2 in <xref target="RFC7525"/>, it i
<li>TLS 1.3 (<xref section="4.4.2.1" sectionFormat="of" target="RFC844 s no longer recommended by this document.</li>
6"/>) allows the association of OCSP information with intermediate certificates <li>TLS 1.3 (<xref section="4.4.2.1" sectionFormat="of" target="RFC844
by using an extension to the CertificateEntry structure. However, using this fac 6"/>) allows the association of OCSP information with intermediate certificates
ility remains impractical because many CAs either do not publish OCSP for CA cer by using an extension to the CertificateEntry structure. However, using this fac
tificates or publish OCSP reports with a lifetime that is too long to be useful. ility remains impractical because many certification authorities (CAs) either do
</li> not publish OCSP for CA certificates or publish OCSP reports with a lifetime th
at is too long to be useful.</li>
<li>Both CRLs and OCSP depend on relatively reliable connectivity to t he Internet, which might not be available to certain kinds of nodes. A common ex ample is newly provisioned devices that need to establish a secure connection in order to boot up for the first time.</li> <li>Both CRLs and OCSP depend on relatively reliable connectivity to t he Internet, which might not be available to certain kinds of nodes. A common ex ample is newly provisioned devices that need to establish a secure connection in order to boot up for the first time.</li>
</ul> </ul>
<t>For the common use cases of public key certificates in TLS, servers < <t>For the common use cases of public key certificates in TLS, servers <
bcp14>SHOULD</bcp14> support the following as a best practice given the current bcp14>SHOULD</bcp14> support the following as a best practice given the current
state of the art and as a foundation for a possible future solution: OCSP <xref state of the art and as a foundation for a possible future solution: OCSP <xref
target="RFC6960"/> and OCSP stapling using the <tt>status_request</tt> extension target="RFC6960"/> and OCSP stapling using the <tt>status_request</tt> extension
defined in <xref target="RFC6066"/>. Note that the exact mechanism for embeddin defined in <xref target="RFC6066"/>. Note that the exact mechanism for embeddin
g the <tt>status_request</tt> extension differs between TLS 1.2 and 1.3. As a ma g the <tt>status_request</tt> extension differs between TLS 1.2 and 1.3. As a ma
tter of local policy, server operators <bcp14>MAY</bcp14> request that CAs issue tter of local policy, server operators <bcp14>MAY</bcp14> request that CAs issue
must-staple <xref target="RFC7633"/> certificates for the server and/or for cli must-staple <xref target="RFC7633"/> certificates for the server and/or for cli
ent authentication, but we recommend to review the operational conditions before ent authentication, but we recommend reviewing the operational conditions before
deciding on this approach.</t> deciding on this approach.</t>
<t>The considerations in this section do not apply to scenarios where th <t>The considerations in this section do not apply to scenarios where th
e DANE-TLSA resource record <xref target="RFC6698"/> is used to signal to a clie e DNS-Based
nt which certificate a server considers valid and good to use for TLS connection Authentication of Named Entities (DANE) TLSA resource record <xref
s.</t> target="RFC6698"/> is used to signal to a client which certificate a server con
siders valid and good to use for TLS connections.</t>
</section> </section>
</section> </section>
<section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name>
<t>Thanks to
Alexey Melnikov,
Alvaro Retana,
Andrei Popov,
Ben Kaduk,
Christian Huitema,
Corey Bonnell,
Cullen Jennings,
Daniel Kahn Gillmor,
David Benjamin,
Eric Rescorla,
<contact fullname="Éric Vyncke"/>,
Francesca Palombini,
Hannes Tschofenig,
Hubert Kario,
Ilari Liusvaara,
John Mattsson,
John R Levine,
<contact fullname="Julien Élie"/>,
Lars Eggert,
Leif Johansson,
Magnus Westerlund,
Martin Duke,
Martin Thomson,
Mohit Sahni,
Nick Sullivan,
Nimrod Aviram,
Paul Wouters,
Peter Gutmann,
Rich Salz,
Robert Sayre,
Robert Wilton,
Roman Danyliw,
Ryan Sleevi,
Sean Turner,
Stephen Farrell,
Tim Evans,
Valery Smyslov,
Viktor Dukhovni
and Warren Kumari
for helpful comments and discussions that have shaped this document.</t>
<t>The authors gratefully acknowledge the contribution of Ralph Holz, who
was a coauthor of RFC 7525, the previous version of this document.</t>
<t>See RFC 7525 for additional acknowledgments for the previous revision o
f this document.</t>
</section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-tls-esni" to="TLS-ECH"/>
<displayreference target="I-D.ietf-uta-tls13-iot-profile" to="IOT-PROFILE"/>
<displayreference target="I-D.irtf-cfrg-aead-limits" to="AEAD-LIMITS"/>
<displayreference target="I-D.mattsson-cfrg-det-sigs-with-noise" to="CFRG-DE
T-SIGS"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC7465" target="https://www.rfc-editor.org/info/rfc7
465"> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.21
<front> 19.xml"/>
<title>Prohibiting RC4 Cipher Suites</title> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.37
<author fullname="A. Popov" initials="A." surname="Popov"> 66.xml"/>
<organization/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.52
</author> 46.xml"/>
<date month="February" year="2015"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.52
<abstract> 88.xml"/>
<t>This document requires that Transport Layer Security (TLS) clie <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.57
nts and servers never negotiate the use of RC4 cipher suites when they establish 46.xml"/>
connections. This applies to all TLS versions. This document updates RFCs 524 <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.60
6, 4346, and 2246.</t> 66.xml"/>
</abstract> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.61
</front> 25.xml"/>
<seriesInfo name="RFC" value="7465"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.61
<seriesInfo name="DOI" value="10.17487/RFC7465"/> 76.xml"/>
</reference> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.63
<reference anchor="RFC5246" target="https://www.rfc-editor.org/info/rfc5 47.xml"/>
246"> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.69
<front> 79.xml"/>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</titl <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.73
e> 01.xml"/>
<author fullname="T. Dierks" initials="T." surname="Dierks"> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.73
<organization/> 66.xml"/>
</author> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.74
<author fullname="E. Rescorla" initials="E." surname="Rescorla"> 65.xml"/>
<organization/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.76
</author> 27.xml"/>
<date month="August" year="2008"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.77
<abstract> 48.xml"/>
<t>This document specifies Version 1.2 of the Transport Layer Secu <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.81
rity (TLS) protocol. The TLS protocol provides communications security over the 74.xml"/>
Internet. The protocol allows client/server applications to communicate in a w <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.84
ay that is designed to prevent eavesdropping, tampering, or message forgery. [S 22.xml"/>
TANDARDS-TRACK]</t> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.84
</abstract> 46.xml"/>
</front> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.89
<seriesInfo name="RFC" value="5246"/> 96.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC5246"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.91
</reference> 47.xml"/>
<reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6 <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.91
347"> 55.xml"/>
<front>
<title>Datagram Transport Layer Security Version 1.2</title> </references>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"> <references>
<organization/> <name>Informative References</name>
</author>
<author fullname="N. Modadugu" initials="N." surname="Modadugu"> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.20
<organization/> 26.xml"/>
</author> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.22
<date month="January" year="2012"/> 46.xml"/>
<abstract> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3
<t>This document specifies version 1.2 of the Datagram Transport L 261.xml"/>
ayer Security (DTLS) protocol. The DTLS protocol provides communications privac <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.36
y for datagram protocols. The protocol allows client/server applications to com 02.xml"/>
municate in a way that is designed to prevent eavesdropping, tampering, or messa <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.43
ge forgery. The DTLS protocol is based on the Transport Layer Security (TLS) pr 46.xml"/>
otocol and provides equivalent security guarantees. Datagram semantics of the u <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.43
nderlying transport are preserved by the DTLS protocol. This document updates D 47.xml"/>
TLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.49
</abstract> 49.xml"/>
</front> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.50
<seriesInfo name="RFC" value="6347"/> 77.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC6347"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.51
</reference> 16.xml"/>
<reference anchor="RFC8996" target="https://www.rfc-editor.org/info/rfc8 <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.52
996"> 80.xml"/>
<front> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.53
<title>Deprecating TLS 1.0 and TLS 1.1</title> 21.xml"/>
<author fullname="K. Moriarty" initials="K." surname="Moriarty"> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.61
<organization/> 01.xml"/>
</author> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.61
<author fullname="S. Farrell" initials="S." surname="Farrell"> 20.xml"/>
<organization/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.66
</author> 98.xml"/>
<date month="March" year="2021"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.67
<abstract> 97.xml"/>
<t>This document formally deprecates Transport Layer Security (TLS <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.69
) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have 60.xml"/>
been moved to Historic status. These versions lack support for current and recom <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.69
mended cryptographic algorithms and mechanisms, and various government and indus 61.xml"/>
try profiles of applications using TLS now mandate avoiding these old TLS versio <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.72
ns. TLS version 1.2 became the recommended version for IETF protocols in 2008 (s 28.xml"/>
ubsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient ti <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.75
me to transition away from older versions. Removing support for older versions f 07.xml"/>
rom implementations reduces the attack surface, reduces opportunity for misconfi <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.75
guration, and streamlines library and product maintenance. </t> 25.xml"/>
<t>This document also deprecates Datagram TLS (DTLS) version 1.0 ( <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.75
RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1.</t> 90.xml"/>
<t>This document updates many RFCs that normatively refer to TLS v <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.74
ersion 1.0 or TLS version 1.1, as described herein. This document also updates t 35.xml"/>
he best practices for TLS usage in RFC 7525; hence, it is part of BCP 195.</t> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.74
</abstract> 57.xml"/>
</front> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.76
<seriesInfo name="BCP" value="195"/> 33.xml"/>
<seriesInfo name="RFC" value="8996"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.76
<seriesInfo name="DOI" value="10.17487/RFC8996"/> 72.xml"/>
</reference> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.76
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8 73.xml"/>
446"> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.75
<front> 68.xml"/>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.91
e> 10.xml"/>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.91
<organization/> 12.xml"/>
</author> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.91
<date month="August" year="2018"/> 13.xml"/>
<abstract> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.77
<t>This document specifies version 1.3 of the Transport Layer Secu 12.xml"/>
rity (TLS) protocol. TLS allows client/server applications to communicate over <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.79
the Internet in a way that is designed to prevent eavesdropping, tampering, and 19.xml"/>
message forgery.</t> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.79
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50 24.xml"/>
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 i <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.79
mplementations.</t> 25.xml"/>
</abstract> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.84
</front> 52.xml"/>
<seriesInfo name="RFC" value="8446"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.84
<seriesInfo name="DOI" value="10.17487/RFC8446"/> 61.xml"/>
</reference> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.84
<reference anchor="RFC9147" target="https://www.rfc-editor.org/info/rfc9 70.xml"/>
147"> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.88
<front> 79.xml"/>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.90
1.3</title> 00.xml"/>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.90
<organization/> 01.xml"/>
</author> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.90
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"> 51.xml"/>
<organization/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.91
</author> 62.xml"/>
<author fullname="N. Modadugu" initials="N." surname="Modadugu">
<organization/> <!-- Note: RFC 9191 library has wrong name for J. Preuß Mattsson. Long way used
</author> instead.
<date month="April" year="2022"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9191.xml"
<abstract> />
<t>This document specifies version 1.3 of the Datagram Transport L -->
ayer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to com <reference anchor="RFC9191" target="https://www.rfc-editor.org/info/rfc9191">
municate over the Internet in a way that is designed to prevent eavesdropping, t
ampering, and message forgery.</t>
<t>The DTLS 1.3 protocol is based on the Transport Layer Security
(TLS) 1.3 protocol and provides equivalent security guarantees with the exceptio
n of order protection / non-replayability. Datagram semantics of the underlying
transport are preserved by the DTLS protocol.</t>
<t>This document obsoletes RFC 6347.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9147"/>
<seriesInfo name="DOI" value="10.17487/RFC9147"/>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization/>
</author>
<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.
This document defines these words as they should be interpreted in IETF document
s. This document specifies an Internet Best Current Practices for the Internet
Community, 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" target="https://www.rfc-editor.org/info/rfc8
174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba">
<organization/>
</author>
<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 tha
t 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="RFC6176" target="https://www.rfc-editor.org/info/rfc6
176">
<front>
<title>Prohibiting Secure Sockets Layer (SSL) Version 2.0</title>
<author fullname="S. Turner" initials="S." surname="Turner">
<organization/>
</author>
<author fullname="T. Polk" initials="T." surname="Polk">
<organization/>
</author>
<date month="March" year="2011"/>
<abstract>
<t>This document requires that when Transport Layer Security (TLS)
clients and servers establish connections, they never negotiate the use of Sec
ure Sockets Layer (SSL) version 2.0. This document updates the backward compat
ibility sections found in the Transport Layer Security (TLS). [STANDARDS-TRACK]<
/t>
</abstract>
</front>
<seriesInfo name="RFC" value="6176"/>
<seriesInfo name="DOI" value="10.17487/RFC6176"/>
</reference>
<reference anchor="RFC5746" target="https://www.rfc-editor.org/info/rfc5
746">
<front>
<title>Transport Layer Security (TLS) Renegotiation Indication Exten
sion</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization/>
</author>
<author fullname="M. Ray" initials="M." surname="Ray">
<organization/>
</author>
<author fullname="S. Dispensa" initials="S." surname="Dispensa">
<organization/>
</author>
<author fullname="N. Oskov" initials="N." surname="Oskov">
<organization/>
</author>
<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
handshake 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 sp
ecification defines a TLS extension to cryptographically tie renegotiations to t
he TLS connections they are being performed over, thus preventing this attack.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5746"/>
<seriesInfo name="DOI" value="10.17487/RFC5746"/>
</reference>
<reference anchor="RFC7627" target="https://www.rfc-editor.org/info/rfc7
627">
<front>
<title>Transport Layer Security (TLS) Session Hash and Extended Mast
er Secret Extension</title>
<author fullname="K. Bhargavan" initials="K." role="editor" surname=
"Bhargavan">
<organization/>
</author>
<author fullname="A. Delignat-Lavaud" initials="A." surname="Deligna
t-Lavaud">
<organization/>
</author>
<author fullname="A. Pironti" initials="A." surname="Pironti">
<organization/>
</author>
<author fullname="A. Langley" initials="A." surname="Langley">
<organization/>
</author>
<author fullname="M. Ray" initials="M." surname="Ray">
<organization/>
</author>
<date month="September" year="2015"/>
<abstract>
<t>The Transport Layer Security (TLS) master secret is not cryptog
raphically bound to important session parameters such as the server certificate.
Consequently, it is possible for an active attacker to set up two sessions, on
e with a client and another with a server, such that the master secrets on the t
wo sessions are the same. Thereafter, any mechanism that relies on the master s
ecret for authentication, including session resumption, becomes vulnerable to a
man-in-the-middle attack, where the attacker can simply forward messages back an
d forth between the client and server. This specification defines a TLS extensi
on that contextually binds the master secret to a log of the full handshake that
computes it, thus preventing such attacks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7627"/>
<seriesInfo name="DOI" value="10.17487/RFC7627"/>
</reference>
<reference anchor="RFC7301" target="https://www.rfc-editor.org/info/rfc7
301">
<front>
<title>Transport Layer Security (TLS) Application-Layer Protocol Neg
otiation Extension</title>
<author fullname="S. Friedl" initials="S." surname="Friedl">
<organization/>
</author>
<author fullname="A. Popov" initials="A." surname="Popov">
<organization/>
</author>
<author fullname="A. Langley" initials="A." surname="Langley">
<organization/>
</author>
<author fullname="E. Stephan" initials="E." surname="Stephan">
<organization/>
</author>
<date month="July" year="2014"/>
<abstract>
<t>This document describes a Transport Layer Security (TLS) extens
ion for application-layer protocol negotiation within the TLS handshake. For ins
tances in which multiple application protocols are supported on the same TCP or
UDP port, this extension allows the application layer to negotiate which protoco
l will be used within the TLS connection.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7301"/>
<seriesInfo name="DOI" value="10.17487/RFC7301"/>
</reference>
<reference anchor="RFC3766" target="https://www.rfc-editor.org/info/rfc3
766">
<front>
<title>Determining Strengths For Public Keys Used For Exchanging Sym
metric Keys</title>
<author fullname="H. Orman" initials="H." surname="Orman">
<organization/>
</author>
<author fullname="P. Hoffman" initials="P." surname="Hoffman">
<organization/>
</author>
<date month="April" year="2004"/>
<abstract>
<t>Implementors of systems that use public key cryptography to exc
hange symmetric keys need to make the public keys resistant to some predetermine
d level of attack. That level of attack resistance is the strength of the syste
m, and the symmetric keys that are exchanged must be at least as strong as the s
ystem strength requirements. The three quantities, system strength, symmetric k
ey strength, and public key strength, must be consistently matched for any netwo
rk protocol usage. While it is fairly easy to express the system strength requi
rements in terms of a symmetric key length and to choose a cipher that has a key
length equal to or exceeding that requirement, it is harder to choose a public
key that has a cryptographic strength meeting a symmetric key strength requireme
nt. This document explains how to determine the length of an asymmetric key as
a function of a symmetric key strength requirement. Some rules of thumb for est
imating equivalent resistance to large-scale attacks on various algorithms are g
iven. The document also addresses how changing the sizes of the underlying larg
e integers (moduli, group sizes, exponents, and so on) changes the time to use t
he algorithms for key exchange. This document specifies an Internet Best Curren
t Practices for the Internet Community, and requests discussion and suggestions
for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="86"/>
<seriesInfo name="RFC" value="3766"/>
<seriesInfo name="DOI" value="10.17487/RFC3766"/>
</reference>
<reference anchor="RFC7366" target="https://www.rfc-editor.org/info/rfc7
366">
<front>
<title>Encrypt-then-MAC for Transport Layer Security (TLS) and Datag
ram Transport Layer Security (DTLS)</title>
<author fullname="P. Gutmann" initials="P." surname="Gutmann">
<organization/>
</author>
<date month="September" year="2014"/>
<abstract>
<t>This document describes a means of negotiating the use of the e
ncrypt-then-MAC security mechanism in place of the existing MAC-then-encrypt mec
hanism in Transport Layer Security (TLS) and Datagram Transport Layer Security (
DTLS). The MAC-then-encrypt mechanism has been the subject of a number of secur
ity vulnerabilities over a period of many years.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7366"/>
<seriesInfo name="DOI" value="10.17487/RFC7366"/>
</reference>
<reference anchor="RFC6979" target="https://www.rfc-editor.org/info/rfc6
979">
<front>
<title>Deterministic Usage of the Digital Signature Algorithm (DSA)
and Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
<author fullname="T. Pornin" initials="T." surname="Pornin">
<organization/>
</author>
<date month="August" year="2013"/>
<abstract>
<t>This document defines a deterministic digital signature generat
ion procedure. Such signatures are compatible with standard Digital Signature A
lgorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital si
gnatures and can be processed with unmodified verifiers, which need not be aware
of the procedure described therein. Deterministic signatures retain the crypto
graphic security features associated with digital signatures but can be more eas
ily implemented in various environments, since they do not need access to a sour
ce of high-quality randomness.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6979"/>
<seriesInfo name="DOI" value="10.17487/RFC6979"/>
</reference>
<reference anchor="RFC8422" target="https://www.rfc-editor.org/info/rfc8
422">
<front>
<title>Elliptic Curve Cryptography (ECC) Cipher Suites for Transport
Layer Security (TLS) Versions 1.2 and Earlier</title>
<author fullname="Y. Nir" initials="Y." surname="Nir">
<organization/>
</author>
<author fullname="S. Josefsson" initials="S." surname="Josefsson">
<organization/>
</author>
<author fullname="M. Pegourie-Gonnard" initials="M." surname="Pegour
ie-Gonnard">
<organization/>
</author>
<date month="August" year="2018"/>
<abstract>
<t>This document describes key exchange algorithms based on Ellipt
ic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In
particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (EC
DHE) key agreement in a TLS handshake and the use of the Elliptic Curve Digital
Signature Algorithm (ECDSA) and Edwards-curve Digital Signature Algorithm (EdDSA
) as authentication mechanisms.</t>
<t>This document obsoletes RFC 4492.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8422"/>
<seriesInfo name="DOI" value="10.17487/RFC8422"/>
</reference>
<reference anchor="RFC7748" target="https://www.rfc-editor.org/info/rfc7
748">
<front>
<title>Elliptic Curves for Security</title>
<author fullname="A. Langley" initials="A." surname="Langley">
<organization/>
</author>
<author fullname="M. Hamburg" initials="M." surname="Hamburg">
<organization/>
</author>
<author fullname="S. Turner" initials="S." surname="Turner">
<organization/>
</author>
<date month="January" year="2016"/>
<abstract>
<t>This memo specifies two elliptic curves over prime fields that
offer a high level of practical security in cryptographic applications, includin
g Transport Layer Security (TLS). These curves are intended to operate at the ~
128-bit and ~224-bit security level, respectively, and are generated determinist
ically based on a list of required properties.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7748"/>
<seriesInfo name="DOI" value="10.17487/RFC7748"/>
</reference>
<reference anchor="RFC9155" target="https://www.rfc-editor.org/info/rfc9
155">
<front>
<title>Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTL
S 1.2</title>
<author fullname="L. Velvindron" initials="L." surname="Velvindron">
<organization/>
</author>
<author fullname="K. Moriarty" initials="K." surname="Moriarty">
<organization/>
</author>
<author fullname="A. Ghedini" initials="A." surname="Ghedini">
<organization/>
</author>
<date month="December" year="2021"/>
<abstract>
<t>The MD5 and SHA-1 hashing algorithms are increasingly vulnerabl
e to attack, and this document deprecates their use in TLS 1.2 and DTLS 1.2 digi
tal signatures. However, this document does not deprecate SHA-1 with Hashed Mess
age Authentication Code (HMAC), as used in record protection. This document upda
tes RFC 5246.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9155"/>
<seriesInfo name="DOI" value="10.17487/RFC9155"/>
</reference>
<reference anchor="RFC6125" target="https://www.rfc-editor.org/info/rfc6
125">
<front>
<title>Representation and Verification of Domain-Based Application S
ervice Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Cer
tificates in the Context of Transport Layer Security (TLS)</title>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
">
<organization/>
</author>
<author fullname="J. Hodges" initials="J." surname="Hodges">
<organization/>
</author>
<date month="March" year="2011"/>
<abstract>
<t>Many application technologies enable secure communication betwe
en two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX
) certificates in the context of Transport Layer Security (TLS). This document s
pecifies procedures for representing and verifying the identity of application s
ervices in such interactions. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6125"/>
<seriesInfo name="DOI" value="10.17487/RFC6125"/>
</reference>
<reference anchor="RFC5288" target="https://www.rfc-editor.org/info/rfc5
288">
<front> <front>
<title>AES Galois Counter Mode (GCM) Cipher Suites for TLS</title> <title>Handling Large Certificates and Long Certificate Chains in TL
<author fullname="J. Salowey" initials="J." surname="Salowey"> S-Based EAP Methods</title>
<organization/> <author fullname="Mohit Sethi" initials="M." surname="Sethi">
</author>
<author fullname="A. Choudhury" initials="A." surname="Choudhury">
<organization/> <organization/>
</author> </author>
<author fullname="D. McGrew" initials="D." surname="McGrew"> <author fullname="John Preuß Mattsson" initials="J." surname="Preuß Mattsson">
<organization/> <organization/>
</author> </author>
<date month="August" year="2008"/> <author fullname="Sean Turner" initials="S." surname="Turner">
<abstract>
<t>This memo describes the use of the Advanced Encryption Standard
(AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) authenti
cated encryption operation. GCM provides both confidentiality and data origin a
uthentication, can be efficiently implemented in hardware for speeds of 10 gigab
its per second and above, and is also well-suited to software implementations.
This memo defines TLS cipher suites that use AES-GCM with RSA, DSA, and Diffie-H
ellman-based key exchange mechanisms. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5288"/>
<seriesInfo name="DOI" value="10.17487/RFC5288"/>
</reference>
<reference anchor="RFC6066" target="https://www.rfc-editor.org/info/rfc6
066">
<front>
<title>Transport Layer Security (TLS) Extensions: Extension Definiti
ons</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd">
<organization/> <organization/>
</author> </author>
<date month="January" year="2011"/> <date month="February" year="2022"/>
<abstract>
<t>This document provides specifications for existing TLS extensio
ns. It is a companion document for RFC 5246, "The Transport Layer Security (TLS
) Protocol Version 1.2". The extensions specified are server_name, max_fragment
_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_req
uest. [STANDARDS-TRACK]</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="6066"/> <seriesInfo name="RFC" value="9191"/>
<seriesInfo name="DOI" value="10.17487/RFC6066"/> <seriesInfo name="DOI" value="10.17487/RFC9191"/>
</reference> </reference>
</references>
<references> <reference anchor="TWIRL" target="https://cs.tau.ac.il/~tromer/papers/twi
<name>Informative References</name> rl.pdf">
<reference anchor="TWIRL" target="http://cs.tau.ac.il/~tromer/papers/twi
rl.pdf">
<front> <front>
<title>Factoring Large Numbers with the TWIRL Device</title> <title>Factoring Large Numbers with the TWIRL Device</title>
<author initials="A." surname="Shamir" fullname="Adi Shamir"> <author initials="A." surname="Shamir" fullname="Adi Shamir">
<organization/> <organization/>
</author> </author>
<author initials="E." surname="Tromer" fullname="Eran Tromer"> <author initials="E." surname="Tromer" fullname="Eran Tromer">
<organization/> <organization/>
</author> </author>
<date year="2003"/> <date year="2004"/>
</front> </front>
<seriesInfo name="proc. Crypto 2003, LNCS 2729, 1-26, Springer-Verlag" <seriesInfo name="DOI" value="10.1007/978-3-540-45146-4_1"/>
value=""/> <refcontent>2014 IEEE Symposium on Security and Privacy</refcontent>
</reference> </reference>
<reference anchor="Chung18">
<reference anchor="Chung18">
<front> <front>
<title>Is the Web Ready for OCSP Must-Staple?</title> <title>Is the Web Ready for OCSP Must-Staple?</title>
<author fullname="Taejoong Chung" initials="T." surname="Chung"> <author fullname="Taejoong Chung" initials="T." surname="Chung">
<organization>Rochester Institute of Technology and Northeastern U niversity</organization> <organization>Rochester Institute of Technology and Northeastern U niversity</organization>
</author> </author>
<author fullname="Jay Lok" initials="J." surname="Lok"> <author fullname="Jay Lok" initials="J." surname="Lok">
<organization>Northeastern University</organization> <organization>Northeastern University</organization>
</author> </author>
<author fullname="Balakrishnan Chandrasekaran" initials="B." surname ="Chandrasekaran"> <author fullname="Balakrishnan Chandrasekaran" initials="B." surname ="Chandrasekaran">
<organization>Max Planck Institute for Informatics</organization> <organization>Max Planck Institute for Informatics</organization>
skipping to change at line 1133 skipping to change at line 863
<organization>Akamai Technologies</organization> <organization>Akamai Technologies</organization>
</author> </author>
<author fullname="Nick Sullivan" initials="N." surname="Sullivan"> <author fullname="Nick Sullivan" initials="N." surname="Sullivan">
<organization>Cloudflare</organization> <organization>Cloudflare</organization>
</author> </author>
<author fullname="Christo Wilson" initials="C." surname="Wilson"> <author fullname="Christo Wilson" initials="C." surname="Wilson">
<organization>Northeastern University</organization> <organization>Northeastern University</organization>
</author> </author>
<date month="October" year="2018"/> <date month="October" year="2018"/>
</front> </front>
<seriesInfo name="Proceedings of the Internet Measurement Conference" value="2018"/>
<seriesInfo name="DOI" value="10.1145/3278532.3278543"/> <seriesInfo name="DOI" value="10.1145/3278532.3278543"/>
<refcontent>Proceedings of the Internet Measurement Conference 2018</re fcontent>
</reference> </reference>
<reference anchor="CRLite"> <reference anchor="CRLite">
<front> <front>
<title>CRLite: A Scalable System for Pushing All TLS Revocations to All Browsers</title> <title>CRLite: A Scalable System for Pushing All TLS Revocations to All Browsers</title>
<author fullname="James Larisch" initials="J." surname="Larisch"> <author fullname="James Larisch" initials="J." surname="Larisch">
<organization/> <organization/>
</author> </author>
<author fullname="David Choffnes" initials="D." surname="Choffnes"> <author fullname="David Choffnes" initials="D." surname="Choffnes">
<organization/> <organization/>
</author> </author>
<author fullname="Dave Levin" initials="D." surname="Levin"> <author fullname="Dave Levin" initials="D." surname="Levin">
skipping to change at line 1159 skipping to change at line 890
<organization/> <organization/>
</author> </author>
<author fullname="Alan Mislove" initials="A." surname="Mislove"> <author fullname="Alan Mislove" initials="A." surname="Mislove">
<organization/> <organization/>
</author> </author>
<author fullname="Christo Wilson" initials="C." surname="Wilson"> <author fullname="Christo Wilson" initials="C." surname="Wilson">
<organization/> <organization/>
</author> </author>
<date month="May" year="2017"/> <date month="May" year="2017"/>
</front> </front>
<seriesInfo name="2017 IEEE Symposium on Security and Privacy" value=" (SP)"/> <refcontent>2017 IEEE Symposium on Security and Privacy (SP)</refconte nt>
<seriesInfo name="DOI" value="10.1109/sp.2017.17"/> <seriesInfo name="DOI" value="10.1109/sp.2017.17"/>
</reference> </reference>
<reference anchor="LetsRevoke">
<reference anchor="LetsRevoke">
<front> <front>
<title>Let's Revoke: Scalable Global Certificate Revocation</title> <title>Let's Revoke: Scalable Global Certificate Revocation</title>
<author fullname="Trevor Smith" initials="T." surname="Smith"> <author fullname="Trevor Smith" initials="T." surname="Smith">
<organization/> <organization/>
</author> </author>
<author fullname="Luke Dickinson" initials="L." surname="Dickinson"> <author fullname="Luke Dickinson" initials="L." surname="Dickinson">
<organization/> <organization/>
</author> </author>
<author fullname="Kent Seamons" initials="K." surname="Seamons"> <author fullname="Kent Seamons" initials="K." surname="Seamons">
<organization/> <organization/>
</author> </author>
<date year="2020"/> <date month="February" year="2020"/>
</front> </front>
<seriesInfo name="Proceedings 2020 Network and Distributed System Secu rity" value="Symposium"/> <refcontent>Proceedings 2020 Network and Distributed System Security S ymposium</refcontent>
<seriesInfo name="DOI" value="10.14722/ndss.2020.24084"/> <seriesInfo name="DOI" value="10.14722/ndss.2020.24084"/>
</reference> </reference>
<reference anchor="DegabrieleP07">
<reference anchor="DegabrieleP07">
<front> <front>
<title>Attacking the IPsec Standards in Encryption-only Configuratio ns</title> <title>Attacking the IPsec Standards in Encryption-only Configuratio ns</title>
<author fullname="Jean Paul Degabriele" initials="J." surname="Degab riele"> <author fullname="Jean Paul Degabriele" initials="J." surname="Degab riele">
<organization/> <organization/>
</author> </author>
<author fullname="Kenneth G. Paterson" initials="K." surname="Paters on"> <author fullname="Kenneth G. Paterson" initials="K." surname="Paters on">
<organization/> <organization/>
</author> </author>
<date month="May" year="2007"/> <date month="May" year="2007"/>
</front> </front>
<seriesInfo name="2007 IEEE Symposium on Security and Privacy (SP" val ue="'07)"/> <refcontent>2007 IEEE Symposium on Security and Privacy (SP '07)</refc ontent>
<seriesInfo name="DOI" value="10.1109/sp.2007.8"/> <seriesInfo name="DOI" value="10.1109/sp.2007.8"/>
</reference> </reference>
<reference anchor="triple-handshake">
<reference anchor="Triple-Handshake">
<front> <front>
<title>Triple Handshakes and Cookie Cutters: Breaking and Fixing Aut hentication over TLS</title> <title>Triple Handshakes and Cookie Cutters: Breaking and Fixing Aut hentication over TLS</title>
<author fullname="Karthikeyan Bhargavan" initials="K." surname="Bhar gavan"> <author fullname="Karthikeyan Bhargavan" initials="K." surname="Bhar gavan">
<organization/> <organization/>
</author> </author>
<author fullname="Antoine Delignat Lavaud" initials="A." surname="La vaud"> <author fullname="Antoine Delignat Lavaud" initials="A." surname="La vaud">
<organization/> <organization/>
</author> </author>
<author fullname="Cedric Fournet" initials="C." surname="Fournet"> <author fullname="Cedric Fournet" initials="C." surname="Fournet">
<organization/> <organization/>
</author> </author>
<author fullname="Alfredo Pironti" initials="A." surname="Pironti"> <author fullname="Alfredo Pironti" initials="A." surname="Pironti">
<organization/> <organization/>
</author> </author>
<author fullname="Pierre Yves Strub" initials="P." surname="Strub"> <author fullname="Pierre Yves Strub" initials="P." surname="Strub">
<organization/> <organization/>
</author> </author>
<date month="May" year="2014"/> <date month="May" year="2014"/>
</front> </front>
<seriesInfo name="2014 IEEE Symposium on Security and" value="Privacy" /> <refcontent>2014 IEEE Symposium on Security and Privacy</refcontent>
<seriesInfo name="DOI" value="10.1109/sp.2014.14"/> <seriesInfo name="DOI" value="10.1109/sp.2014.14"/>
</reference> </reference>
<reference anchor="Soghoian2011">
<reference anchor="Soghoian2011">
<front> <front>
<title>Certified Lies: Detecting and Defeating Government Intercepti on Attacks Against SSL</title> <title>Certified Lies: Detecting and Defeating Government Intercepti on Attacks Against SSL</title>
<author fullname="Christopher Soghoian" initials="C." surname="Sogho ian"> <author fullname="Christopher Soghoian" initials="C." surname="Sogho ian">
<organization/> <organization/>
</author> </author>
<author fullname="Sid Stamm" initials="S." surname="Stamm"> <author fullname="Sid Stamm" initials="S." surname="Stamm">
<organization/> <organization/>
</author> </author>
<date year="2010"/> <date month="April" year="2010"/>
</front> </front>
<seriesInfo name="SSRN Electronic" value="Journal"/> <refcontent>SSRN Electronic Journal</refcontent>
<seriesInfo name="DOI" value="10.2139/ssrn.1591033"/> <seriesInfo name="DOI" value="10.2139/ssrn.1591033"/>
</reference> </reference>
<reference anchor="Logjam">
<reference anchor="Logjam">
<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 fullname="David Adrian" initials="D." surname="Adrian"> <author fullname="David Adrian" initials="D." surname="Adrian">
<organization>University of Michigan, Ann Arbor, MI, USA</organiza tion> <organization>University of Michigan, Ann Arbor, MI, USA</organiza tion>
</author> </author>
<author fullname="Karthikeyan Bhargavan" initials="K." surname="Bhar gavan"> <author fullname="Karthikeyan Bhargavan" initials="K." surname="Bhar gavan">
<organization>INRIA Paris-Rocquencourt, Paris, France</organizatio n> <organization>INRIA Paris-Rocquencourt, Paris, France</organizatio n>
</author> </author>
<author fullname="Zakir Durumeric" initials="Z." surname="Durumeric" > <author fullname="Zakir Durumeric" initials="Z." surname="Durumeric" >
<organization>University of Michigan, Ann Arbor, MI, USA</organiza tion> <organization>University of Michigan, Ann Arbor, MI, USA</organiza tion>
skipping to change at line 1277 skipping to change at line 1013
<organization>University of Michigan, Ann Arbor, MI, USA</organiza tion> <organization>University of Michigan, Ann Arbor, MI, USA</organiza tion>
</author> </author>
<author fullname="Santiago Zanella-Béguelin" initials="S." surname=" Zanella-Béguelin"> <author fullname="Santiago Zanella-Béguelin" initials="S." surname=" Zanella-Béguelin">
<organization>Microsoft Research, Cambridge, United Kingdom</organ ization> <organization>Microsoft Research, Cambridge, United Kingdom</organ ization>
</author> </author>
<author fullname="Paul Zimmermann" initials="P." surname="Zimmermann "> <author fullname="Paul Zimmermann" initials="P." surname="Zimmermann ">
<organization>INRIA Nancy-Grand Est, CNRS and Université de Lorrai ne, Nancy, France</organization> <organization>INRIA Nancy-Grand Est, CNRS and Université de Lorrai ne, Nancy, France</organization>
</author> </author>
<date month="October" year="2015"/> <date month="October" year="2015"/>
</front> </front>
<seriesInfo name="Proceedings of the 22nd ACM SIGSAC Conference on Com puter and Communications" value="Security"/> <refcontent>Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, pp. 5-17</refcontent>
<seriesInfo name="DOI" value="10.1145/2810103.2813707"/> <seriesInfo name="DOI" value="10.1145/2810103.2813707"/>
</reference> </reference>
<reference anchor="POODLE" target="https://www.us-cert.gov/ncas/alerts/T A14-290A"> <reference anchor="POODLE" target="https://www.us-cert.gov/ncas/alerts/T A14-290A">
<front> <front>
<title>SSL 3.0 Protocol Vulnerability and POODLE Attack</title> <title>SSL 3.0 Protocol Vulnerability and POODLE Attack</title>
<author> <author>
<organization>US-CERT</organization> <organization>US-CERT</organization>
</author> </author>
<date year="2014" month="October"/> <date year="2014" month="October"/>
</front> </front>
</reference> </reference>
<reference anchor="CAB-Baseline" target="https://cabforum.org/documents/ "> <reference anchor="CAB-Baseline" target="https://cabforum.org/documents/ ">
<front> <front>
<title>Baseline Requirements for the Issuance and Management of Publ icly-Trusted Certificates Version 1.1.6</title> <title>Baseline Requirements for the Issuance and Management of Publ icly-Trusted Certificates</title>
<author> <author>
<organization>CA/Browser Forum</organization> <organization>CA/Browser Forum</organization>
</author> </author>
<date year="2013"/> <date month="April" year="2022"/>
</front> </front>
<seriesInfo name="Version" value="1.8.4"/>
</reference> </reference>
<reference anchor="Heninger2012"> <reference anchor="Heninger2012">
<front> <front>
<title>Mining Your Ps and Qs: Detection of Widespread Weak Keys in N etwork Devices</title> <title>Mining Your Ps and Qs: Detection of Widespread Weak Keys in N etwork Devices</title>
<author initials="N." surname="Heninger" fullname="Nadia Heninger"> <author initials="N." surname="Heninger" fullname="Nadia Heninger">
<organization/> <organization/>
</author> </author>
<author initials="Z." surname="Durumeric" fullname="Zakir Durumeric" > <author initials="Z." surname="Durumeric" fullname="Zakir Durumeric" >
<organization/> <organization/>
</author> </author>
<author initials="E." surname="Wustrow" fullname="Eric Wustrow"> <author initials="E." surname="Wustrow" fullname="Eric Wustrow">
<organization/> <organization/>
</author> </author>
<author initials="J. A." surname="Halderman" fullname="J. Alex Halde rman"> <author initials="J. A." surname="Halderman" fullname="J. Alex Halde rman">
<organization/> <organization/>
</author> </author>
<date year="2012"/> <date year="2012" month="August"/>
</front> </front>
<seriesInfo name="Usenix Security Symposium" value="2012"/> <refcontent>21st Usenix Security Symposium</refcontent>
</reference> </reference>
<reference anchor="Sy2018"> <reference anchor="Sy2018">
<front> <front>
<title>Tracking Users across the Web via TLS Session Resumption</tit le> <title>Tracking Users across the Web via TLS Session Resumption</tit le>
<author fullname="Erik Sy" initials="E." surname="Sy"> <author fullname="Erik Sy" initials="E." surname="Sy">
<organization>University of Hamburg</organization> <organization>University of Hamburg</organization>
</author> </author>
<author fullname="Christian Burkert" initials="C." surname="Burkert" > <author fullname="Christian Burkert" initials="C." surname="Burkert" >
<organization>University of Hamburg</organization> <organization>University of Hamburg</organization>
</author> </author>
<author fullname="Hannes Federrath" initials="H." surname="Federrath "> <author fullname="Hannes Federrath" initials="H." surname="Federrath ">
<organization>University of Hamburg</organization> <organization>University of Hamburg</organization>
</author> </author>
<author fullname="Mathias Fischer" initials="M." surname="Fischer"> <author fullname="Mathias Fischer" initials="M." surname="Fischer">
<organization>University of Hamburg</organization> <organization>University of Hamburg</organization>
</author> </author>
<date month="December" year="2018"/> <date month="December" year="2018"/>
</front> </front>
<seriesInfo name="Proceedings of the 34th Annual Computer Security App lications" value="Conference"/> <refcontent>Proceedings of the 34th Annual Computer Security Applicati ons Conference, pp. 289-299</refcontent>
<seriesInfo name="DOI" value="10.1145/3274694.3274708"/> <seriesInfo name="DOI" value="10.1145/3274694.3274708"/>
</reference> </reference>
<reference anchor="DANE-SMTP" target="https://www.rfc-editor.org/info/rf
c7672">
<front>
<title>SMTP Security via Opportunistic DNS-Based Authentication of N
amed Entities (DANE) Transport Layer Security (TLS)</title>
<author fullname="V. Dukhovni" initials="V." surname="Dukhovni">
<organization/>
</author>
<author fullname="W. Hardaker" initials="W." surname="Hardaker">
<organization/>
</author>
<date month="October" year="2015"/>
<abstract>
<t>This memo describes a downgrade-resistant protocol for SMTP tra
nsport security between Message Transfer Agents (MTAs), based on the DNS-Based A
uthentication of Named Entities (DANE) TLSA DNS record. Adoption of this protoco
l enables an incremental transition of the Internet email backbone to one using
encrypted and authenticated Transport Layer Security (TLS).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7672"/>
<seriesInfo name="DOI" value="10.17487/RFC7672"/>
</reference>
<reference anchor="PatersonRS11"> <reference anchor="PatersonRS11">
<front> <front>
<title>Tag Size Does Matter: Attacks and Proofs for the TLS Record P rotocol</title> <title>Tag Size Does Matter: Attacks and Proofs for the TLS Record P rotocol</title>
<author fullname="Kenneth G. Paterson" initials="K." surname="Paters on"> <author fullname="Kenneth G. Paterson" initials="K." surname="Paters on">
<organization/> <organization/>
</author> </author>
<author fullname="Thomas Ristenpart" initials="T." surname="Ristenpa rt"> <author fullname="Thomas Ristenpart" initials="T." surname="Ristenpa rt">
<organization/> <organization/>
</author> </author>
<author fullname="Thomas Shrimpton" initials="T." surname="Shrimpton "> <author fullname="Thomas Shrimpton" initials="T." surname="Shrimpton ">
<organization/> <organization/>
</author> </author>
<date year="2011"/> <date month="December" year="2011" />
</front> </front>
<seriesInfo name="Lecture Notes in Computer Science" value="pp. 372-38 9"/> <refcontent>Proceedings of the 17th International conference on The Th eory and Application of Cryptology and Information Security, pp. 372-389</refcon tent>
<seriesInfo name="DOI" value="10.1007/978-3-642-25385-0_20"/> <seriesInfo name="DOI" value="10.1007/978-3-642-25385-0_20"/>
</reference> </reference>
<reference anchor="DANE-SRV" target="https://www.rfc-editor.org/info/rfc
7673">
<front>
<title>Using DNS-Based Authentication of Named Entities (DANE) TLSA
Records with SRV Records</title>
<author fullname="T. Finch" initials="T." surname="Finch">
<organization/>
</author>
<author fullname="M. Miller" initials="M." surname="Miller">
<organization/>
</author>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
">
<organization/>
</author>
<date month="October" year="2015"/>
<abstract>
<t>The DNS-Based Authentication of Named Entities (DANE) specifica
tion (RFC 6698) describes how to use TLSA resource records secured by DNSSEC (RF
C 4033) to associate a server's connection endpoint with its Transport Layer Sec
urity (TLS) certificate (thus enabling administrators of domain names to specify
the keys used in that domain's TLS servers). However, application protocols th
at use SRV records (RFC 2782) to indirectly name the target server connection en
dpoints for a service domain name cannot apply the rules from RFC 6698. Therefo
re, this document provides guidelines that enable such protocols to locate and u
se TLSA records.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7673"/>
<seriesInfo name="DOI" value="10.17487/RFC7673"/>
</reference>
<reference anchor="HTTP-SEMA" target="https://www.rfc-editor.org/info/rf
c9110">
<front>
<title>HTTP Semantics</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="
Fielding">
<organization/>
</author>
<author fullname="M. Nottingham" initials="M." role="editor" surname
="Nottingham">
<organization/>
</author>
<author fullname="J. Reschke" initials="J." role="editor" surname="R
eschke">
<organization/>
</author>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document describes the overall architecture of HTTP, establishes common te
rminology, and defines aspects of the protocol that are shared by all versions.
In this definition are core protocol elements, extensibility mechanisms, and the
"http" and "https" Uniform Resource Identifier (URI) schemes. </t>
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7
232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
</abstract>
</front>
<seriesInfo name="STD" value="97"/>
<seriesInfo name="RFC" value="9110"/>
<seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>
<reference anchor="HTTP1.1" target="https://www.rfc-editor.org/info/rfc9
112">
<front>
<title>HTTP/1.1</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="
Fielding">
<organization/>
</author>
<author fullname="M. Nottingham" initials="M." role="editor" surname
="Nottingham">
<organization/>
</author>
<author fullname="J. Reschke" initials="J." role="editor" surname="R
eschke">
<organization/>
</author>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document specifies the HTTP/1.1 message syntax, message parsing, connectio
n management, and related security concerns. </t>
<t>This document obsoletes portions of RFC 7230.</t>
</abstract>
</front>
<seriesInfo name="STD" value="99"/>
<seriesInfo name="RFC" value="9112"/>
<seriesInfo name="DOI" value="10.17487/RFC9112"/>
</reference>
<reference anchor="HTTP2" target="https://www.rfc-editor.org/info/rfc911
3">
<front>
<title>HTTP/2</title>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson">
<organization/>
</author>
<author fullname="C. Benfield" initials="C." role="editor" surname="
Benfield">
<organization/>
</author>
<date month="June" year="2022"/>
<abstract>
<t>This specification describes an optimized expression of the sem
antics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2
(HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced
latency by introducing field compression and allowing multiple concurrent excha
nges on the same connection.</t>
<t>This document obsoletes RFCs 7540 and 8740.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9113"/>
<seriesInfo name="DOI" value="10.17487/RFC9113"/>
</reference>
<reference anchor="Kleinjung2010"> <reference anchor="Kleinjung2010">
<front> <front>
<title>Factorization of a 768-Bit RSA Modulus</title> <title>Factorization of a 768-Bit RSA Modulus</title>
<author fullname="Thorsten Kleinjung" initials="T." surname="Kleinju ng"> <author fullname="Thorsten Kleinjung" initials="T." surname="Kleinju ng">
<organization/> <organization/>
</author> </author>
<author fullname="Kazumaro Aoki" initials="K." surname="Aoki"> <author fullname="Kazumaro Aoki" initials="K." surname="Aoki">
<organization/> <organization/>
</author> </author>
<author fullname="Jens Franke" initials="J." surname="Franke"> <author fullname="Jens Franke" initials="J." surname="Franke">
skipping to change at line 1497 skipping to change at line 1141
<organization/> <organization/>
</author> </author>
<author fullname="Andrey Timofeev" initials="A." surname="Timofeev"> <author fullname="Andrey Timofeev" initials="A." surname="Timofeev">
<organization/> <organization/>
</author> </author>
<author fullname="Paul Zimmermann" initials="P." surname="Zimmermann "> <author fullname="Paul Zimmermann" initials="P." surname="Zimmermann ">
<organization/> <organization/>
</author> </author>
<date year="2010"/> <date year="2010"/>
</front> </front>
<seriesInfo name="Advances in Cryptology - CRYPTO 2010" value="pp. 333 -350"/> <refcontent>Advances in Cryptology - CRYPTO 2010, pp. 333-350</refcont ent>
<seriesInfo name="DOI" value="10.1007/978-3-642-14623-7_18"/> <seriesInfo name="DOI" value="10.1007/978-3-642-14623-7_18"/>
</reference> </reference>
<reference anchor="IANA_TLS" target="https://www.iana.org/assignments/tl s-parameters"> <reference anchor="IANA_TLS" target="https://www.iana.org/assignments/tl s-parameters">
<front> <front>
<title>Transport Layer Security (TLS) Parameters</title> <title>Transport Layer Security (TLS) Parameters</title>
<author> <author>
<organization abbrev="IANA">Internet Assigned Numbers Authority</o rganization> <organization abbrev="IANA">Internet Assigned Numbers Authority</o rganization>
</author> </author>
<date day="23" month="August" year="2005"/>
</front> </front>
</reference> </reference>
<reference anchor="Multiple-Encryption"> <reference anchor="Multiple-Encryption">
<front> <front>
<title>On the security of multiple encryption</title> <title>On the security of multiple encryption</title>
<author fullname="Ralph C. Merkle" initials="R." surname="Merkle"> <author fullname="Ralph C. Merkle" initials="R." surname="Merkle">
<organization>Elxsi, Int., Sunnyvale, CA</organization> <organization>Elxsi, Int., Sunnyvale, CA</organization>
</author> </author>
<author fullname="Martin E. Hellman" initials="M." surname="Hellman" > <author fullname="Martin E. Hellman" initials="M." surname="Hellman" >
<organization>Stanford Univ., Stanford, CA</organization> <organization>Stanford Univ., Stanford, CA</organization>
</author> </author>
<date month="July" year="1981"/> <date month="July" year="1981"/>
</front> </front>
<seriesInfo name="Communications of the ACM" value="vol. 24, no. 7, pp . 465-467"/> <refcontent>Communications of the ACM, Vol. 24, Issue 7, pp. 465-467</ refcontent>
<seriesInfo name="DOI" value="10.1145/358699.358718"/> <seriesInfo name="DOI" value="10.1145/358699.358718"/>
</reference> </reference>
<reference anchor="NIST.SP.800-56A">
<front> <reference anchor="NIST.SP.800-56A">
<title>Recommendation for pair-wise key-establishment schemes using <front>
discrete logarithm cryptography</title> <title>
<author fullname="Elaine Barker" initials="E." surname="Barker"> Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm
<organization/> Cryptography
</author> </title>
<author fullname="Lily Chen" initials="L." surname="Chen"> <author>
<organization/> <organization>National Institute of Standards and Technology</organization>
</author> </author>
<author fullname="Allen Roginsky" initials="A." surname="Roginsky"> <date month="April" year="2018"/>
<organization/> </front>
</author> <refcontent>Revision 3</refcontent>
<author fullname="Apostol Vassilev" initials="A." surname="Vassilev" <seriesInfo name="NIST Special Publication" value="800-56A"/>
> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Ar3"/>
<organization/> </reference>
</author>
<author fullname="Richard Davis" initials="R." surname="Davis">
<organization/>
</author>
<date month="April" year="2018"/>
</front>
<seriesInfo name="National Institute of Standards and Technology" valu
e="report"/>
<seriesInfo name="DOI" value="10.6028/nist.sp.800-56ar3"/>
</reference>
<reference anchor="Springall16"> <reference anchor="Springall16">
<front> <front>
<title>Measuring the Security Harm of TLS Crypto Shortcuts</title> <title>Measuring the Security Harm of TLS Crypto Shortcuts</title>
<author fullname="Drew Springall" initials="D." surname="Springall"> <author fullname="Drew Springall" initials="D." surname="Springall">
<organization>University of Michigan, Ann Arbor, MI, USA</organiza tion> <organization>University of Michigan, Ann Arbor, MI, USA</organiza tion>
</author> </author>
<author fullname="Zakir Durumeric" initials="Z." surname="Durumeric" > <author fullname="Zakir Durumeric" initials="Z." surname="Durumeric" >
<organization>University of Michigan, Ann Arbor, MI, USA</organiza tion> <organization>University of Michigan, Ann Arbor, MI, USA</organiza tion>
</author> </author>
<author fullname="J. Alex Halderman" initials="J." surname="Halderma n"> <author fullname="J. Alex Halderman" initials="J." surname="Halderma n">
<organization>University of Michigan, Ann Arbor, MI, USA</organiza tion> <organization>University of Michigan, Ann Arbor, MI, USA</organiza tion>
</author> </author>
<date month="November" year="2016"/> <date month="November" year="2016"/>
</front> </front>
<seriesInfo name="Proceedings of the 2016 Internet Measurement" value= "Conference"/> <refcontent>Proceedings of the 2016 Internet Measurement Conference, p p. 33-47</refcontent>
<seriesInfo name="DOI" value="10.1145/2987443.2987480"/> <seriesInfo name="DOI" value="10.1145/2987443.2987480"/>
</reference> </reference>
<reference anchor="DEP-SSLv3" target="https://www.rfc-editor.org/info/rf
c7568"> <reference anchor="Boeck2016" target="https://eprint.iacr.org/2016/475.pdf">
<front>
<title>Deprecating Secure Sockets Layer Version 3.0</title>
<author fullname="R. Barnes" initials="R." surname="Barnes">
<organization/>
</author>
<author fullname="M. Thomson" initials="M." surname="Thomson">
<organization/>
</author>
<author fullname="A. Pironti" initials="A." surname="Pironti">
<organization/>
</author>
<author fullname="A. Langley" initials="A." surname="Langley">
<organization/>
</author>
<date month="June" year="2015"/>
<abstract>
<t>The Secure Sockets Layer version 3.0 (SSLv3), as specified in R
FC 6101, is not sufficiently secure. This document requires that SSLv3 not be u
sed. The replacement versions, in particular, Transport Layer Security (TLS) 1.
2 (RFC 5246), are considerably more secure and capable protocols.</t>
<t>This document updates the backward compatibility section of RFC
5246 and its predecessors to prohibit fallback to SSLv3.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7568"/>
<seriesInfo name="DOI" value="10.17487/RFC7568"/>
</reference>
<reference anchor="Boeck2016" target="https://eprint.iacr.org/2016/475.p
df">
<front> <front>
<title>Nonce-Disrespecting Adversaries: Practical Forgery Attacks on GCM in TLS</title> <title>Nonce-Disrespecting Adversaries: Practical Forgery Attacks on GCM in TLS</title>
<author initials="H." surname="Böck" fullname="Hanno Böck"> <author initials="H." surname="Böck" fullname="Hanno Böck">
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Zauner" fullname="Aaron Zauner"> <author initials="A." surname="Zauner" fullname="Aaron Zauner">
<organization/> <organization/>
</author> </author>
<author initials="S." surname="Devlin" fullname="Sean Devlin"> <author initials="S." surname="Devlin" fullname="Sean Devlin">
<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="P." surname="Jovanovic" fullname="Philipp Jovanovi c"> <author initials="P." surname="Jovanovic" fullname="Philipp Jovanovi c">
<organization/> <organization/>
</author> </author>
<date year="2016" month="May"/> <date year="2016" month="May"/>
</front> </front>
</reference> </reference>
<reference anchor="Joux2006" target="https://csrc.nist.gov/csrc/media/pr
ojects/block-cipher-techniques/documents/bcm/comments/800-38-series-drafts/gcm/j <reference anchor="Joux2006" target="https://csrc.nist.gov/csrc/media/pro
oux_comments.pdf"> jects/block-cipher-techniques/documents/bcm/comments/800-38-series-drafts/gcm/jo
ux_comments.pdf">
<front> <front>
<title>Authentication Failures in NIST version of GCM</title> <title>Authentication Failures in NIST version of GCM</title>
<author initials="A." surname="Joux" fullname="Antoine Joux"> <author initials="A." surname="Joux" fullname="Antoine Joux">
<organization/> <organization/>
</author> </author>
<date year="2006"/> <date year="2006"/>
</front> </front>
</reference> </reference>
<reference anchor="CVE" target="https://cve.mitre.org"> <reference anchor="CVE" target="https://cve.mitre.org">
<front> <front>
<title>Common Vulnerabilities and Exposures</title> <title>CVE Program</title>
<author> <author>
<organization>MITRE</organization> <organization>Common Vulnerabilities and Exposures</organization>
</author> </author>
<date/> <date/>
</front> </front>
<refcontent>MITRE</refcontent>
</reference> </reference>
<reference anchor="ALPACA" target="https://www.usenix.org/conference/use nixsecurity21/presentation/brinkmann"> <reference anchor="ALPACA" target="https://www.usenix.org/conference/use nixsecurity21/presentation/brinkmann">
<front> <front>
<title>ALPACA: Application Layer Protocol Confusion - Analyzing and Mitigating Cracks in TLS Authentication</title> <title>ALPACA: Application Layer Protocol Confusion - Analyzing and Mitigating Cracks in TLS Authentication</title>
<author initials="M." surname="Brinkmann" fullname="Marcus Brinkmann "> <author initials="M." surname="Brinkmann" fullname="Marcus Brinkmann ">
<organization/> <organization/>
</author> </author>
<author initials="C." surname="Dresen" fullname="Christian Dresen"> <author initials="C." surname="Dresen" fullname="Christian Dresen">
<organization/> <organization/>
</author> </author>
<author initials="R." surname="Merget" fullname="Robert Merget"> <author initials="R." surname="Merget" fullname="Robert Merget">
skipping to change at line 1653 skipping to change at line 1272
</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="J." surname="Schwenk" fullname="Jörg Schwenk"> <author initials="J." surname="Schwenk" fullname="Jörg Schwenk">
<organization/> <organization/>
</author> </author>
<author initials="S." surname="Schinzel" fullname="Sebastian Schinze l"> <author initials="S." surname="Schinzel" fullname="Sebastian Schinze l">
<organization/> <organization/>
</author> </author>
<date year="2021"/> <date month="August" year="2021"/>
</front> </front>
<seriesInfo name="30th USENIX Security Symposium (USENIX Security 21)" value=""/> <refcontent>30th USENIX Security Symposium (USENIX Security 21)</refco ntent>
</reference> </reference>
<reference anchor="DROWN" target="https://www.usenix.org/conference/usen ixsecurity16/technical-sessions/presentation/aviram"> <reference anchor="DROWN" target="https://www.usenix.org/conference/usen ixsecurity16/technical-sessions/presentation/aviram">
<front> <front>
<title>DROWN: Breaking TLS using SSLv2</title> <title>DROWN: Breaking TLS using SSLv2</title>
<author initials="N." surname="Aviram" fullname="Nimrod Aviram"> <author initials="N." surname="Aviram" fullname="Nimrod Aviram">
<organization/> <organization/>
</author> </author>
<author initials="S." surname="Schinzel" fullname="Sebastian Schinze l"> <author initials="S." surname="Schinzel" fullname="Sebastian Schinze l">
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Somorovsky" fullname="Juraj Somorovsk y"> <author initials="J." surname="Somorovsky" fullname="Juraj Somorovsk y">
skipping to change at line 1705 skipping to change at line 1325
</author> </author>
<author initials="S." surname="Engels" fullname="Susanne Engels"> <author initials="S." surname="Engels" fullname="Susanne Engels">
<organization/> <organization/>
</author> </author>
<author initials="C." surname="Paar" fullname="Christof Paar"> <author initials="C." surname="Paar" fullname="Christof Paar">
<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 year="2016"/> <date month="August" year="2016"/>
</front> </front>
<seriesInfo name="25th USENIX Security Symposium (USENIX Security 16)" value=""/> <refcontent>25th USENIX Security Symposium (USENIX Security 16)</refco ntent>
</reference> </reference>
<reference anchor="RACCOON" target="https://www.usenix.org/conference/us enixsecurity21/presentation/merget"> <reference anchor="RACCOON" target="https://www.usenix.org/conference/us enixsecurity21/presentation/merget">
<front> <front>
<title>Raccoon Attack: Finding and Exploiting Most-Significant-Bit-O racles in TLS-DH(E)</title> <title>Raccoon Attack: Finding and Exploiting Most-Significant-Bit-O racles in TLS-DH(E)</title>
<author initials="R." surname="Merget" fullname="Robert Merget"> <author initials="R." surname="Merget" fullname="Robert Merget">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Brinkmann" fullname="Marcus Brinkmann "> <author initials="M." surname="Brinkmann" fullname="Marcus Brinkmann ">
<organization/> <organization/>
</author> </author>
<author initials="N." surname="Aviram" fullname="Nimrod Aviram"> <author initials="N." surname="Aviram" fullname="Nimrod Aviram">
skipping to change at line 1732 skipping to change at line 1353
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Mittmann" fullname="Johannes Mittmann "> <author initials="J." surname="Mittmann" fullname="Johannes Mittmann ">
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Schwenk" fullname="Jörg Schwenk"> <author initials="J." surname="Schwenk" fullname="Jörg Schwenk">
<organization/> <organization/>
</author> </author>
<date year="2021"/> <date year="2021"/>
</front> </front>
<seriesInfo name="30th USENIX Security Symposium (USENIX Security 21)" value=""/> <refcontent>30th USENIX Security Symposium (USENIX Security 21)</refco ntent>
</reference> </reference>
<reference anchor="Antipa2003">
<reference anchor="Antipa2003" target="https://doi.org/10.1007/3-540-362
88-6_16">
<front> <front>
<title>Validation of Elliptic Curve Public Keys</title> <title>Validation of Elliptic Curve Public Keys</title>
<author initials="A." surname="Antipa" fullname="Adrian Antipa"> <author initials="A." surname="Antipa" fullname="Adrian Antipa">
<organization/> <organization/>
</author> </author>
<author initials="D. R. L." surname="Brown" fullname="Daniel R. L. B rown"> <author initials="D. R. L." surname="Brown" fullname="Daniel R. L. B rown">
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Menezes" fullname="Alfred Menezes"> <author initials="A." surname="Menezes" fullname="Alfred Menezes">
<organization/> <organization/>
</author> </author>
<author initials="R." surname="Struik" fullname="Rene Struik"> <author initials="R." surname="Struik" fullname="Rene Struik">
<organization/> <organization/>
</author> </author>
<author initials="S. A." surname="Vanstone" fullname="Scott A. Vanst one"> <author initials="S." surname="Vanstone" fullname="Scott Vanstone">
<organization/> <organization/>
</author> </author>
<date year="2003"/> <date month="December" year="2003"/>
</front> </front>
<seriesInfo name="Public Key Cryptography - PKC 2003" value=""/> <refcontent>Public Key Cryptography - PKC 2003</refcontent>
</reference> </reference>
<reference anchor="Jager2015"> <reference anchor="Jager2015">
<front> <front>
<title>Practical Invalid Curve Attacks on TLS-ECDH</title> <title>Practical Invalid Curve Attacks on TLS-ECDH</title>
<author fullname="Tibor Jager" initials="T." surname="Jager"> <author fullname="Tibor Jager" initials="T." surname="Jager">
<organization/> <organization/>
</author> </author>
<author fullname="Jörg Schwenk" initials="J." surname="Schwenk"> <author fullname="Jörg Schwenk" initials="J." surname="Schwenk">
<organization/> <organization/>
</author> </author>
<author fullname="Juraj Somorovsky" initials="J." surname="Somorovsk y"> <author fullname="Juraj Somorovsky" initials="J." surname="Somorovsk y">
<organization/> <organization/>
</author> </author>
<date year="2015"/> <date year="2015"/>
</front> </front>
<seriesInfo name="Computer Security -- ESORICS 2015" value="pp. 407-42 5"/> <refcontent>Computer Security -- ESORICS 2015, pp. 407-425</refcontent >
<seriesInfo name="DOI" value="10.1007/978-3-319-24174-6_21"/> <seriesInfo name="DOI" value="10.1007/978-3-319-24174-6_21"/>
</reference> </reference>
<reference anchor="SAFECURVES" target="https://safecurves.cr.yp.to"> <reference anchor="SAFECURVES" target="https://safecurves.cr.yp.to">
<front> <front>
<title>SafeCurves: Choosing Safe Curves for Elliptic-Curve Cryptogra phy</title> <title>SafeCurves: choosing safe curves for elliptic-curve cryptogra phy</title>
<author initials="D. J." surname="Bernstein" fullname="Daniel J. Ber nstein"> <author initials="D. J." surname="Bernstein" fullname="Daniel J. Ber nstein">
<organization/> <organization/>
</author> </author>
<author initials="T." surname="Lange" fullname="Tanja Lange"> <author initials="T." surname="Lange" fullname="Tanja Lange">
<organization/> <organization/>
</author> </author>
<date year="2014" month="December"/> <date year="2014" month="December"/>
</front> </front>
</reference> </reference>
<reference anchor="Poddebniak2017" target="https://eprint.iacr.org/2017/
1014.pdf"> <reference anchor="Poddebniak2017" target="https://eprint.iacr.org/2017/1
014.pdf">
<front> <front>
<title>Attacking Deterministic Signature Schemes using Fault Attacks </title> <title>Attacking Deterministic Signature Schemes using Fault Attacks </title>
<author initials="D." surname="Poddebniak" fullname="Damian Poddebni ak"> <author initials="D." surname="Poddebniak" fullname="Damian Poddebni ak">
<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="S." surname="Schinzel" fullname="Sebastian Schinze l"> <author initials="S." surname="Schinzel" fullname="Sebastian Schinze l">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Lochter" fullname="Manfred Lochter"> <author initials="M." surname="Lochter" fullname="Manfred Lochter">
<organization/> <organization/>
</author> </author>
<author initials="P." surname="Rösler" fullname="Paul Rösler"> <author initials="P." surname="Rösler" fullname="Paul Rösler">
<organization/> <organization/>
</author> </author>
<date year="2017"/> <date month="April" year="2018"/>
</front> </front>
<refcontent>Conference: 2018 IEEE European Symposium on Security and Pr
ivacy</refcontent>
<seriesInfo name="DOI" value="10.1109/EuroSP.2018.00031"/>
</reference> </reference>
<reference anchor="Kim2014" target="https://users.ece.cmu.edu/~yoonguk/p apers/kim-isca14.pdf"> <reference anchor="Kim2014" target="https://users.ece.cmu.edu/~yoonguk/p apers/kim-isca14.pdf">
<front> <front>
<title>Flipping Bits in Memory Without Accessing Them: An Experiment al Study of DRAM Disturbance Errors</title> <title>Flipping Bits in Memory Without Accessing Them: An Experiment al Study of DRAM Disturbance Errors</title>
<author initials="Y." surname="Kim" fullname="Yoongu Kim"> <author initials="Y." surname="Kim" fullname="Yoongu Kim">
<organization/> <organization/>
</author> </author>
<author initials="R." surname="Daly" fullname="Ross Daly"> <author initials="R." surname="Daly" fullname="Ross Daly">
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Kim" fullname="Jeremie Kim"> <author initials="J." surname="Kim" fullname="Jeremie Kim">
skipping to change at line 1836 skipping to change at line 1464
</author> </author>
<author initials="C." surname="Wilkerson" fullname="Chris Wilkerson" > <author initials="C." surname="Wilkerson" fullname="Chris Wilkerson" >
<organization/> <organization/>
</author> </author>
<author initials="K." surname="Lai" fullname="Konrad Lai"> <author initials="K." surname="Lai" fullname="Konrad Lai">
<organization/> <organization/>
</author> </author>
<author initials="O." surname="Mutlu" fullname="Onur Mutlu"> <author initials="O." surname="Mutlu" fullname="Onur Mutlu">
<organization/> <organization/>
</author> </author>
<date year="2014"/> <date month="July" year="2014"/>
</front>
</reference>
<reference anchor="RFC9051" target="https://www.rfc-editor.org/info/rfc9
051">
<front>
<title>Internet Message Access Protocol (IMAP) - Version 4rev2</titl
e>
<author fullname="A. Melnikov" initials="A." role="editor" surname="
Melnikov">
<organization/>
</author>
<author fullname="B. Leiba" initials="B." role="editor" surname="Lei
ba">
<organization/>
</author>
<date month="August" year="2021"/>
<abstract>
<t>The Internet Message Access Protocol Version 4rev2 (IMAP4rev2)
allows a client to access and manipulate electronic mail messages on a server.
IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way th
at is functionally equivalent to local folders. IMAP4rev2 also provides the cap
ability for an offline client to resynchronize with the server. </t>
<t>IMAP4rev2 includes operations for creating, deleting, and renam
ing mailboxes; checking for new messages; removing messages permanently; setting
and clearing flags; parsing per RFCs 5322, 2045, and 2231; searching; and selec
tive fetching of message attributes, texts, and portions thereof. Messages in I
MAP4rev2 are accessed by the use of numbers. These numbers are either message se
quence numbers or unique identifiers. </t>
<t>IMAP4rev2 does not specify a means of posting mail; this functi
on is handled by a mail submission protocol such as the one specified in RFC 640
9.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="9051"/> <seriesInfo name="DOI" value="10.1109/ISCA.2014.6853210"/>
<seriesInfo name="DOI" value="10.17487/RFC9051"/> </reference>
</reference>
<referencegroup anchor="STD53" target="https://www.rfc-editor.org/info/s td53"> <referencegroup anchor="STD53" target="https://www.rfc-editor.org/info/s td53">
<reference anchor="RFC1939" target="https://www.rfc-editor.org/info/rf c1939"> <reference anchor="RFC1939" target="https://www.rfc-editor.org/info/rf c1939">
<front> <front>
<title>Post Office Protocol - Version 3</title> <title>Post Office Protocol - Version 3</title>
<author fullname="J. Myers" initials="J" surname="Myers"/> <author fullname="J. Myers" initials="J" surname="Myers"/>
<author fullname="M. Rose" initials="M" surname="Rose"/> <author fullname="M. Rose" initials="M" surname="Rose"/>
<date month="May" year="1996"/> <date month="May" year="1996"/>
<abstract>
<t>The Post Office Protocol - Version 3 (POP3) is intended to pe
rmit a workstation to dynamically access a maildrop on a server host in a useful
fashion. [STANDARDS-TRACK]</t>
</abstract>
</front> </front>
<seriesInfo name="STD" value="53"/> <seriesInfo name="STD" value="53"/>
<seriesInfo name="RFC" value="1939"/> <seriesInfo name="RFC" value="1939"/>
<seriesInfo name="DOI" value="10.17487/RFC1939"/> <seriesInfo name="DOI" value="10.17487/RFC1939"/>
</reference> </reference>
</referencegroup> </referencegroup>
<reference anchor="RFC3261" target="https://www.rfc-editor.org/info/rfc3
261">
<front>
<title>SIP: Session Initiation Protocol</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization/>
</author>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne
">
<organization/>
</author>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization/>
</author>
<author fullname="A. Johnston" initials="A." surname="Johnston">
<organization/>
</author>
<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization/>
</author>
<author fullname="R. Sparks" initials="R." surname="Sparks">
<organization/>
</author>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization/>
</author>
<author fullname="E. Schooler" initials="E." surname="Schooler">
<organization/>
</author>
<date month="June" year="2002"/>
<abstract>
<t>This document describes Session Initiation Protocol (SIP), an a
pplication-layer control (signaling) protocol for creating, modifying, and termi
nating sessions with one or more participants. These sessions include Internet
telephone calls, multimedia distribution, and multimedia conferences. [STANDARD
S-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3261"/>
<seriesInfo name="DOI" value="10.17487/RFC3261"/>
</reference>
<reference anchor="RFC5321" target="https://www.rfc-editor.org/info/rfc5
321">
<front>
<title>Simple Mail Transfer Protocol</title>
<author fullname="J. Klensin" initials="J." surname="Klensin">
<organization/>
</author>
<date month="October" year="2008"/>
<abstract>
<t>This document is a specification of the basic protocol for Inte
rnet electronic mail transport. It consolidates, updates, and clarifies several
previous documents, making all or parts of most of them obsolete. It covers th
e SMTP extension mechanisms and best practices for the contemporary Internet, bu
t does not provide details about particular extensions. Although SMTP was desig
ned as a mail transport and delivery protocol, this specification also contains
information that is important to its use as a "mail submission" protocol for "sp
lit-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-T
RACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5321"/>
<seriesInfo name="DOI" value="10.17487/RFC5321"/>
</reference>
<reference anchor="RFC6120" target="https://www.rfc-editor.org/info/rfc6
120">
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</titl
e>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
">
<organization/>
</author>
<date month="March" year="2011"/>
<abstract>
<t>The Extensible Messaging and Presence Protocol (XMPP) is an app
lication profile of the Extensible Markup Language (XML) that enables the near-r
eal-time exchange of structured yet extensible data between any two or more netw
ork entities. This document defines XMPP's core protocol methods: setup and tea
rdown of XML streams, channel encryption, authentication, error handling, and co
mmunication primitives for messaging, network availability ("presence"), and req
uest-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK
]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6120"/>
<seriesInfo name="DOI" value="10.17487/RFC6120"/>
</reference>
<reference anchor="RFC9000" target="https://www.rfc-editor.org/info/rfc9
000">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I
yengar">
<organization/>
</author>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson">
<organization/>
</author>
<date month="May" year="2021"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol.
QUIC provides applications with flow-controlled streams for structured communic
ation, low-latency connection establishment, and network path migration. QUIC in
cludes security measures that ensure confidentiality, integrity, and availabilit
y in a range of deployment circumstances. Accompanying documents describe the i
ntegration of TLS for key negotiation, loss detection, and an exemplary congesti
on control algorithm.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>
<reference anchor="RFC3602" target="https://www.rfc-editor.org/info/rfc3
602">
<front>
<title>The AES-CBC Cipher Algorithm and Its Use with IPsec</title>
<author fullname="S. Frankel" initials="S." surname="Frankel">
<organization/>
</author>
<author fullname="R. Glenn" initials="R." surname="Glenn">
<organization/>
</author>
<author fullname="S. Kelly" initials="S." surname="Kelly">
<organization/>
</author>
<date month="September" year="2003"/>
<abstract>
<t>This document describes the use of the Advanced Encryption Stan
dard (AES) Cipher Algorithm in Cipher Block Chaining (CBC) Mode, with an explici
t Initialization Vector (IV), as a confidentiality mechanism within the context
of the IPsec Encapsulating Security Payload (ESP).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3602"/>
<seriesInfo name="DOI" value="10.17487/RFC3602"/>
</reference>
<reference anchor="RFC7457" target="https://www.rfc-editor.org/info/rfc7
457">
<front>
<title>Summarizing Known Attacks on Transport Layer Security (TLS) a
nd Datagram TLS (DTLS)</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer">
<organization/>
</author>
<author fullname="R. Holz" initials="R." surname="Holz">
<organization/>
</author>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
">
<organization/>
</author>
<date month="February" year="2015"/>
<abstract>
<t>Over the last few years, there have been several serious attack
s on Transport Layer Security (TLS), including attacks on its most commonly used
ciphers and modes of operation. This document summarizes these attacks, with t
he goal of motivating generic and protocol-specific recommendations on the usage
of TLS and Datagram TLS (DTLS).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7457"/>
<seriesInfo name="DOI" value="10.17487/RFC7457"/>
</reference>
<reference anchor="RFC7525" target="https://www.rfc-editor.org/info/rfc7
525">
<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">
<organization/>
</author>
<author fullname="R. Holz" initials="R." surname="Holz">
<organization/>
</author>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
">
<organization/>
</author>
<date month="May" year="2015"/>
<abstract>
<t>Transport Layer Security (TLS) and Datagram Transport Layer Sec
urity (DTLS) are widely used to protect data exchanged over application protocol
s such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, severa
l serious attacks on TLS have emerged, including attacks on its most commonly us
ed cipher suites and their modes of operation. This document provides recommend
ations for improving the security of deployed services that use TLS and DTLS. Th
e recommendations are applicable to the majority of use cases.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="195"/>
<seriesInfo name="RFC" value="7525"/>
<seriesInfo name="DOI" value="10.17487/RFC7525"/>
</reference>
<reference anchor="RFC4949" target="https://www.rfc-editor.org/info/rfc4
949">
<front>
<title>Internet Security Glossary, Version 2</title>
<author fullname="R. Shirey" initials="R." surname="Shirey">
<organization/>
</author>
<date month="August" year="2007"/>
<abstract>
<t>This Glossary provides definitions, abbreviations, and explanat
ions of terminology for information system security. The 334 pages of entries of
fer recommendations to improve the comprehensibility of written material that is
generated in the Internet Standards Process (RFC 2026). The recommendations fol
low the principles that such writing should (a) use the same term or definition
whenever the same concept is mentioned; (b) use terms in their plainest, diction
ary sense; (c) use terms that are already well-established in open publications;
and (d) avoid terms that either favor a particular vendor or favor a particular
technology or mechanism over other, competing techniques that already exist or
could be developed. This memo provides information for the Internet community.<
/t>
</abstract>
</front>
<seriesInfo name="FYI" value="36"/>
<seriesInfo name="RFC" value="4949"/>
<seriesInfo name="DOI" value="10.17487/RFC4949"/>
</reference>
<reference anchor="RFC6101" target="https://www.rfc-editor.org/info/rfc6
101">
<front>
<title>The Secure Sockets Layer (SSL) Protocol Version 3.0</title>
<author fullname="A. Freier" initials="A." surname="Freier">
<organization/>
</author>
<author fullname="P. Karlton" initials="P." surname="Karlton">
<organization/>
</author>
<author fullname="P. Kocher" initials="P." surname="Kocher">
<organization/>
</author>
<date month="August" year="2011"/>
<abstract>
<t>This document is published as a historical record of the SSL 3.
0 protocol. The original Abstract follows.</t>
<t>This document specifies version 3.0 of the Secure Sockets Layer
(SSL 3.0) protocol, a security protocol that provides communications privacy ov
er the Internet. The protocol allows client/server applications to communicate
in a way that is designed to prevent eavesdropping, tampering, or message forger
y. This document defines a Historic Document for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6101"/>
<seriesInfo name="DOI" value="10.17487/RFC6101"/>
</reference>
<reference anchor="RFC2246" target="https://www.rfc-editor.org/info/rfc2
246">
<front>
<title>The TLS Protocol Version 1.0</title>
<author fullname="T. Dierks" initials="T." surname="Dierks">
<organization/>
</author>
<author fullname="C. Allen" initials="C." surname="Allen">
<organization/>
</author>
<date month="January" year="1999"/>
<abstract>
<t>This document specifies Version 1.0 of the Transport Layer Secu
rity (TLS) protocol. The TLS protocol provides communications privacy over the I
nternet. The protocol allows client/server applications to communicate in a way
that is designed to prevent eavesdropping, tampering, or message forgery.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2246"/>
<seriesInfo name="DOI" value="10.17487/RFC2246"/>
</reference>
<reference anchor="RFC4346" target="https://www.rfc-editor.org/info/rfc4
346">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.1</titl
e>
<author fullname="T. Dierks" initials="T." surname="Dierks">
<organization/>
</author>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization/>
</author>
<date month="April" year="2006"/>
<abstract>
<t>This document specifies Version 1.1 of the Transport Layer Secu
rity (TLS) protocol. The TLS protocol provides communications security over the
Internet. The protocol allows client/server applications to communicate in a w
ay that is designed to prevent eavesdropping, tampering, or message forgery.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4346"/>
<seriesInfo name="DOI" value="10.17487/RFC4346"/>
</reference>
<reference anchor="RFC4347" target="https://www.rfc-editor.org/info/rfc4
347">
<front>
<title>Datagram Transport Layer Security</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization/>
</author>
<author fullname="N. Modadugu" initials="N." surname="Modadugu">
<organization/>
</author>
<date month="April" year="2006"/>
<abstract>
<t>This document specifies Version 1.0 of the Datagram Transport L
ayer Security (DTLS) protocol. The DTLS protocol provides communications privac
y for datagram protocols. The protocol allows client/server applications to com
municate in a way that is designed to prevent eavesdropping, tampering, or messa
ge forgery. The DTLS protocol is based on the Transport Layer Security (TLS) pr
otocol and provides equivalent security guarantees. Datagram semantics of the u
nderlying transport are preserved by the DTLS protocol.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4347"/>
<seriesInfo name="DOI" value="10.17487/RFC4347"/>
</reference>
<reference anchor="RFC7507" target="https://www.rfc-editor.org/info/rfc7
507">
<front>
<title>TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventi
ng Protocol Downgrade Attacks</title>
<author fullname="B. Moeller" initials="B." surname="Moeller">
<organization/>
</author>
<author fullname="A. Langley" initials="A." surname="Langley">
<organization/>
</author>
<date month="April" year="2015"/>
<abstract>
<t>This document defines a Signaling Cipher Suite Value (SCSV) tha
t prevents protocol downgrade attacks on the Transport Layer Security (TLS) and
Datagram Transport Layer Security (DTLS) protocols. It updates RFCs 2246, 4346,
4347, 5246, and 6347. Server update considerations are included.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7507"/>
<seriesInfo name="DOI" value="10.17487/RFC7507"/>
</reference>
<reference anchor="RFC6797" target="https://www.rfc-editor.org/info/rfc6
797">
<front>
<title>HTTP Strict Transport Security (HSTS)</title>
<author fullname="J. Hodges" initials="J." surname="Hodges">
<organization/>
</author>
<author fullname="C. Jackson" initials="C." surname="Jackson">
<organization/>
</author>
<author fullname="A. Barth" initials="A." surname="Barth">
<organization/>
</author>
<date month="November" year="2012"/>
<abstract>
<t>This specification defines a mechanism enabling web sites to de
clare themselves accessible only via secure connections and/or for users to be a
ble to direct their user agent(s) to interact with given sites only over secure
connections. This overall policy is referred to as HTTP Strict Transport Securi
ty (HSTS). The policy is declared by web sites via the Strict-Transport-Securit
y HTTP response header field and/or by other means, such as user agent configura
tion, for example. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6797"/>
<seriesInfo name="DOI" value="10.17487/RFC6797"/>
</reference>
<reference anchor="RFC8461" target="https://www.rfc-editor.org/info/rfc8
461">
<front>
<title>SMTP MTA Strict Transport Security (MTA-STS)</title>
<author fullname="D. Margolis" initials="D." surname="Margolis">
<organization/>
</author>
<author fullname="M. Risher" initials="M." surname="Risher">
<organization/>
</author>
<author fullname="B. Ramakrishnan" initials="B." surname="Ramakrishn
an">
<organization/>
</author>
<author fullname="A. Brotman" initials="A." surname="Brotman">
<organization/>
</author>
<author fullname="J. Jones" initials="J." surname="Jones">
<organization/>
</author>
<date month="September" year="2018"/>
<abstract>
<t>SMTP MTA Strict Transport Security (MTA-STS) is a mechanism ena
bling mail service providers (SPs) to declare their ability to receive Transport
Layer Security (TLS) secure SMTP connections and to specify whether sending SMT
P servers should refuse to deliver to MX hosts that do not offer TLS with a trus
ted server certificate.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8461"/>
<seriesInfo name="DOI" value="10.17487/RFC8461"/>
</reference>
<reference anchor="RFC6698" target="https://www.rfc-editor.org/info/rfc6
698">
<front>
<title>The DNS-Based Authentication of Named Entities (DANE) Transpo
rt Layer Security (TLS) Protocol: TLSA</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman">
<organization/>
</author>
<author fullname="J. Schlyter" initials="J." surname="Schlyter">
<organization/>
</author>
<date month="August" year="2012"/>
<abstract>
<t>Encrypted communication on the Internet often uses Transport La
yer Security (TLS), which depends on third parties to certify the keys used. Th
is document improves on that situation by enabling the administrators of domain
names to specify the keys used in that domain's TLS servers. This requires matc
hing improvements in TLS client software, but no change in TLS server software.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6698"/>
<seriesInfo name="DOI" value="10.17487/RFC6698"/>
</reference>
<reference anchor="RFC7712" target="https://www.rfc-editor.org/info/rfc7
712">
<front>
<title>Domain Name Associations (DNA) in the Extensible Messaging an
d Presence Protocol (XMPP)</title>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
">
<organization/>
</author>
<author fullname="M. Miller" initials="M." surname="Miller">
<organization/>
</author>
<author fullname="P. Hancke" initials="P." surname="Hancke">
<organization/>
</author>
<date month="November" year="2015"/>
<abstract>
<t>This document improves the security of the Extensible Messaging
and Presence Protocol (XMPP) in two ways. First, it specifies how to establish
a strong association between a domain name and an XML stream, using the concept
of "prooftypes". Second, it describes how to securely delegate a service domai
n name (e.g., example.com) to a target server hostname (e.g., hosting.example.ne
t); this is especially important in multi-tenanted environments where the same t
arget server hosts a large number of domains.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7712"/>
<seriesInfo name="DOI" value="10.17487/RFC7712"/>
</reference>
<reference anchor="RFC9191" target="https://www.rfc-editor.org/info/rfc9
191">
<front>
<title>Handling Large Certificates and Long Certificate Chains in TL
S-Based EAP Methods</title>
<author fullname="M. Sethi" initials="M." surname="Sethi">
<organization/>
</author>
<author fullname="J. Preuß Mattsson" initials="J." surname="Preuß Ma
ttsson">
<organization/>
</author>
<author fullname="S. Turner" initials="S." surname="Turner">
<organization/>
</author>
<date month="February" year="2022"/>
<abstract>
<t>The Extensible Authentication Protocol (EAP), defined in RFC 37
48, provides a standard mechanism for support of multiple authentication methods
. EAP-TLS and other TLS-based EAP methods are widely deployed and used for netwo
rk access authentication. Large certificates and long certificate chains combine
d with authenticators that drop an EAP session after only 40 - 50 round trips is
a major deployment problem. This document looks at this problem in detail and d
escribes the potential solutions available.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9191"/>
<seriesInfo name="DOI" value="10.17487/RFC9191"/>
</reference>
<reference anchor="RFC8879" target="https://www.rfc-editor.org/info/rfc8
879">
<front>
<title>TLS Certificate Compression</title>
<author fullname="A. Ghedini" initials="A." surname="Ghedini">
<organization/>
</author>
<author fullname="V. Vasiliev" initials="V." surname="Vasiliev">
<organization/>
</author>
<date month="December" year="2020"/>
<abstract>
<t>In TLS handshakes, certificate chains often take up the majorit
y of the bytes transmitted.</t>
<t>This document describes how certificate chains can be compresse
d to reduce the amount of data transmitted and avoid some round trips.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8879"/>
<seriesInfo name="DOI" value="10.17487/RFC8879"/>
</reference>
<reference anchor="RFC7924" target="https://www.rfc-editor.org/info/rfc7
924">
<front>
<title>Transport Layer Security (TLS) Cached Information Extension</
title>
<author fullname="S. Santesson" initials="S." surname="Santesson">
<organization/>
</author>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig">
<organization/>
</author>
<date month="July" year="2016"/>
<abstract>
<t>Transport Layer Security (TLS) handshakes often include fairly
static information, such as the server certificate and a list of trusted certifi
cation authorities (CAs). This information can be of considerable size, particu
larly if the server certificate is bundled with a complete certificate chain (i.
e., the certificates of intermediate CAs up to the root CA).</t>
<t>This document defines an extension that allows a TLS client to
inform a server of cached information, thereby enabling the server to omit alrea
dy available information.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7924"/>
<seriesInfo name="DOI" value="10.17487/RFC7924"/>
</reference>
<reference anchor="RFC5077" target="https://www.rfc-editor.org/info/rfc5
077">
<front>
<title>Transport Layer Security (TLS) Session Resumption without Ser
ver-Side State</title>
<author fullname="J. Salowey" initials="J." surname="Salowey">
<organization/>
</author>
<author fullname="H. Zhou" initials="H." surname="Zhou">
<organization/>
</author>
<author fullname="P. Eronen" initials="P." surname="Eronen">
<organization/>
</author>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig">
<organization/>
</author>
<date month="January" year="2008"/>
<abstract>
<t>This document describes a mechanism that enables the Transport
Layer Security (TLS) server to resume sessions and avoid keeping per-client sess
ion state. The TLS server encapsulates the session state into a ticket and forw
ards it to the client. The client can subsequently resume a session using the o
btained ticket. This document obsoletes RFC 4507. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5077"/>
<seriesInfo name="DOI" value="10.17487/RFC5077"/>
</reference>
<reference anchor="I-D.ietf-tls-esni" target="https://www.ietf.org/archi
ve/id/draft-ietf-tls-esni-14.txt">
<front>
<title>TLS Encrypted Client Hello</title>
<author fullname="Eric Rescorla">
<organization>RTFM, Inc.</organization>
</author>
<author fullname="Kazuho Oku">
<organization>Fastly</organization>
</author>
<author fullname="Nick Sullivan">
<organization>Cloudflare</organization>
</author>
<author fullname="Christopher A. Wood">
<organization>Cloudflare</organization>
</author>
<date day="13" month="February" year="2022"/>
<abstract>
<t> This document describes a mechanism in Transport Layer Secur
ity (TLS)
for encrypting a ClientHello message under a server public key.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at <!--draft-ietf-tls-esni-15; I-D exists as of 11/15/22-->
https://github.com/tlswg/draft-ietf-tls-esni <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.draft-i
(https://github.com/tlswg/draft-ietf-tls-esni). etf-tls-esni.xml"/>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-14"/>
</reference>
<reference anchor="RFC8470" target="https://www.rfc-editor.org/info/rfc8
470">
<front>
<title>Using Early Data in HTTP</title>
<author fullname="M. Thomson" initials="M." surname="Thomson">
<organization/>
</author>
<author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/>
</author>
<author fullname="W. Tarreau" initials="W." surname="Tarreau">
<organization/>
</author>
<date month="September" year="2018"/>
<abstract>
<t>Using TLS early data creates an exposure to the possibility of
a replay attack. This document defines mechanisms that allow clients to communi
cate with servers about HTTP requests that are sent in early data. Techniques a
re described that use these mechanisms to mitigate the risk of replay.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8470"/>
<seriesInfo name="DOI" value="10.17487/RFC8470"/>
</reference>
<reference anchor="RFC9001" target="https://www.rfc-editor.org/info/rfc9
001">
<front>
<title>Using TLS to Secure QUIC</title>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson">
<organization/>
</author>
<author fullname="S. Turner" initials="S." role="editor" surname="Tu
rner">
<organization/>
</author>
<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="RFC7919" target="https://www.rfc-editor.org/info/rfc7
919">
<front>
<title>Negotiated Finite Field Diffie-Hellman Ephemeral Parameters f
or Transport Layer Security (TLS)</title>
<author fullname="D. Gillmor" initials="D." surname="Gillmor">
<organization/>
</author>
<date month="August" year="2016"/>
<abstract>
<t>Traditional finite-field-based Diffie-Hellman (DH) key exchange
during the Transport Layer Security (TLS) handshake suffers from a number of se
curity, interoperability, and efficiency shortcomings. These shortcomings arise
from lack of clarity about which DH group parameters TLS servers should offer an
d clients should accept. This document offers a solution to these shortcomings
for compatible peers by using a section of the TLS "Supported Groups Registry" (
renamed from "EC Named Curve Registry" by this document) to establish common fin
ite field DH parameters with known structure and a mechanism for peers to negoti
ate support for these groups.</t>
<t>This document updates TLS versions 1.0 (RFC 2246), 1.1 (RFC 434
6), and 1.2 (RFC 5246), as well as the TLS Elliptic Curve Cryptography (ECC) ext
ensions (RFC 4492).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7919"/>
<seriesInfo name="DOI" value="10.17487/RFC7919"/>
</reference>
<reference anchor="RFC5116" target="https://www.rfc-editor.org/info/rfc5
116">
<front>
<title>An Interface and Algorithms for Authenticated Encryption</tit
le>
<author fullname="D. McGrew" initials="D." surname="McGrew">
<organization/>
</author>
<date month="January" year="2008"/>
<abstract>
<t>This document defines algorithms for Authenticated Encryption w
ith Associated Data (AEAD), and defines a uniform interface and a registry for s
uch algorithms. The interface and registry can be used as an application-indepe
ndent set of cryptoalgorithm suites. This approach provides advantages in effic
iency and security, and promotes the reuse of crypto implementations. [STANDARD
S-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5116"/>
<seriesInfo name="DOI" value="10.17487/RFC5116"/>
</reference>
<reference anchor="I-D.mattsson-cfrg-det-sigs-with-noise" target="https:
//www.ietf.org/archive/id/draft-mattsson-cfrg-det-sigs-with-noise-04.txt">
<front>
<title>Deterministic ECDSA and EdDSA Signatures with Additional Rand
omness</title>
<author fullname="John Preuß Mattsson">
<organization>Ericsson</organization>
</author>
<author fullname="Erik Thormarker">
<organization>Ericsson</organization>
</author>
<author fullname="Sini Ruohomaa">
<organization>Ericsson</organization>
</author>
<date day="15" month="February" year="2022"/>
<abstract>
<t> Deterministic elliptic-curve signatures such as deterministi
c ECDSA
and EdDSA have gained popularity over randomized ECDSA as their
security do not depend on a source of high-quality randomness.
Recent research has however found that implementations of these
signature algorithms may be vulnerable to certain side-channel and
fault injection attacks due to their determinism. One countermeasure
to such attacks is to re-add randomness to the otherwise
deterministic calculation of the per-message secret number. This
document updates RFC 6979 and RFC 8032 to recommend constructions
with additional randomness for deployments where side-channel attacks
and fault injection attacks are a concern. The updates are invisible
to the validator of the signature and compatible with existing ECDSA
and EdDSA validators.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-mattsson-cfrg-det-sigs-
with-noise-04"/>
</reference>
<reference anchor="I-D.irtf-cfrg-aead-limits" target="https://www.ietf.o
rg/archive/id/draft-irtf-cfrg-aead-limits-05.txt">
<front>
<title>Usage Limits on AEAD Algorithms</title>
<author fullname="Felix Günther">
<organization>ETH Zurich</organization>
</author>
<author fullname="Martin Thomson">
<organization>Mozilla</organization>
</author>
<author fullname="Christopher A. Wood">
<organization>Cloudflare</organization>
</author>
<date day="11" month="July" year="2022"/>
<abstract>
<t> An Authenticated Encryption with Associated Data (AEAD) algo
rithm
provides confidentiality and integrity. Excessive use of the same
key can give an attacker advantages in breaking these properties.
This document provides simple guidance for users of common AEAD
functions about how to limit the use of keys in order to bound the
advantage given to an attacker. It considers limits in both single-
and multi-key settings.
</t> <!--[rfced] FYI: draft-mattsson-cfrg-det-sigs-with-noise-04 was
</abstract> replaced by draft-irtf-cfrg-det-sigs-with-noise-00, so we updated
</front> the entry for [CFRG-DET-SIGS] accordingly.
<seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-aead-limits-0
5"/>
</reference>
<reference anchor="RFC7590" target="https://www.rfc-editor.org/info/rfc7
590">
<front>
<title>Use of Transport Layer Security (TLS) in the Extensible Messa
ging and Presence Protocol (XMPP)</title>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
">
<organization/>
</author>
<author fullname="T. Alkemade" initials="T." surname="Alkemade">
<organization/>
</author>
<date month="June" year="2015"/>
<abstract>
<t>This document provides recommendations for the use of Transport
Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP).
This document updates RFC 6120.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7590"/>
<seriesInfo name="DOI" value="10.17487/RFC7590"/>
</reference>
<reference anchor="RFC2026" target="https://www.rfc-editor.org/info/rfc2
026">
<front>
<title>The Internet Standards Process -- Revision 3</title>
<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization/>
</author>
<date month="October" year="1996"/>
<abstract>
<t>This memo documents the process used by the Internet community
for the standardization of protocols and procedures. It defines the stages in t
he standardization process, the requirements for moving a document between stage
s and the types of documents used during this process. This document specifies a
n Internet Best Current Practices for the Internet Community, and requests discu
ssion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="9"/>
<seriesInfo name="RFC" value="2026"/>
<seriesInfo name="DOI" value="10.17487/RFC2026"/>
</reference>
<reference anchor="RFC7228" target="https://www.rfc-editor.org/info/rfc7
228">
<front>
<title>Terminology for Constrained-Node Networks</title>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization/>
</author>
<author fullname="M. Ersue" initials="M." surname="Ersue">
<organization/>
</author>
<author fullname="A. Keranen" initials="A." surname="Keranen">
<organization/>
</author>
<date month="May" year="2014"/>
<abstract>
<t>The Internet Protocol Suite is increasingly used on small devic
es with severe constraints on power, memory, and processing resources, creating
constrained-node networks. This document provides a number of basic terms that
have been useful in the standardization work for constrained-node networks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7228"/>
<seriesInfo name="DOI" value="10.17487/RFC7228"/>
</reference>
<reference anchor="RFC7925" target="https://www.rfc-editor.org/info/rfc7
925">
<front>
<title>Transport Layer Security (TLS) / Datagram Transport Layer Sec
urity (DTLS) Profiles for the Internet of Things</title>
<author fullname="H. Tschofenig" initials="H." role="editor" surname
="Tschofenig">
<organization/>
</author>
<author fullname="T. Fossati" initials="T." surname="Fossati">
<organization/>
</author>
<date month="July" year="2016"/>
<abstract>
<t>A common design pattern in Internet of Things (IoT) deployments
is the use of a constrained device that collects data via sensors or controls a
ctuators for use in home automation, industrial control systems, smart cities, a
nd other IoT deployments.</t>
<t>This document defines a Transport Layer Security (TLS) and Data
gram Transport Layer Security (DTLS) 1.2 profile that offers communications secu
rity for this data exchange thereby preventing eavesdropping, tampering, and mes
sage forgery. The lack of communication security is a common vulnerability in I
oT products that can easily be solved by using these well-researched and widely
deployed Internet security protocols.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7925"/>
<seriesInfo name="DOI" value="10.17487/RFC7925"/>
</reference>
<reference anchor="I-D.ietf-uta-tls13-iot-profile" target="https://www.i
etf.org/archive/id/draft-ietf-uta-tls13-iot-profile-05.txt">
<front>
<title>TLS/DTLS 1.3 Profiles for the Internet of Things</title>
<author fullname="Hannes Tschofenig">
<organization>Arm Limited</organization>
</author>
<author fullname="Thomas Fossati">
<organization>Arm Limited</organization>
</author>
<date day="6" month="July" year="2022"/>
<abstract>
<t> This document is a companion to RFC 7925 and defines TLS/DTL
S 1.3
profiles for Internet of Things devices. It also updates RFC 7925
with regards to the X.509 certificate profile.
Discussion Venues Original:
[I-D.mattsson-cfrg-det-sigs-with-noise]
Mattsson, J. P., Thormarker, E., and S. Ruohomaa,
"Deterministic ECDSA and EdDSA Signatures with Additional
Randomness", Work in Progress, Internet-Draft, draft-
mattsson-cfrg-det-sigs-with-noise-04, 15 February 2022,
<https://www.ietf.org/archive/id/draft-mattsson-cfrg-det-
sigs-with-noise-04.txt>.
This note is to be removed before publishing as an RFC. Updated:
[CFRG-DET-SIGS]
Preuß Mattsson, J., Thormarker, E., and S. Ruohomaa,
"Deterministic ECDSA and EdDSA Signatures with Additional
Randomness", Work in Progress, Internet-Draft, draft-irtf-
cfrg-det-sigs-with-noise-00, 8 August 2022,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
det-sigs-with-noise-00>.
-->
<!-- draft-mattsson-cfrg-det-sigs-with-noise-04 replaced by draft-irtf-cfrg-det-
sigs-with-noise-00; I-D exists as of 11/15/22. Long way used to correctly displa
y "John Preuß Mattsson"
-->
<reference anchor="I-D.mattsson-cfrg-det-sigs-with-noise">
<front>
<title>
Deterministic ECDSA and EdDSA Signatures with Additional Randomness
</title>
<author initials="J" surname="Preuß Mattsson" fullname="John Preuß Mattsson">
</author>
<author initials="E" surname="Thormarker" fullname="Erik Thormarker">
</author>
<author initials="S" surname="Ruohomaa" fullname="Sini Ruohomaa">
</author>
<date month="August" day="8" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-det-sigs-with-noise-00"
/>
</reference>
Source for this draft and an issue tracker can be found at <!--draft-irtf-cfrg-aead-limits-05; I-D exists as of 11/15/22-->
https://github.com/thomas-fossati/draft-tls13-iot. <xi:include
href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.draft-irtf-cfrg-aead-limits.xml"/>
</t> <!--draft-ietf-uta-tls13-iot-profile-05; I-D exists as of 11/15/22-->
</abstract> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.draft-i
</front> etf-uta-tls13-iot-profile.xml"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-uta-tls13-iot-prof </references>
ile-05"/>
</reference>
<reference anchor="RFC7435" target="https://www.rfc-editor.org/info/rfc7
435">
<front>
<title>Opportunistic Security: Some Protection Most of the Time</tit
le>
<author fullname="V. Dukhovni" initials="V." surname="Dukhovni">
<organization/>
</author>
<date month="December" year="2014"/>
<abstract>
<t>This document defines the concept "Opportunistic Security" in t
he context of communications protocols. Protocol designs based on Opportunistic
Security use encryption even when authentication is not available, and use auth
entication when possible, thereby removing barriers to the widespread use of enc
ryption on the Internet.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7435"/>
<seriesInfo name="DOI" value="10.17487/RFC7435"/>
</reference>
<reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5
280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Cert
ificate Revocation List (CRL) Profile</title>
<author fullname="D. Cooper" initials="D." surname="Cooper">
<organization/>
</author>
<author fullname="S. Santesson" initials="S." surname="Santesson">
<organization/>
</author>
<author fullname="S. Farrell" initials="S." surname="Farrell">
<organization/>
</author>
<author fullname="S. Boeyen" initials="S." surname="Boeyen">
<organization/>
</author>
<author fullname="R. Housley" initials="R." surname="Housley">
<organization/>
</author>
<author fullname="W. Polk" initials="W." surname="Polk">
<organization/>
</author>
<date month="May" year="2008"/>
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certif
icate revocation list (CRL) for use in the Internet. An overview of this approa
ch and model is provided as an introduction. The X.509 v3 certificate format is
described in detail, with additional information regarding the format and seman
tics of Internet name forms. Standard certificate extensions are described and
two Internet-specific extensions are defined. A set of required certificate ext
ensions is specified. The X.509 v2 CRL format is described in detail along with
standard and Internet-specific extensions. An algorithm for X.509 certificatio
n path validation is described. An ASN.1 module and examples are provided in th
e appendices. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5280"/>
<seriesInfo name="DOI" value="10.17487/RFC5280"/>
</reference>
<reference anchor="RFC8452" target="https://www.rfc-editor.org/info/rfc8
452">
<front>
<title>AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption<
/title>
<author fullname="S. Gueron" initials="S." surname="Gueron">
<organization/>
</author>
<author fullname="A. Langley" initials="A." surname="Langley">
<organization/>
</author>
<author fullname="Y. Lindell" initials="Y." surname="Lindell">
<organization/>
</author>
<date month="April" year="2019"/>
<abstract>
<t>This memo specifies two authenticated encryption algorithms tha
t are nonce misuse resistant -- that is, they do not fail catastrophically if a
nonce is repeated.</t>
<t>This document is the product of the Crypto Forum Research Group
.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8452"/>
<seriesInfo name="DOI" value="10.17487/RFC8452"/>
</reference>
<reference anchor="RFC9162" target="https://www.rfc-editor.org/info/rfc9
162">
<front>
<title>Certificate Transparency Version 2.0</title>
<author fullname="B. Laurie" initials="B." surname="Laurie">
<organization/>
</author>
<author fullname="E. Messeri" initials="E." surname="Messeri">
<organization/>
</author>
<author fullname="R. Stradling" initials="R." surname="Stradling">
<organization/>
</author>
<date month="December" year="2021"/>
<abstract>
<t>This document describes version 2.0 of the Certificate Transpar
ency (CT) protocol for publicly logging the existence of Transport Layer Securit
y (TLS) server certificates as they are issued or observed, in a manner that all
ows anyone to audit certification authority (CA) activity and notice the issuanc
e of suspect certificates as well as to audit the certificate logs themselves. T
he intent is that eventually clients would refuse to honor certificates that do
not appear in a log, effectively forcing CAs to add all issued certificates to t
he logs.</t>
<t>This document obsoletes RFC 6962. It also specifies a new TLS
extension that is used to send various CT log artifacts.</t>
<t>Logs are network services that implement the protocol operation
s for submissions and queries that are defined in this document.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9162"/>
<seriesInfo name="DOI" value="10.17487/RFC9162"/>
</reference>
<reference anchor="RFC6960" target="https://www.rfc-editor.org/info/rfc6
960">
<front>
<title>X.509 Internet Public Key Infrastructure Online Certificate S
tatus Protocol - OCSP</title>
<author fullname="S. Santesson" initials="S." surname="Santesson">
<organization/>
</author>
<author fullname="M. Myers" initials="M." surname="Myers">
<organization/>
</author>
<author fullname="R. Ankney" initials="R." surname="Ankney">
<organization/>
</author>
<author fullname="A. Malpani" initials="A." surname="Malpani">
<organization/>
</author>
<author fullname="S. Galperin" initials="S." surname="Galperin">
<organization/>
</author>
<author fullname="C. Adams" initials="C." surname="Adams">
<organization/>
</author>
<date month="June" year="2013"/>
<abstract>
<t>This document specifies a protocol useful in determining the cu
rrent status of a digital certificate without requiring Certificate Revocation L
ists (CRLs). Additional mechanisms addressing PKIX operational requirements are
specified in separate documents. This document obsoletes RFCs 2560 and 6277. I
t also updates RFC 5912.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6960"/>
<seriesInfo name="DOI" value="10.17487/RFC6960"/>
</reference>
<reference anchor="RFC7633" target="https://www.rfc-editor.org/info/rfc7
633">
<front>
<title>X.509v3 Transport Layer Security (TLS) Feature Extension</tit
le>
<author fullname="P. Hallam-Baker" initials="P." surname="Hallam-Bak
er">
<organization/>
</author>
<date month="October" year="2015"/>
<abstract>
<t>The purpose of the TLS feature extension is to prevent downgrad
e attacks that are not otherwise prevented by the TLS protocol. In particular,
the TLS feature extension may be used to mandate support for revocation checking
features in the TLS protocol such as Online Certificate Status Protocol (OCSP)
stapling. Informing clients that an OCSP status response will always be stapled
permits an immediate failure in the case that the response is not stapled. Thi
s in turn prevents a denial-of-service attack that might otherwise be possible.<
/t>
</abstract>
</front>
<seriesInfo name="RFC" value="7633"/>
<seriesInfo name="DOI" value="10.17487/RFC7633"/>
</reference>
<reference anchor="RFC6961" target="https://www.rfc-editor.org/info/rfc6
961">
<front>
<title>The Transport Layer Security (TLS) Multiple Certificate Statu
s Request Extension</title>
<author fullname="Y. Pettersen" initials="Y." surname="Pettersen">
<organization/>
</author>
<date month="June" year="2013"/>
<abstract>
<t>This document defines the Transport Layer Security (TLS) Certif
icate Status Version 2 Extension to allow clients to specify and support several
certificate status methods. (The use of the Certificate Status extension is co
mmonly referred to as "OCSP stapling".) Also defined is a new method based on t
he Online Certificate Status Protocol (OCSP) that servers can use to provide sta
tus information about not only the server's own certificate but also the status
of intermediate certificates in the chain.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6961"/>
<seriesInfo name="DOI" value="10.17487/RFC6961"/>
</reference>
</references>
</references> </references>
<section anchor="diff-rfc"> <section anchor="diff-rfc">
<name>Differences from RFC 7525</name> <name>Differences from RFC 7525</name>
<t>This revision of the Best Current Practices contains numerous changes, and this section is focused <t>This revision of the Best Current Practices contains numerous changes, and this section is focused
on the normative changes.</t> on the normative changes.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>High level differences: <t>High-level differences:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>Described the expectations from new TLS-incorporating transport protocols and from new application protocols layered on TLS.</li> <li>Described the expectations from new TLS-incorporating transport protocols and from new application protocols layered on TLS.</li>
<li>Clarified items (e.g. renegotiation) that only apply to TLS 1.2. <li>Clarified items (e.g., renegotiation) that only apply to TLS 1.2
</li> .</li>
<li>Changed status of TLS 1.0 and 1.1 from <bcp14>SHOULD NOT</bcp14> <li>Changed the status of TLS 1.0 and 1.1 from "<bcp14>SHOULD NOT</b
to <bcp14>MUST NOT</bcp14>.</li> cp14>" to "<bcp14>MUST NOT</bcp14>".</li>
<li>Added TLS 1.3 at a <bcp14>SHOULD</bcp14> level.</li> <li>Added TLS 1.3 at a "<bcp14>SHOULD</bcp14>" level.</li>
<li>Similar changes to DTLS.</li> <li>Made similar changes to DTLS.</li>
<li>Specific guidance for multiplexed protocols.</li> <li>Included specific guidance for multiplexed protocols.</li>
<li> <li>
<bcp14>MUST</bcp14>-level implementation requirement for ALPN, and more specific <bcp14>SHOULD</bcp14>-level guidance for ALPN and SNI.</li> <bcp14>MUST</bcp14>-level implementation requirement for ALPN and more specific <bcp14>SHOULD</bcp14>-level guidance for ALPN and SNI.</li>
<li>Clarified discussion of strict TLS policies, including <bcp14>MU ST</bcp14>-level recommendations.</li> <li>Clarified discussion of strict TLS policies, including <bcp14>MU ST</bcp14>-level recommendations.</li>
<li>Limits on key usage.</li> <li>Limits on key usage.</li>
<li>New attacks since <xref target="RFC7457"/>: ALPACA, Raccoon, Log jam, "Nonce-Disrespecting Adversaries".</li> <li>New attacks since <xref target="RFC7457"/>: ALPACA, Raccoon, Log jam, and "Nonce-Disrespecting Adversaries".</li>
<li>RFC 6961 (OCSP status_request_v2) has been deprecated.</li> <li>RFC 6961 (OCSP status_request_v2) has been deprecated.</li>
<li> <li>
<bcp14>MUST</bcp14>-level requirement for server-side RSA certific ates to have 2048-bit modulus at a minimum, replacing a <bcp14>SHOULD</bcp14>.</ li> <bcp14>MUST</bcp14>-level requirement for server-side RSA certific ates to have a 2048-bit modulus at a minimum, replacing a "<bcp14>SHOULD</bcp14> ".</li>
</ul> </ul>
</li> </li>
<li> <li>
<t>Differences specific to TLS 1.2: <t>Differences specific to TLS 1.2:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<bcp14>SHOULD</bcp14>-level guidance on AES-GCM nonce generation.< /li> <bcp14>SHOULD</bcp14>-level guidance on AES-GCM nonce generation.< /li>
<li> <li>
<bcp14>SHOULD NOT</bcp14> use (static or ephemeral) finite-field D H key agreement.</li> <bcp14>SHOULD NOT</bcp14> use (static or ephemeral) finite-field D H key agreement.</li>
<li> <li>
<bcp14>SHOULD NOT</bcp14> reuse ephemeral finite-field DH keys acr oss multiple connections.</li> <bcp14>SHOULD NOT</bcp14> reuse ephemeral finite-field DH keys acr oss multiple connections.</li>
<li> <li>
<bcp14>SHOULD NOT</bcp14> use static elliptic curve DH key exchang <bcp14>SHOULD NOT</bcp14> use static Elliptic Curve DH key exchang
e.</li> e.</li>
<li>2048-bit DH now a <bcp14>MUST</bcp14>, ECDH minimal curve size i <li>2048-bit DH is now a "<bcp14>MUST</bcp14>" and ECDH minimal curv
s 224, vs. 192 previously.</li> e size is 224 (vs. 192 previously).</li>
<li>Support for <tt>extended_master_secret</tt> is now a <bcp14>MUST <li>Support for <tt>extended_master_secret</tt> is now a "<bcp14>MUS
</bcp14> (previously it was a soft recommendation, as the RFC had not been publi T</bcp14>" (previously it was a soft recommendation, as the RFC had not been pub
shed at the time). Also removed other, more complicated, related mitigations.</l lished at the time). Also removed other, more complicated, related mitigations.<
i> /li>
<li> <li>
<bcp14>MUST</bcp14>-level restriction on session ticket validity, replacing a <bcp14>SHOULD</bcp14>.</li> <bcp14>MUST</bcp14>-level restriction on session ticket validity, replacing a "<bcp14>SHOULD</bcp14>".</li>
<li> <li>
<bcp14>SHOULD</bcp14>-level restriction on the TLS session duratio n, depending on the rotation period of an <xref target="RFC5077"/> ticket key.</ li> <bcp14>SHOULD</bcp14>-level restriction on the TLS session duratio n, depending on the rotation period of an <xref target="RFC5077"/> ticket key.</ li>
<li>Drop TLS_DHE_RSA_WITH_AES from the recommended ciphers</li> <li>Dropped TLS_DHE_RSA_WITH_AES from the recommended ciphers.</li>
<li>Add TLS_ECDHE_ECDSA_WITH_AES to the recommended ciphers</li> <li>Added TLS_ECDHE_ECDSA_WITH_AES to the recommended ciphers.</li>
<li> <li>
<bcp14>SHOULD NOT</bcp14> use the old MTI cipher suite, TLS_RSA_WI TH_AES_128_CBC_SHA.</li> <bcp14>SHOULD NOT</bcp14> use the old MTI cipher suite, TLS_RSA_WI TH_AES_128_CBC_SHA.</li>
<li>Recommend curve X25519 alongside NIST P-256</li> <li>Recommended curve X25519 alongside NIST P-256.</li>
</ul> </ul>
</li> </li>
<li> <li>
<t>Differences specific to TLS 1.3: <t>Differences specific to TLS 1.3:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>New TLS 1.3 capabilities: 0-RTT.</li> <li>New TLS 1.3 capabilities: 0-RTT.</li>
<li>Removed capabilities: renegotiation, compression.</li> <li>Removed capabilities: renegotiation and compression.</li>
<li>Added mention of TLS Encrypted Client Hello, but no recommendati <li>Added mention of TLS Encrypted Client Hello, but no recommendati
on to use until it is finalized.</li> on for use until it is finalized.</li>
<li> <li>
<bcp14>SHOULD</bcp14>-level requirement for forward secrecy in TLS 1.3 session resumption.</li> <bcp14>SHOULD</bcp14>-level requirement for forward secrecy in TLS 1.3 session resumption.</li>
<li>Generic <bcp14>SHOULD</bcp14>-level guidance to avoid 0-RTT unle ss it is documented for the particular protocol.</li> <li>Generic <bcp14>MUST</bcp14>-level guidance to avoid 0-RTT unless it is documented for the particular protocol.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="document-history">
<name>Document History</name> <section numbered="false" anchor="acknowledgments">
<t><cref>Note to RFC Editor: please remove before publication.</cref></t> <name>Acknowledgments</name>
<section anchor="draft-ietf-uta-rfc7525bis-11"> <t>Thanks to
<name>draft-ietf-uta-rfc7525bis-11</name> <contact fullname="Alexey Melnikov"/>,
<ul spacing="normal"> <contact fullname="Alvaro Retana"/>,
<li>Addressed outstanding comments by Peter Gutmann.</li> <contact fullname="Andrei Popov"/>,
</ul> <contact fullname="Ben Kaduk"/>,
</section> <contact fullname="Christian Huitema"/>,
<section anchor="draft-ietf-uta-rfc7525bis-10"> <contact fullname="Corey Bonnell"/>,
<name>draft-ietf-uta-rfc7525bis-10</name> <contact fullname="Cullen Jennings"/>,
<ul spacing="normal"> <contact fullname="Daniel Kahn Gillmor"/>,
<li>Addressed IESG feedback, ARTART review by Cullen Jennings, and TSV <contact fullname="David Benjamin"/>,
ART review by Magnus Westerlund.</li> <contact fullname="Eric Rescorla"/>,
<li>Improved the rationale for still recommending TLS 1.2.</li> <contact fullname="Éric Vyncke"/>,
<li>Specified TLS 1.3 as a <bcp14>MUST</bcp14> for new transport proto <contact fullname="Francesca Palombini"/>,
cols and a <bcp14>SHOULD</bcp14> for new application protocols.</li> <contact fullname="Hannes Tschofenig"/>,
<li>Clarified TLS-only vs. dynamic upgrade for non-HTTP protocols.</li <contact fullname="Hubert Kario"/>,
> <contact fullname="Ilari Liusvaara"/>,
<li>Clarified distinction between implementation and deployment.</li> <contact fullname="John Preuß Mattsson"/>,
<li>Clarified applicability to QUIC.</li> <contact fullname="John R. Levine"/>,
<li>Further specified what to do on reaching the confidentiality limit <contact fullname="Julien Élie"/>,
or integrity limit.</li> <contact fullname="Lars Eggert"/>,
<li>Added a note about post-quantum cryptography.</li> <contact fullname="Leif Johansson"/>,
<li>Improved the text about Encrypted Client Hello.</li> <contact fullname="Magnus Westerlund"/>,
</ul> <contact fullname="Martin Duke"/>,
</section> <contact fullname="Martin Thomson"/>,
<section anchor="draft-ietf-uta-rfc7525bis-09"> <contact fullname="Mohit Sahni"/>,
<name>draft-ietf-uta-rfc7525bis-09</name> <contact fullname="Nick Sullivan"/>,
<ul spacing="normal"> <contact fullname="Nimrod Aviram"/>,
<li>More background on strict TLS for non-HTTP protocols.</li> <contact fullname="Paul Wouters"/>,
</ul> <contact fullname="Peter Gutmann"/>,
</section> <contact fullname="Rich Salz"/>,
<section anchor="draft-ietf-uta-rfc7525bis-08"> <contact fullname="Robert Sayre"/>,
<name>draft-ietf-uta-rfc7525bis-08</name> <contact fullname="Robert Wilton"/>,
<ul spacing="normal"> <contact fullname="Roman Danyliw"/>,
<li>Addressed SecDir review by Ben Kaduk.</li> <contact fullname="Ryan Sleevi"/>,
<li>Addressed reviews by Stephen Farrell, Martin Thomson, Tim Evans an <contact fullname="Sean Turner"/>,
d John Mattsson.</li> <contact fullname="Stephen Farrell"/>,
</ul> <contact fullname="Tim Evans"/>,
</section> <contact fullname="Valery Smyslov"/>,
<section anchor="draft-ietf-uta-rfc7525bis-07"> <contact fullname="Viktor Dukhovni"/>,
<name>draft-ietf-uta-rfc7525bis-07</name> and <contact fullname="Warren Kumari"/>
<ul spacing="normal"> for helpful comments and discussions that have shaped this document.</t>
<li>Addressed AD reviews by Francesca and Paul.</li> <t>The authors gratefully acknowledge the contribution of <contact fullnam
</ul> e="Ralph Holz"/>, who was a coauthor of RFC 7525, the previous version of the TL
</section> S recommendations.</t>
<section anchor="draft-ietf-uta-rfc7525bis-06"> <t>See RFC 7525 for additional acknowledgments specific to the previous ve
<name>draft-ietf-uta-rfc7525bis-06</name> rsion of the TLS recommendations.</t>
<ul spacing="normal">
<li>Addressed several I-D nits raised by the document shepherd.</li>
</ul>
</section>
<section anchor="draft-ietf-uta-rfc7525bis-05">
<name>draft-ietf-uta-rfc7525bis-05</name>
<ul spacing="normal">
<li>
<t>Addressed WG Last Call comments, specifically:
</t>
<ul spacing="normal">
<li>More clarity and guidance on session resumption.</li>
<li>Clarity on TLS 1.2 renegotiation.</li>
<li>Wording on the 0-RTT feature aligned with RFC 8446.</li>
<li>
<bcp14>SHOULD NOT</bcp14> guidance on static and ephemeral finit
e field DH cipher suites.</li>
<li>Revamped the recommended TLS 1.2 cipher suites, removing DHE a
nd adding ECDSA. The latter due to the wide adoption of ECDSA certificates and i
n line with RFC 8446.</li>
<li>Recommendation to use deterministic ECDSA.</li>
<li>Finally deprecated the old TLS 1.2 MTI cipher suite.</li>
<li>Deeper discussion of ECDH public key reuse issues, and as a re
sult, recommended support of X25519.</li>
<li>Reworded the section on certificate revocation and OCSP follow
ing a long mailing list thread.</li>
</ul>
</li>
</ul>
</section>
<section anchor="draft-ietf-uta-rfc7525bis-04">
<name>draft-ietf-uta-rfc7525bis-04</name>
<ul spacing="normal">
<li>No version fallback from TLS 1.2 to earlier versions, therefore no
SCSV.</li>
</ul>
</section>
<section anchor="draft-ietf-uta-rfc7525bis-03">
<name>draft-ietf-uta-rfc7525bis-03</name>
<ul spacing="normal">
<li>Cipher integrity and confidentiality limits.</li>
<li>Require <tt>extended_master_secret</tt>.</li>
</ul>
</section>
<section anchor="draft-ietf-uta-rfc7525bis-02">
<name>draft-ietf-uta-rfc7525bis-02</name>
<ul spacing="normal">
<li>Adjusted text about ALPN support in application protocols</li>
<li>Incorporated text from draft-ietf-tls-md5-sha1-deprecate</li>
</ul>
</section>
<section anchor="draft-ietf-uta-rfc7525bis-01">
<name>draft-ietf-uta-rfc7525bis-01</name>
<ul spacing="normal">
<li>
<t>Many more changes, including:
</t>
<ul spacing="normal">
<li>
<bcp14>SHOULD</bcp14>-level requirement for forward secrecy in T
LS 1.3 session resumption.</li>
<li>Removed TLS 1.2 capabilities: renegotiation, compression.</li>
<li>Specific guidance for multiplexed protocols.</li>
<li>
<bcp14>MUST</bcp14>-level implementation requirement for ALPN, a
nd more specific <bcp14>SHOULD</bcp14>-level guidance for ALPN and SNI.</li>
<li>Generic <bcp14>SHOULD</bcp14>-level guidance to avoid 0-RTT un
less it is documented for the particular protocol.</li>
<li>
<bcp14>SHOULD</bcp14>-level guidance on AES-GCM nonce generation
in TLS 1.2.</li>
<li>
<bcp14>SHOULD NOT</bcp14> use static DH keys or reuse ephemeral
DH keys across multiple connections.</li>
<li>2048-bit DH now a <bcp14>MUST</bcp14>, ECDH minimal curve size
is 224, up from 192.</li>
</ul>
</li>
</ul>
</section>
<section anchor="draft-ietf-uta-rfc7525bis-00">
<name>draft-ietf-uta-rfc7525bis-00</name>
<ul spacing="normal">
<li>Renamed: WG document.</li>
<li>Started populating list of changes from RFC 7525.</li>
<li>General rewording of abstract and intro for revised version.</li>
<li>Protocol versions, fallback.</li>
<li>Reference to ECHO.</li>
</ul>
</section>
<section anchor="draft-sheffer-uta-rfc7525bis-00">
<name>draft-sheffer-uta-rfc7525bis-00</name>
<ul spacing="normal">
<li>Renamed, since the BCP number does not change.</li>
<li>Added an empty "Differences from RFC 7525" section.</li>
</ul>
</section>
<section anchor="draft-sheffer-uta-bcp195bis-00">
<name>draft-sheffer-uta-bcp195bis-00</name>
<ul spacing="normal">
<li>Initial release, the RFC 7525 text as-is, with some minor editoria
l
changes to the references.</li>
</ul>
</section>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAF/x+2IAA8W93XbjWHIueM+ngNUXJfWQTJH6S6k9HqskZaWqpExZVFW6
feZMFkSCIkogQAOglOxcddbcnuvzAr44z+CruXK/yTzJxBcR+w8ElVllj49X
L1eKADY29o4d//FFr9frdOq0zpKT6DYZF/N5kk/iOi3yKpoWZTRKxssyiX6s
kqiYRndlnFeLoqyjq3iV6NW0XkXbd1ejnSjOJ9F5XMcPZTx/4d5z3NyJ7+/L
5Okkoj+ab+5MinEez2lKkzKe1r00qae9ZR33yun46GB4cJ9WvcGgM47r5KEo
VyfR/XjRKe6rIkvqpDqJcE9nuaDR8NfB8PXrbnS4e3jY6aSL8iSqy2VVD3d3
j3eHnbhM4pPodLHI0rG+/LkoHx/KYrk4iX68O40+0J9p/hB9h586naqmJ+Yn
0eXF3ZvOY7Kiuyf0V14nZZ7UvXNMuDOmcZK8Wlb8sgRP0dp8jLMip49aJVVn
kZ50ooi+J5lU9SrTX6OoLsbeP9N8kuS1+aGixSyTaWX/Xs2DP+syHdubZUFr
ezXNszR3r0k+1b0sreoeDXJfZHRb0fvj/ybPLWI3TLW8t7/kRacTL+tZUdLc
e3QRo9KTf+5Ho1kynSYl/yY79+e4LPLg96J8iPP0L7zKvGLLtOYLyTxOM3oh
npj2sdl//4Cf+vTm4EU39KI4zeveaT4pE+9lN7Tv5dq18IVYy0XCC+q/taoX
ePjv9b/9NHzlXT96U1QVjeG97m5WzOMquBC+Ky7n/jtqvr8/lfv/nq7yp3Xy
opzTD0/JCVFmPnV/RdHdh8vbqxMexC45/V9PZnWKFY/nqSysmdbpJPV/1nsv
+nQUi3kS3ntBp9P/HWflJPqGTsXeN/xDHZcPSX2iD83qenHy6tW46tfxsh+P
+2n26r/V/PirRbxIyupV/ZyWWX8xmcrjzFL06W/eEP0UJU7RFYaN3i3n9/RM
9JzWM1qdRD43Ok+e0nEi76+SMk0qrApNa1EW4350Vq4WdRFhjt3o6t3ZKBoe
DY+70aA3POxGowVekJS9n5Iyix++6dAwZ7Nl/jB4fRKdv7/sD3b7g8H+wau9
4dHrg71hn/+7v8f33V6l+H572+7xq9FNf7g7OOoPjnDHVVJXt8lT8ejdtX80
HL7KJ1VFNw53+8P93df7uPc8eYjvafZZcrN71DLo7lH/Ne6j87rIkt6MWEM1
ix9b379Pr8G9o+JhVqRxTj8N7H3Dwd7xq6oq8/7g4Hiwu8ffclU8/AIG5X/y
8PVgl6736b97R7v8QTfv359fXbRRGJEycb5R7+zi9s6jjfe0hbRpESblUwjT
RkXE8fz83F9WvXFS1v2H4ulVPo6rV3FGf1av7k4H+73h8e6pRxzRaHQV7fV3
o5uyIF5XZNFPyyxPyvg+zSAnIE1kltFpXcfjR96p029738ZVwsxs0+TPTl99
WxbPREJ0RsvlPKTwQUjhdv7j+H6Ku/s0xiuSQEvmn6/8GZs3k8D652VaJnwH
y0kQ8WVVLeN8nPDMr+M8fuAbIDhvlvckYLJV7w6yJ5lEZ7Qs6RQyJ6kiotiK
+EY06A/6h/jKt0nOtEyTHW5kAu/69r7gaL+LJ2kcXtIn/qkfnS/pC+lojYNH
/il+TMvGNcc+PtCUaTkb/CMdBxf09u/7xJvextkkIWaWB498349Os+RT46rb
luE3/lJ/c53iA6I/F8syuql4Tf+BXnBOXHoMLotl/ZBOkmpBAnkSfUjix+iH
ZFXRPKJ3SQ0prgylWuMoOi/SavL0k9NMRqv5oqjS5dxOCCdvRf9cZyH7h8f7
YCH7R7t8mM9P3130Rtd3N6RHvTk7Ojwa8imjryurIr8decd2QBzg1fHR695e
73B/2Bse7L0+6O1+HO66cW5/MsPwmX57d3fTG11cn/Kvx8QfzK9EMua3oflt
aH7hZ3/IkjT/hfggfcbupjkM9g+He72jjwP+lsvTd6cfSS874X/166zqLWLS
6SAgK9xwvcxq5l0X+RhMmYVesEAHrw+Pj/v0n6PB6wiPvLsc3fWJp73e3e0d
HJ7a2w93h69fNS6WPHFh6HGWDQ4b3Oz49dH+PnEz/Pe1rNoFrc/o6mlPlu3g
kL/j2yIZP9JnH248Q2/70bd//VdiLT6hvo3zvPB+d0L3n+Jl3jhtp6zneBf0
7lEf1EfMIrh7lJDY9X63p4YY/Lwoi6fqcRUemmUZ/9K82LPq0PfFU5wXT43j
fDMjDrpYNK7qSbuOV+Dhh+1MMMGi1/00HpfMB3Hnq/2jg4Zgj755VxCn652n
VUknECeSzurp5IkIJMYxo0mUJPSJwWXgwcSIVsrFq4jW67uza5xTojE+Y98X
y08kFzfv02mf7wlXPq8L8GJ7wekwGz5uXJXjfk5aL8sn/PVqnhCzfEX6xS/0
DdWr+6wYP/bG6WJGigQxmlme/vMyqTxxcD+evzK69SvQ697rnnCWHhsr1asH
uuMXmtNHc1tz7U7p++h3NTiiN6Qjko0ljIsOQvSk4oAYHK0TS72fNkvq68u7
2wvv+6dxViXtn/+U9OcpmRDYWX9CZzRRep8vful7mOVefCKOiNlhGqdXN6dn
pxs36ZoOE1HPI7H2kOqv43K8rBoX9aEzOic0fBI+cTYraZtSHBZ3UZ+47UfX
Cb4seOIWykntX9Hbz/vRTTGZJPd5Gofn/JxUZXpD46o7ktd//X+yrHHcvyez
Lrjw7zrBeGo8e07ycGLf//Vfy4fgimMq9Gua/yXJGmzlPpblCi7bAzEcbFLq
neIGUchHnoxXMtkSOt6v5NdK5eNwQAcFu1Ez4b66D/Yz1PiVVHzLWv0AVts7
o/csmdB7dJbjbPUX8BDWnYj+HmKwFB3urGTGIRyjcX5azIW9XTIrfhxdvLv8
xxbhHm03Lw0HO8yGzm/ff3j3kr51+pSSGAy1rXReFhP/yu/bq38XHf12VZDO
6nmcPzbmdh2nj/7v3qTqZHmfrB8F73e9+aof/URaPxFJcPfV8jEJLrjjeTop
04aueB4/pRO9EDWm8lu0S33qJyi+j7PiKU+Dh35KH8kuDa85vfeHv/5PEm0N
u3lO3DEOLrn9PitmeRLuGtnjZAjk/iV3/wXtSlaF9y8rOlCJf8kxyps4Dmcj
bBL2hbnS81wytIZ1yCT/vHwieexfcer34X8EiyBlQaQmyX0SixWOdxVyjdid
lJBlyOkjKUGaPDgBjjrxB/oXNLthyzkfHvy2cz44lHN+e3p29v795pP+GyXM
75J7v5Gb/G75Qry0XpvY98UMVFaFV3+rUPr/WbzM3UKHhHIbj8cFiQ3RJ0+i
N2k+MaKD9JWsSFkbvS6qujdKH3K2s/O6921a996TJMkSI0p652+3L3b+AyUI
6aTpIoaH6iVVVu4KlVlhdd4Vxx+JHK9AYsVzk0nmaZKtXXbvuU7y5C9JyGBO
s2mZTIJLjupHdblMw22/pRv93x33OgWjz4n95KFcGI2Lul67uu5gFN2TREIq
bn/ouxcZGS4k2aOzZfmUqNuEzfr1PXIX1TP4UMaL2YpmePPDWSQvgm0RiyPl
oM323Rsc94b7g6P93uHH4YCtztM3F2c/3v50Mdq4g7QldEa+TUr6vCRt3ZO1
6z3rTr6KibUHz9zF+S+x97ss1YDsxHEyf9HlVsVTUOBTUvXJXlst+nURGGkj
us4rCfkxKwrhpvSjrK+4rsya92TN/bXkBXT6MfyhL63K79Szfwdj+33KFTHq
q2I8qxsy/TrO+Uz415yJffvXf62aVsBNvMyCC7JlWJ/WfWqxqo9eDeDdbZrV
wtOwTXB0lfMU5ipROfhYXCMURx+WzGnrRDS+oZnUxrLm7fohnYNeNu4TqQY/
pKHU+TNx04el/dnxg3PSyhsysKrcr24LmyN+Txx+nibNIUmHeRNnTacIazH+
BU/Xox1LGmpnGn2/SuzPjvqaN57TR81Wy8fmrTSJD2n2yH65lnmE1/SZH3Bu
Q93xhyIv44n9WW98T1x3WWfL4Nb3+bL0frbE0n6oSSqWVZ/Ofn88X/aTyfLV
f1vxBj2aUMtjOu+l1ThuoZ83cPyAMEjYsZS7Tuj8rOiriBCWRCnjMbQyqFdE
RnCiQGQSW4WnArphvZyswInPb0+vo3MivmV5z07ti7IsSpBYr9eL4vuqhn+n
8x8YEY5iom76+ElUF9GCrMRkXGOt4ij5NJ6BO06i4omei6PndJJEJX7CVGPP
xlyodVl1+d0k96M4qwowujk76Yk/pML3Kglt13ZW9tl+FL3Hi3D/KolLGgz/
JDUDDu9VNIs5dEUKFGZbJXQvLR2EU0HqXuzcXFBheQnoH116fpwtRVNxt2Dg
OWkqHLAt8mwlSyAuqKhaprV6YujGtKRbJ/Q3fXRBm8afTJO9m9EnGRcVPuMJ
fnEeOkOAoY7KltA+AtQck8N9RgnD0JOEdKgVf1nJ/nO6I64xr+CD+iAh+q05
NrZRt+Q+S7CZ/I3xL4V5AUYax2Qe9DsdIkBa4Sylj/X8XnXwRc+03gtI+2pG
s6I/bt+ccZA/ep4lebg3uDfVZU0nFUdfcBR4m1OmEZoRvmPQH/ajP2N7eZVK
eal3X4oLdDZpTxADR3IBf7w8vIfrIES6HD/FaYav7Tf2QpMQeDoPS1J0cJIe
0ieddZ480zaQsl/kfDtGt3kM9iv70SVR8WTCsxJSXHsB7kWiAw+BP5DvgIV4
SukdtAa0S/wGoby+HGNaoUmWdDp/QDieDI8lR1Y6/ytP9RPcx0ImG861O0YI
dkSfP2sc5Ndf9d/DX3/tRpfXp7j2fyASsnswwE837/mX0d35wR7+Hl2aO/aG
h3wH4jf608HekH/Ct/7j9Y35+XAw3P31Vzpzo+V45mbFJH1fmGg2EQjcCviv
je7am81pDm7DISonRG+0hDT6aQZ2/eCGaxnG8rZ7XWCOpk/SKZtXdTBkhdWf
JFP4yzfzPRJilh3Rj6R8YJzkUwziB7n/w4+XZ3ZRd2kh6IkKC9E2GDY+L2iz
U5pJTaeEqLEaE9/SgKl3Tv5EJ4FogF5OthltMZmkK2ED6+yF2CKO9sOsZgLB
sFUxjUvwhWp9UzYvIJ2BkMtHWRIzXXGSweBgjetPAq7/v4rbv6HVo2+uwUu6
juhOL0a9s2/N9uwd7tIxEG5wtk8//g3iYvuHB/RjYoN2RD8P4MqzOS368yzF
ThakjGAyz1hnBHncpJXbWfkg08ajuFc+k35W9kuGPtKMOG8M0gIaLbFJvkFz
XTCDe6gluN8s02NOliztUgoqkZ0A7alY4+FjSVPKMYBlhdvy5Uf7B0e//rpj
5M6iTJ54o5rSBVEricAzV5Wvf06zjCgsWyjpxRNaiWVO/58zuORXfiKmE3Gf
kI0xaaVSO1uQK6QCCVA7U+gPOBn3CckB4eD8WWMsd1mbtJgUJJP8iTebZtKF
uACj1HXC+SLyGJfpvVl070h1cR5iPiriTDdinxhLlXhy4E4PCOa/zMG46bPH
tTBsf1+Cd/lrzQdblaDneFWdkHBxm23FXijF9TAsNbFQ5LHS6cFw/1CJ9zy8
cri3f8RcOSOFWNbJaA+WL+pGVyqL7fvTSs+kI1Gi/YeUttJ8DglbfS/oPcNS
0Ffk3vKCmnBi9SV/wj4moh/VwdvwtTpIPCkWWM/7VchQSA3X08XLMrZeEKve
0FtB/n1aT80Rqcxqmc+mV+e8QHwG6WgSJTI9yYK9Pj6mpfQGYM1Fx9Bb9nm1
MeGS+C/pZURq0yLLimeZ9FP45Ll79HiA7fgTvoH20Sy81ZqU9LDONDSpNU/y
uY6SfDIEWT7PiiiFtLHqkDAby1vhtLvHFD02nyc+mdFEZ8Uz3rNiEWmko4i9
bLVZX7ZD4JisK8FQ+hNiD7GaD8W0fsYBs/OVQ4aDVy3nRrG2V2mvkk+IlFfK
3MfE3HHG7hP3MqVLTyesVGzrqTOKNadIQRE5Y57BqTIyihz+UIEWE7MyOlZM
cgkO2IhUQFio2QonKjPTQGIe7cMzHVTMjzRP9iN4IettmnNagzv16MBHLMho
SebLehlnO10wsmmKTMs0xjxFi2KlL6WFeGD1UHVBVcjNkjAP0kxcZU5tCgDW
CbKchivwtoreJnx5zZqBQgn+P0+gbqbVXKw5epuNVJC+Ucv9mCemWLLAlVXu
egIZ0gQxLLCTvLnzUSyCrCZjGm9+LtkRTQT3Yw69BktGu0JUQFuYgjPQu8Ei
RQLS03HjY0UFTipjsnACcSRy8dz+0CVmQLJr86OsIwSmG1bWJxA6h8l8UfPd
8DnN07+IdWLPhDOaWghehWDBMiDDq8sCU0p5QFquYlnGZKxXK5Jkc3lL8eQN
uteP3hK7oeeVdFORkHEGgULLrrkk/ehd8gwVJCVNku52LKTrn09aCXlVJCZG
BdnJjo+aeWNVzOXzSj+PT7aAdUrva/2zCJHC0pOOPZ3xOZHWX8zJhOKNBHVw
2847EBQtBRHPdMluO19qZ+mjnDleN38fJkWiHz6ZlCAZWtY5c6wvccdX52aD
HWMURimaqV7HxMnSyx9YLoksg2FGpxg0kJvzqLOe0JZkxUI/HnboIi5pJ5bE
4sEz1EoRwhbFTWUh6X+kRxiJ9s/LOK+Xc1bblrWk/kLTiokIYhKENkiD76O9
jloO8tg5ptMx9EOIlyenL8t5LrLiIfVdFlhB4kjLEkYRffUCYSE7Hz9wkDKD
RN5gygbnA+8As4RaSLlgscvkMQf7abCmPzl9GZL0Cd8TqJmVbgCNGZcTQzuc
O3px9wYHO8mq5BkcrsnCK1rpbMLSTBVGmkSZTDPY0/cJW2x8SBLlQ/h/xIjg
YmGSglQ3xhAkeTAxI56rwPR6aiQEoWCgRdXsR6d6suW1QpSVe5NMnTd7yips
c2BWYsyBo1W4J6J7Zv8SfWGxvhglvSHGl/p6W1f0QRrJcNjooSDmHnAgMhxL
S5Vs1BCNVL4K6vEklj963JkrEsW0edIaiqxu6VNMo/tur5BveudXNnic5BBV
VdelxSefxsnCzHaZe1I4ETfUdpUk61rBTj96zzZcg/h4d2hFJfzaWFPoSrxF
UkeSlCFzJII2VKcyaF6ArVWi0ijFGN7TdbxHBadlG2Q1lvRKsV+raDvpP/S7
vIxYQtlC//Y2L9DOn4znL5aTOROHYtdXt9QT6ZhcPGHfAWsbYKetH9qP3izh
iCjnLXRnVcU4mmZFQSyQeXU0Tmjl84eTiI8uEXlcpfcZPR5PJIJDNFeUvEpO
nSwTR5c8vwfogqtCuZkhuGq5YMeK9TG2aR7iW8PchG0yiwdTsAyU2B7Pqc/+
A/XpeNsE5k26CB0RZ5FbtRR38Rbx4UJECm6Nlo1hooZ1Tjz2PslJc4WcirNV
xbbTA7gePWpnhWqq/IG2/IkWvkXxUl+pLpr5xlL9PxOibtGhSR/gpXFCu05L
9szCowqPmCip7mSfWXO37cvtvDwF0vlKeFSzyVay4wCJukHiLh0/GgmfcHyF
TxxxwmejZ0TfYn/ORC6ZbNkk2v727GbHU8x4Sna9WEQtCtQ5pXmPFc0KKo2w
4eiWHRZrhE9M4pGVTPD2pCyhiOO8Wee0r/eErJ2DS512p/bnz2yrv34tLgDj
acb6ff5sc69hUPMK9aMRM6ucM4fLhI47XTP8c8L+gmpNMw1eBqd228sk29B7
k76qytPWV/whuuPYKpSFFQnIKOeCJDmfstQ9y/DozmpN5jm3dmo0lbxKQlsN
omn/eP+YRFPHeQO3ZI5bXfpXYFXhl7ErC+E/2cHG/yLFCR7ZSn4P7Sv6qbNF
6pb+gjtCYwu/OK8f/qI1IeOVrWKSaHzDY2L+E2VM/PirSrJpD/oZ3H3B5Dpb
5pBsCZ1vCdfZUrMN46A4soq2rn8c3WEw/Dd6957/fXvxDz9e3l6c49+jt6dX
V/YfHb1j9Pb9j1fn7l/uybP319cX787lYfo1Cn7qbF2f/tnM6f3N3eX7d6dX
W+07KOY3Mx4y7WqOLnUCRxcdx3/7l4HxoA4Hg2OOM7DjZHC0D8cJ7aG8jVmM
/An3Q4fOFOmL7LDM4K9fkPmRiaUCTpCLc7DT+eN/wcr815Pob+/Hi8H+3+kP
+ODgR7NmwY+8Zuu/rD0si9jyU8tr7GoGvzdWOpzv6Z+Dv826ez/i2H2X5Owm
bBb8fj6J/kB0+Kue/kodA841o881tS/fTPB1sP5aMbOnvzS87TBzyJxcVt5p
FveXiir2u9Ps/+BVqqmrC7/+AfmJryBZ1i/rd/WMa4w+8JI1FhLgJNRhIIgD
n5h0XSw0qaPISFdnj4F+2JPn/DMvY6sHj5GqpM8hXFAS8bFm1niUnXROm/Y/
kQ9Ci6Nl7FxLMCBRrrfmZD2hbf1jdNlQRwz1ko39UBBLqhMu9jOOxGGfszCN
H/0kuismMUlLzvPE6hiPDm+Ifog6gAdH7M/87S/da76U64VsWG93oD7QmLUr
Ijwt3kOISCbGxnW2fHgwHgTfbrUielYgv/B+icDXhPVDo8EJfwzJr6/TsIa/
uZl9vJ/IIq/Ex8IvhFOJ4xSqNRP/1W+lmz4irGI86Efw6Urw1Uq0MfxR7EQJ
A8rO3OCUS3aiimTV8kuRWDS0/M2RUp41e2meTVwI9EML8heJ0U+XREiSVSJB
Ot5GK5ptxZYK6Klo3Z6Q/qodxjI5//SubueQAwhrVMbK32607aIQdNwHx8fH
O+vrz3awOVDtOxcsohk8Ey9PRDpfTyOwl6RmQlBLdTgxBxRDR9uXP+3wl599
e6Yu7fUwoJ0WCWt620OMWJAGD8lImrBGkXBmjoY7WA7xSjaPsxGAhrmy7zqP
uJ6VSSCMGPye9R8YrWdv8/oPGuuPcq0dUWydmts8gGZ1cazI+oCvurlh0E5i
RKLE9ikbq8lKLsdIUk11MBFz0feNS8Y6B6y3k6f42g/osrkZjG7XmgbFnpqH
OeTjKx1qsEMmyAhE/uzt2Nm84j5LaAbJ2td4qCJGTeGJ52tIJiIe9Mx6npe9
yASx2K6gR7ouv2YTMQXalA0asRdZYz/iFbRe2pagX8qxFeSy4r9rN+wJv2Jn
TWtKiPFr9JoZSl2RecKmaD242K9OJGDEc4QziHafWLbv9N0zflTYZE8a8pa4
mpl0N+Kyx5SZ2z1dMrkGbB4bHsqBMDUuqmZKyzhLNb6jsBQmhyBL70suooSR
ppF/aCLGeS6xZCb+VVI3yGOPlG542yyVh97VholNS1MtE94WsnBncTkPzHOm
FCYRxMRxKYWZ+S5I1rBRjUSixmLdqgO5GXUndVpcv25FWyiCyU7G5VjCouR9
g6FPGk/RelRUmW2uRhDjZJpOp/7R6MoZW7BbDG8IeRvHPMGBGklqxmXY10RP
+39tx3FP2Bv7Anm0GfKHbYKC5zppdcN61j82S7iWzWC7K5Tuao708eo3HURm
VSq7wtsJ/CpYCrhRpsgirrwDsMPbyisjh7qVCTiHjhlWHY5tTmLs2Tsy2ttS
hcSPx9aqoQgbsmhPoHpVlEGCk8yVyUj9PK/OzeJvT4OMGU1ikhwmaH11UTzK
ZE3gaofjTC9xm2QeBl7wijEX1WQR55Zy6ZOfasMTdN/Im2gCczKGJS2sJKiB
Jt/MjKJlLcFqOX1S3Y33NOf1sKUNoRk9vtvusSPzCuY98Sey4egbCrhGa86Y
pZNg6aypPItS7vmvHb/Gmz2mQ9sBVxkyV+ib2KxhjaVHU8iVvVSbhyMS/wB2
IPNke4VDdxvT2CQLLJZstVAElDQRiW81ZGo/+nbFCUtlXNWcaPOVogZrZsay
YVYjQTwVgghV2AuHreMJYkOxpC9zelG2wpcJ51+18X37FlAav8nmuajRDNba
iBfTRLpOYrEzssHGSIutDaWwBJ7ywRI3InzmyGWwCS6b9QDzcpai4F3r/F/i
zrCXz9uN5Y7IbKQ1TuJFHWhimNaP5zecRIC0U0RJONPX6XIgEqNiBrlGHD/9
GoOXz6TiGZgQ+8lXKsL+CfYskX1OWOLT85N30aTREAMTxwQvtq9I63ezvhjf
k9D4CgWxNVmq8e7hF989bH13FG3feSepMVVOKtj5CrFsmbKfQPQb5XJjqV8Q
0JrrEDWTn178/r32tQfhokblHqYwPXBVIJK55umZ6i1wZTkhNLTaniUd3BiZ
wczkfTHQtQlihZ9cxTE6zhzclOwVfUi8tDS4NEDUqBNihSKuTQ75c05HaZL0
vFSc0dnop2ibq40Q0YrOxMwZwcxBrd4y2XGZNDb8ustZgEwYmRhfULHVFtIv
b7WX99yWV8rXzUZ4ng33RnHDjThwhyE64mt2R7utGMHmYtJCc24nsnggY+Ae
wlhSMQP2OLo7vb3D1BAewg+X+S+6MtsmziOr2pIB4pJPmWlcc7TlpWhZZZL2
1MF+z+65pkIM62KeqNFvii48ibRawKlDnNeXaRA5ufhxngvJyoySlP0CT2nM
tjYgfWhTrVBBah0rT0EWlnE18W37+3t8K7LsRzsQUzLYPCEild2erPJ4rhNa
LkBfIrKNcjQtizmJPFWMZFPwZqVB+kFfaLbCpOamlY23uI83op6z/U2q/g68
v9BMWddQJdoRLWZpKN4Y88EXm6lu2xXhj3cfpx+W7GBuMXxFNcebNRJN1CdR
OfNuHVAVmdjXvRAuqkSex83hzbJKTNVumJ2VXObDbNzg7bcI07lPDIVIWuda
9lrubuQA08OylDsbUezalRzwZriEAjFF2j+DpHDz861VwnNd+/7u2hRVJEig
OwZZS1R6bX5VAsVXAvzEkpDjtyjo/K3k9NJD9+mkMqdskQE5Ernq6v6P7ytj
wsdO8IhCp5sp6lTjzdYIYZ1I3kgsC9yAa1WEFfKTCGnTYWx+IeZhvUgYSWf0
oSjJqAfeGXH3exFNnfXEj1AfwIP8XsMwra7sinTeju7oJM8k071Dpls2MT7x
o2POta4KWTS8V2Ytse4YaE91WjntcMVsEea9VlF04jESWDzWYmSBP5iqCPha
zAYPoqJfnQP+0B1v7A1Dd4m5ZJo5t9IceZdcK/yCCYdH7kjghF9r/CYkmcdw
FZKintuURmuDK3dKa5NcTOR4T1sYo0oXn2w/g7XJDfFTCQI2MupHKmkGqoPY
PSD1Y5TOU2TDBDluLFyYUvIi7/FOb6iZMnzy+u60h7nhmQ7AScV+gopF1giE
sOz9630UREkmPJ9eL5nw/N2IIRgnTSArmnLnHYmqSXRBP3Ji1zbg7HYMQR0e
v1ZvvxZaWdA8fZdXaHV0NBiy8uoZnSSU7wUVcJk7eWHSwt0vITsnSyoXxszb
XrSI/UpX13opRfOCH0V895yQZNl5MLwaT2uJzTozG3Uz9EJqRbpYSjASvNX4
RlFyw5oeJ61J5uxjkizaXqkFNhmpjf2IVaIz5AeI06FjddGx/oioo2eCBjrQ
2D1oUx6MprPd1HAMhQ77h0qgqvCop1hO04Y84UbCmz33UIaVY0Fl7mXIOfXn
hcoe8+ZDstWH+m7xgO/8SXKPwQNcvlzKzpG8w9y8ze1B3wNkN/4R9TisUXPU
QYJ2IuRAO+IuwPlR6ujMJFU5Eh+aWsDwyMALhzwy+mNppxGXdMR4t9VNbHLl
ilryNXAiOo00YS9crcU5ZjX60TWHd01qHycZW07vvs/m4/KHmIxLKch9YdP7
0bsC5ela7fJSNjqbijleb77M3zS7qLQgvKqs+bkErE7DTdr6bLW8/0WNccuB
3SFVpoaPP7u9vDaBShr80k8D1PxTZxL5r6I/Z+nDzC8gYgJUGce+T/yDIwHu
qMJm+8Ql8HIMVXtwdW38tVoGl2sOAbshvr29OD17a2KqUuMlnwIKMvq9unox
B6bse1vIJfUCCI8bA4EVEbYblpW9xvogV1s2y6lNHtamw9wejlXvNlnB//Yv
HnhtyHj8C6QnpWyF14kWayyFl/kpsfj7fsUmOOQQfSK+b8J16Xx2rfdXgkCW
h80ZXleTSyviUCZCXnKujQ5t7cKOkWLKhMV9C2ODbXxU0boF2cfjXOM6OB40
1qNC+J+5RiVW3hXS0PllLocMNTUcvHEB/D/RrQDRfwRCrWgGc0xUKr84WapM
fPgjom+UCUQXZ+ejU/P02F9fjyWQFQyFaJYmWmGVsUXirGxjaODaz+bJj95w
P7u5Ehl3VAt4fXQsxc7ri3SgNCP3OEAFU0WzKNOneLzqBMU5CPRVxViUaV4F
lOYvQfaclsrc+qkwlVxTotnlfd2V091joPxGwW3HP8saFLN+yM3Ldb601orG
9rkmI50VxYQzw7kw/r74JG51NXC6Hf1gnUqTZdmazjnMHj9ht2P9zKBiem1R
Ktf+eUz7lkw4ecPfhLVMwqPjIbLNxuBlHbW/uhwQT60HV4O6Sc5VGc7aExng
ZdXErqSmE2foXcDI8+JewVxH+lm3CekALFKtVgFf0jwhncLcU9p70K+hqtX6
p/csx0pz7mxMl0T1QVzHFHAs2YBGhnFViWDsLGjpwVG5KC8R/Jspp55Xta9K
0LxHMLg1Z2ptWqqKy+80v0cUw2ku7YKzzNmESx5Wkh5tXeaytH5US4/Gwe7R
ER8Nd/se8pX91Kub0Q+a2OGcD2mo9Xc8rtM/FF+qDVdaRu2AkPWkxVJQg2qm
lDP2FbSFndppxVCZ4hW/l5znsHZmiyRiWY9JUmz5aQ3rC0fr+sGFYoXixHFu
l9aXeTA+QZphnQKHHXx3j1E958XEFaCAW8ZPSTUpC9HLQ92439G0/HUPnznt
jf1l7nzaSN0x/g3BS8CnmQideoLkYTj7gAZQsftUh1BNYx4rDKmfAUIW2h+j
O36258X8mNtbn4qiXZTJA0gOepPYklw0BIVyRVZn8sgWt3IT8XubmKhm1LNP
q5HAaxJL6M/eYlopnaj0Bq9s3I8SEdKJ6penTKRK375i7dC6tkxxEIDb2N4B
EsIEC4CzYEwpCbVBSwu2xT1m3pFBgGqBhj7FTJOUgMABOYuzKZYlM3vRNnU7
vGyIKqk2V6gkfUA9ZTIpPGJWBkyCsQVgxGT2HmhkS2RIOMK1dKkBWBkRzoxv
Ns0LXKQuskTKfgweyiThm3RpUbIgqAkS/4ztNLeZCJy3MmfXxzoV7IAF2Vi8
eJg8K0s4txnV82Sjso2TTrHUjesu3sDGkPr3OWoL13L755IqrfYWE0cV2vEt
HJo5v+StPaZCZIGQ6DaM6fmygqzl4yncVo+nMdg9xTEsKCBjUo4F3GWWmQR5
Ry2ZY8bp2FhwYp99eoPe0qAOsegjTtojZseWMJ3xmCG4jPrBeZ75hGs6iNTF
Ra9+QtapsIk7WoVYyXvRcwLmRal4JfrUAvyKdVUWlIHPQGwPI/rM6okWPdnA
cNLKKx/i1IIa3kyjUwY4UwtEw0i2E5EYX1CTQ7G1bA8Z6KiXpU/srjEWUscU
dAnZWEUCZDvpBzbLMBCV4UbCxNNwm1B/p0rYh47iho9EFWWypTlGTC31Junn
WxzYxvXtb9YlhrPY4OS1k+LiTSzf1qJ6/DiZJR8faWakN/AhMgBJnIbKFNBB
cBoFYlom531P19j1ClMFw+HthRsDySgoyW77zNPKaC5W4ULptVULu5s+BNkP
dCBLXhqhSJ5fasA54qjjr/mSeFzG9XKSqxnPi6XwOk45VE4/JyGwlNzviEz3
stph7ZrIm3EcLGpGBnrvhN/5J9kRTNRWAfMCe7OwYDrq8gXdF2MidFsptFCS
6/i2agvXQuEgichKHi/NZzOBT5NnmT0HsCBPOG/Voq51mucDLxfuqufC8GE9
c21c06Q/VJ43SS0vmy3WEFHMaknAdsCASo4/sy8xZdwI+MiLuckvQs+sKc4I
42aoNsr9UFTBYKLx6qr+wHixLnCb2rLediyHtZzkZvV96F8K8t2/6GHaNBXR
/F1emSR0VXUs+SIVh6Eb1ea2/claGaSnJvhRRskDnfivFXCJzYA1IuM4rWWu
nki/DkUAdiSJ0BjBHshUEMUyQWu5r4sGEj10vOvtHRwc0CbS3+xcb2YnuMiU
KoEOboCN1fWCA89m1ZiGZ7e6UoSWd0moCoy5dVh1cp+JKHyb0ELAep76pOzg
EsauitNmQ8qcHHXLG6WUCDwymsaAvPzZUsLHqbTi+DnitlUOg0qQWAMNLLd1
QZ5i05JLFZuXC1BJrt7MNTVNs3obSe1tK9PVvEsT3aYDzuJftQCrTJB9v5Ta
C5diEQzX7tjZt1ao3bnTKHQSazoJVsMeOcOdvJMi7hDcJdoDYryBZUhrdcc9
0NByRw/j58/NtmgwhO8KDxEjrSxdbwo1rIVBf2aKmCSTj3OSGkn5URSpjR4X
hks7HIqNz55Prv9CXbObaxj/eoHh4Exvc007NmTH4Bd43GEP9q6Xk0HvcQyq
gb6DQwr9QEpjPWAb613ysdcauYtzbd30yRNeAr+oZo+jbcR/xMOO0MKroYNX
3Ol+YYoz1cYrZK5ohJSz/M2KNAnRdJT6FCA7qe3ipSCjqnnspfSYbJRXwzBC
dUwSgFVEnbF1YHP+kBw5xCppwSY202X07nKH3VyoGxaG9UXCemmsTcRlJmmj
vFLW7NDZJCKhkbDGBj4rDogU1/P5S+smKuYowNNJlBcY+4bmxpkbmzAZNFsd
LmSuYvDyJ4BN2YpyBMvTBqdXCjAbuFbw1m1FPLqw/iCfv3MZkHAMwLBIuFnl
ADYjaMUKt+hl75z7hfbQoizham9g94qCCGKX9BcXTvKRV1jYisM0yDtMa6lQ
EJQeNjLDGgSrxKj3GoEIUfk21jxwEoifPk1rYbNfwqxnc0AbMe2ntOQtNNK5
cJ4KJW1lkE1LOWF3CuktRH+9h1Lg7KxdpxovEgzDF3R1VLjhjA7CBgTnbBfi
FmBf1HPuO9o9wsNHsnDJkvhR+IEOKnhkJO7malRZpAfHfYwm7/kXMY7sDdxp
WVGJg1MH9VLm2snLoPN8gTD6YbTcmPV8jNqhEA38QJddNuvivGMrI611IWVZ
ejPiRb6fBtw7zZdyt8dj80lHsSAtZ0QKh1parM0oz/h5mbtqzI8Yf3swGO6o
YoMSngC2sNMI9DrQhXZWdRJthYqYQmQiekK/dmTVZdEdD+SaWOuKC5bEW4iu
/4Nayhw+9PIZY56US2mM7w07dqvF8lQbg/hr03l5beBAaV///pZ+l5VLba9N
g3Xx9NLKMkFPOcWSKDlUahebgJXuqsPzJclQM6WI720mK4JHDbKkaJpih3mN
t3qNxlvvPCVlm2j33Y6N7cTZIt8g+bY5SVFe0fMMhR5iSuuJZ53fNAGPSlT3
2kNpzoajuDUui6rqGcG45WVNBHqpqvOCAAWXQkeL0+bEJ4Vrr2fbYVF9jGXR
YqM5mXOcEcbcqmNG8B40/kuHgWR4dROOhbPxOE5Hj4szo3OfoCsTp6a2Z4Xt
WZeXrA3OoKJFPtnKL4ykpGfFS140VQjPJLJJfFWQR6qHD2gcDZeT2kx58dFL
q/loXmAYzFYUhWel8zvOCijDOyydgH+o88zLJnUZF/JpQCtDgM4RARcPYk87
mg+f2sJUhbFm7WsDdydivHGJu4yLZzbXQuqFgE5kp8EJwP4C/hjBbJmmnGop
kjd1BGNLuDXNxiBDwB3hwWoL7gOgDnvOaTGJOvaWP0UzI4L9ylTJCVDoJEXe
kwLVAOep29G0WaVOo5fwB4iyM49Xatw5FCR2p5rv7HgfKsBPvA560OL1yXuY
3MS72BjoqWZ9brWjTufcyx7TmsEnRpW1SpNVj0qHtDXmPD7AEepKIF/EhLHU
oiXuMI0V+pXxQ+5IzFhINt5kILghGYDmfdLpDPqRPxuiFElTD2bCrwe9Z4kz
h1TrYVaO9HnH4aHIuI1Wb6ikdaIU4foUqe2Xfr6ZH2uQjYW6qlleArzOo8ZW
sYIaZzwEJgNC0bUYJ0vkpZtTUJ4q7tqYhwx5sEVeumR07rZrgSvGS4G+TzLO
W8GgNmlXMgnXp+FwymdJ89MT6f0FtqLsueJBWUQ2ObugH/i4P+4hgw4dsHNh
gBgPyk6VSjJdQhME/p2GXy0QVcM5mrSDnmMbs7iSaSLiJ8xohx0etoJeavJn
gNPsrkGhWWVEoUD5/GE2GFKABlio/+rq3+GH4aomw0usx6y2MHEqMEOfga6m
T9e2f0iTsk3ADNB6DJlbm7w6D2SLB9x2pmvQQcHUIDinh6tTqnwsDAXGooHN
/BBCs3BY1Y4LdHIKTMVfarEfvgRtQDxp+DWHHXshXx0sitkw5riWoDHTtY+s
wtPd/arjHRxtDOsfb2uPqPReX1cTcWNiBTPnNFo+SPwiqTRgWuIGjb+dtjfS
tRz4r6FtnxglG3/jcnsk+pU0+CJxYLgvEoi6lf4pKYvolljkhN2a0R3HtHZ7
t3d3O9wvxXP3STiErymmLCO2mSSnVIIQ7n6u07URV0mtmnDfmny86tjaV2c+
i8zSOFbX5G+4KBEgGjnWbWBTGpHeFN15Tl3tIPtFFChTM6LizMMMFkeUn3YL
i4/Oc8dX8RTbUoUALAciCVPAptFU8dQ64GrotA4WY+XjPLuUXWlywmwNGBWd
zhunmEOC9uDk7HE5WemBJHLtUinamql8ONpVGjfY1zoaysl7ZMzoIFqW6rsc
hzZxdFetFzwXihESYByBSMdBZwLxfgQKv/TyITMKVuyn6KJ/0Amyw5DzCX/x
YlZCFfBvDEr91WnJeZWywobKpFKm4yPmhqjAHMRyGLdfTKRHjINUynSqJCn0
3UDxENEvYFB3wus0QVhSdss5s4xcMJHpe7udmAtc+G/jqelyxhgWzRxDZT+N
BFN51DwVKJpNjLiToNpVSno1VcRFr6zn2Sa2gktOM1oqg7tgjKhMN7KZUdKP
fgS/rJc5C2Pj8HBI1wbrSxxzYTbKjGNsXB+njZPYEWvARJjxS8iXRwGR+3UA
Fk5t28CsQytSXITnmUVIxakXeNyJmEbeF7ISytXTbMUaeSKao550tNLhI0zW
JyMKCMMyX2maMJi4rzbmaFYceAB/ZjFBPX6UZW1xHSALM2WDOPjdEq5eJEG7
8hh+rvdgr9A2d86CuK+H+eoVhClAUiVBYotvq1FboiPvMYc7xd5HLwdX0wrv
8cUJD8/dHCqEZYCaISCSFqwIpWYzqcFa1v40GDZG40lM8n4OaoPweNFR/1M5
p4jzCbBa63uHnSzQ7IVZkU36FoLQuk/T3MM9YhMv4xTd4a52VmLjwYO0acmw
cnlmPpgWoF4Vf7cVBJF7TD37y4qF5DIAk8HJ8WE/i1M/cx1f3FCjwL6RkVi1
KogeLqL/HY5IteTzK1Aj1teCd/Ddj1dXHnbMl0CGaBB+IhxJs+F1GOR6TKcg
aeQRNcarHHx0XjS7d1iNH42LV5yn6Lhcc6Q8qRlBX3hvkOnmBRbB8RnBl3mW
zVtoDoazLemQJizkesYFLk/PnOxHa8OEcFUbGi5wRwntUmE6u0CnaQ5mVRxM
Z33VHWhD0H4GmXFcc9kYDc0ZTRHiJLlfPjxww5Dgtq8kJbT5apz2L5MNHgKM
bzw3z84YL8LrwhcmwjSHxGnjjmha0arrGoTRueuYpWEXeWBsDL+OzdZle7mY
mGGcQWdb9X/PsoRnwro4OHlibTe4l9JgGN1rkrVhhEGWfNHTIOYWaU0kxiWs
sLU2mpcSuy3mojlj+7tgUAeHa+/ZacIsfWuKbmUp944Qfek63mYn23J0fNBw
geOgs7G/27tP5bwcHPI/XWXzlE0X2rd19tD4ZNP5bWvHGU7CfdeOi9E3akC8
NnaQ/rcRMOalXbS9PZpv8+RuuNOys8PXayveXPCz9RcJfDxW2ti9PAi80etj
v7QPpiFiU1j5sIue71aKLtaoKsDZEweyMpgsnSbVIuZkaq7wMIVAxIB/WRKj
ma7Wt1aiBEzY7cCZ/uyIgOhDmWyUAta3AG4EO0f4wOfWvFTdwBCvSWnTFrtt
gmmoRGreJgmkYA85BIaHMesnHzRHuSf28VjPSiyGH/t0/nFWug2RNx/fmieJ
4O3Pkp5UhrmQ0+fPJnWld2EPPBDfmwsNJS9LHpCZGS6w+nkHh7Kwe+cXAGRg
/3yu/sX0aZ3WHU679eFwSaFNzmfSyNHFk1bHuxvRzvUl0nbRLFNjWRGeiWl1
Gs7ZdaNZo8+nOFtKrtgY8HyK1iCzcV/j5vNlrv4VHMGCEzSnczs65XdZmDii
s/5jP+4Drp4xG+iOrTUU1XXDy/idZWMqhXTAx7JyHJfW/+b/nwcwy8xoi0Te
R3rjxw+Xd28//nGrqy1X9CRMyvj5XoqbHbzoupRKBKLCYWOoqudBxPmZxf3f
zWjNsq5peWRSJwv0ocest2UldyJJFe4JiMh5Supm0kMSAGn+vAnxQ5loqwrF
s4CV054d35hX+EYaM11g84ip0PKdv20Mv76d7Fdo8rYX9xS4Nukn0TR5287f
fvw//7N2jKesAbttfjvS3PH+HU2pQdBqrRrBVIJ7ZfNpziVRulKOa31Pmm6J
5pIvYT3b3jPsfF9HYgupZV32qQhe+zqXI7QpgbONCJrjb2ABjky+QI9rosvQ
T7SNqp6u2fYLOqj6lh3juKD/iUhNnS0ifpYp2RDsJmlRBdQMImawNBmWHDa6
PT07e//+HSO2q4uUy+LUpVVCMVu3tJwTpNfzFFQJnZmiYfSrcHQOG5csbNQa
NsczdXjLBXxxzSP0Zq3ckOQZVILKNDHcQu0IiM7s9poE1FYjOyaPw1nXXPvI
8VUXRxDHCZr52WSuVu5aZMgO8Qr6DJoxfxCWAu1A0SCawfYg4+A2gbt9jaDE
XtOqPFMh6qr9Uk4TgE1L6pZrMmNKLtfoKZ/o5ckssZW7NmiiTSfW7HuGc/Ed
kT6ieMN59Wun853tJi+IreyWCIrumyy22XmsCZbQOFj01V7XD2n4YDjShRNm
pxejj6Qcfvzu7Prj6O0paW4v3EhXzY17r/fDGxnx4OvGbNzaHBXxi9p2cAtz
z33r7PTi9HzHNx60xnswYGurzQ0rXNbU1zNER6PSQ0CBXmhP3Ol4kY80THNi
TsuvNZKKA9J8B3RVmQSsOgPH5ncVdeBtaW4cssapgRxxl0SMjBSgDU2bt60x
5GdtndYyOfA/xZBGIT4U3UliYsRPiHyWk2dvwZieuV352TWbUVgq/E17p3Bj
JgsgN8FOLwXckflmPOqGI0Q8fWKbcMhAp+dDqZvJeYgcQXdICT1Kyp4jKvbF
ThVpJdGuY1wyEbgGxZDkujPJL0Cn9m295T4riLkwXgrNfUfK/cQq6Lxw0GgI
PRQ7vrg01e0OBq2jtP4R9P9xHo9bsu2kr1YlyoVjctnKg7/rC86w1y1vrcns
FwHuDKKACCk+v4wVzQEpLa5aQxXDsVok3GlejGKPH6nx06BWk/P07pK0GFF9
bnq0Ug0QUkTIOSxGVD1JxxLx5nDFImEuwb3KKgRLbOa9QAJBgsU2+4Fr0lEk
FBmMaiKfna+erSuy2pokUmuE4rKxrM8We699YHWF9z1m5BWtKnNtPDbkNDA+
qQkddpwXrjkZWu/2WSDrax1JSsLHHYibngHO5PZ4sSTYhZVorFaP0yrxuiaI
+EnLjnvrnMEiUTTJYQQZqzX5WlSlGgdLisAR7+7Qea24sXPogZZjH22HCfLc
3bMovZ6tNO5lcdfxscp4ZRcFwrmCtqfxDuIX5l3Widc1JZSsTYzjsqR964BT
oFCR828+f74pJpPkPk9jNMljnEVxA9Be3xbPs3gOa+Xz5x/SOV0H8AtcsrFp
wxvOTcJ9wQ6YbsMv7ATLxI4Fh292DBBAFBzusYXd4zNOlvSkmOemN663ax1G
2re9JdcRDrlgA4UlVUVLOJ6WDz16HPiIVQ8r3MuLFF0BdzhJ03Aye0prhTcR
EWh4lAHisiUXiX8KFbk5NG+icylZ9UK8PeJzpE01Mrw1Lvl1+o6BIJimJbfj
LRZFJf1nEfmy4YmRX19pxSni4L7E4AAfxxybDjkopQw/J9xF3oMcD6+lg1Yh
rs+m7xJzNacRUQ909yTbh5u7srez3RdoaFSYNyQ2fbVtxcpWbUv2vqcytI/r
iSo9jkjqSgTpU3FEjJesSjgYyC1ZNAjugQTtMEuSFgacdvFM5KT9CGF0+HHE
NVw0KRoXFSo2jWygdRHTJ9YZAW4QQcwJsF5XvbroOb7tfw4btRvFdX9j/dQ6
DdjglIW8VckFlW2tWaqAHwqnEoOKJm4BV0+Vh0k2Sos/XdWgzUAXmy10l/bf
+ALTh7gd/Fpk2qp1SnHllprdGHapt6/vLhEnMY1dhkMIQexX1VrGHDgscIb9
EtVt1g3YrP/W6S/hAA1WgL3bGlnV/8K4os54pK013Upm6J+79bH9gkJWWVhZ
gXdgvKB/lIOdKPxcYKUODw4Gx9H2J/6vueHoaB+1+fJZQZ1PMICFjq84n051
WjqIBtIM54pzScQgNyq0BMs1b99kcXG2FnzV44/8zEd5pmpWYV+c3eDyG756
BehaZoEI8cY+8E4iO92Ntvz5bElu+CbLeK/ZONZVCiiZgQmHROY93Te9czvr
aWEuwSvE5xJ0e//ANtQumTEjBHImyw/EIn9EijHZB2gIqkEN4+snIkDmDAMK
at6LB5Ch4XtBNxHVQoIq2arjygS1BfpKE8ogAG1NsLr1Ye02+TqKqkz1cSeT
CbNehNC8lAyyaEcBII0p+e9njTwBmfn22dWOwOLIrjvoN+nXU/mfIPmq6m7p
Y9BLi6Orw11+1XCszLjuY6j84bz3wJZQSaB+Vc924Ug0q4Vs/9AvSPbbscap
AlLQqiTZ1IT42/ItiV3l3FhBN7Aj0lc9SpwnKeUoxg6K+fgoKod2H+K+C1fy
uQ2tzPKiVPiZtExwFTXbLmPUCBQhFQWHnIRlcUSQP5oicqlnUrrzazPUtcay
lXGdTMme9bhZYHvakiR90iyCMmFkw+jyxU/hMs5GfghJq6yeSeiSLe22rg4x
fRYrNtI4u9H63cuaip9jk+TkNKM4Q08EJDyvFEwc0Dn0wXjjPGwyYAnsfplm
cjSLhdql0uADpw76vcFjER8cR7/U48YVEdqq6h7uXG7wZn2IFt5YGYx2prJY
I6xROw+yQ7CxXlJaOmxhyX4obnF1n9TPiboGxZMhzmULAq9Js143JIcqEMoO
GlI78LY3kao0O12LgoxxmMwZ5zryS24fjLsy1WC6+MNjrY6HJSdLYbqc8Qqz
/hK2MUkUbxh5ichQ675AK5iXVSc0LTdWHEokOza44eYMYYt+2j9YFwVYaA0e
0bWzK6nauRJISbzu/He/b79/wJjwHdszx/sKdZ19ZUtK0xzRdKbi+l8jNbuY
tnWDl6lyDO5668BPSg/myVOmaPfYzu7QXv7zEjIhTaowp1khLqVwv6ynYgPG
9P09kTpox+a3o++ItdmNLHqGVdPVORMIB5tjaSMspk0FsGIFgNXnLVFxb8Qb
e0zVsZuBmulVigyt8XQwKk9l6HY2uHdsLYKK8mk0/Fs6YX83pF3821f4l5Vd
pqkJEMCbTb1+2/aaLe0SxUXb7rO0KLLDEwo2xvbtmJhyIJqNzvS1zBOJjIA9
EZco1JcrjtnbKAQxDIni/xr49dbTGhs5nYHhJeqH87vKJmhMJIe2yM1kvPbc
ATTgCacwmwP4Uti54+Iy5hFTmBDqCZBnLGJUxfXrsi0QaoyvcHEuz28MWT6Z
MJLAB8lBD+DcbKRyTrIC6BtIqsq1LmP7+v35zU7zMx6AeEHmytb524utcGlJ
O9L4t+yEFtxojs1wd1+TnrCmpoE8onthcM9m2VrcThaBRrbKG1THsQ2HDJSS
OCDl7R0nLhkTsDI1+2rAC4ENdvUg/O/RYHe4zzO01wb2mp29vTa01/Z3jyWB
Ds3JvlVfYmzWgl46GJp8Lxvt4AwgFDi5giC4PLj7TB69lty4akWEitx3jhFL
KMgk3smJJ8laS6hmaSC9A1hMbTEjpiLv2DSeo7BqPVn91J/w8fDwqyYc06K1
zDXy5xoO7chge22owXB9qJ2oo82M4NmbL+dWudZYN/dNg0PzKTXOlM+fYbr2
Rzf91zS7g0MBxKisn0UdHR2OeYfwM7Z25RyW/SmraD72tVl+LTrQnALRVP2e
5XF09+Hy9opkPbRoKFb8Nzq7S3OX+SLTgi+QHX+3Ie0VZwlI9drhwCYKesuF
RFnOoBL/MSMJYGG9YfQ9/ljHw5fG6rNFclU8/BLPXZ91+RtqhYXhn4uaZN01
bv4hp3DyuOOStNh96viRxMmw/ewPkZh5oD43NRGs9OXpu1Pf8/Gd8KRbLu4u
V1vcZxVe662Ls0j6wLBPpGPv2OkaeERIJOKZW64jkUBEuL5ExOJ3ohv7MVta
RF6CyjGTj3QDE5iEPzxi0ulueSJnCy8THgpHDDtHGNnI5m8OlQm5FGL1PmvN
RAMghYFpemHMRY5E5wtHAv1aPEl5Ozp1OBFSp+WFqfUmv3GQWvgWntpRIEuT
pavWcgJJcMG8sJdLr8Y/R29P2d1ERtvMRcGbqg23x6M7B4iAXJ8frK0UkHWl
p+PBgdkZSW85O/2WOwZhvVqAI3f61jemTXJN86fCefFs5pTClplZd8GRnNax
NTLBRNLzTDx/qx2Iy2LyBxjuVnvz45wcGeUkdC8Sd79qBNX+y/8F4M4eHZye
KYn7rydqRhXsQ76gLSjKk+hZ/NxZUTwaZqbIZgBPQ6C7EPPWggeklei10lBX
jLSJKyG04Bdnp6++LYtnWjd81nIue++Ox4nmAv1IbFIEmMkO2k5RdUes3zjI
OXtXdcTWb5NuAeUyl5SKt9enZ17rlWZOvonJhg/4TsJWkLSjAHmoCaRVzxJ/
cy0epMERxXU4vFRJ26yUsgrsgVel6kG0I3EkUlzVTfR37qLLaqG+xuFKzVpK
7/jzbmKwtSK/HQ2kVNRC9mgZITc0YK0VynbY6K3Tjqa6FtFYlCn6N0G98Rfk
i+lAL/Q+lmipFN7PWXMSLH3Tk9yal+pJgj+vzJNaCwCi6EKcGQa7NJGMCmOl
OzR4STTiPnEmJ8V4zl3uxjN7bAqDDCBgGcZVaubE+Y0X3O3sNwwFuI1udPP+
Zo9LTbljWevIl3Iqe+JCkxKRr37LhdAuHCbX9nk8dsOoUHSyLebMNve2xFzs
mt4mWbyKzjDw9uXt2U77BG+TOONoE+M//JbZaZdvO4AT125Wo9u7m8aLpe2u
zWfb5Jjn/g+rr6DIJp0bnOgvx+KqHR9P6f6L/Vgbvd0jNaz7BndWMdUNasAS
IMkCkpm3V0c/C6Iw8w8tKvRQAzW3xZjvXpuWBgxB4OoMGRcsVWZXNhvMSwVT
iFDhki98eaQ4z5wOB9vYuBxTkwx3dHC86zJJHUAcN/YbDHfRpTACc46ic9tR
Hr2QNrZSNxhK0KVL65AxtE3jjLRouwK1cR6HvG64O4TLLag0gYNRLRUB2uU6
cuV3WL1O9OL6+U0jTQg0LCxndJGWwLSXGmTwyaSbl8yBpbMmc0WMN1ktoEgE
HDcPvKBBdlom6EQ2ca4j6eTO3evSFtl2Ms4tv9q2eX5sDTt7OcR1y4EPKyXY
gUwCq0DeLPxcTOnG9QIXpos5OLwzfoq9K7WcQMabl/IvyzkcAXTWEujWW5UZ
4IVGvzvfY9rZFK1bh2PYwIgctHDQeDkNtqWXIy1P61sr9QscDYevbRugzemI
rI6XxTRlyvHatvGxx65KNzCz89qv6Cnx/eMSQ2SnCjDy59xCSmFxQAywrekz
imU5NgmjskwCwdUEujg6Hh5IKLnjI6ku6xhoqoO9XlrUPZl0IgrKH5x5NlKx
0VxSD6EkXAuNZMTLSZpYFE7HHA2VcFggbHZpNYs6bHFm05VFUWgEI0/Ydeox
np7EXtZ6d7rscstsuQEnTzBnhA2UQDtT2qDvaOuWtDaJFyzHDKCgiYSxAFbs
Fw1snkgkmn2BlbQKsxXSzS6fODVprW1sIZL59eqDCd4RYlGfcNjIAAEpG9Au
i+H3N3o1VeFnaLG3tJbQB8Xk9XPW19wKoTu1q01OBId2Pb2TgT1LSS4zc3bF
aGEXkxaA64J541KTFW21pVL5/h4bo3yeq8hVLVitFQyo6f49rUx2vrFG6CU0
sviggoZ2IOwNMzA6LZKwmb2JZR5CS5FiofB7JYtEDutaa655jCxMTNOB3kCK
8GKefEl4PIdaXUqkAVQNcqrt7G3Vf/OMm7g5K/+MIvGUlkXu5yI2EQRc1vCE
gYwsjpCXcw9OFkJTSSsZo5QpVqYpQNGJTxRWSU/K+mRZrHFWqMlzCg6jhykm
Rj6Hhb2VATMQl7onsTmnQlpkyAe78VIDbyuf6wxJiUE+MmJrpeFRq2cqsWuu
HrA8+l7Ous3YtJhnwfJqj3r3IaKb1iRt/mKgH8ePBr9QpolDiqXh0ti1/YKL
tsvkmuYCCt4F/hed7/syTbLkZhd9QtO1o3h5Q9uzs74JIl9h83EGBb/9N5uY
TYNyzeQMoKTA/kNmZ+LhzAa9XCzpXiBuJo8wIQKQE2lwIhlaav102HIw52LB
sSiXiZJG8DpGNkxss23u8AkT915cNtI0NLBUv05rKenO0lcpHXSlzMKjaPkS
+TgP4EUJV8FRwu663Ns3XodGNVwRGI7FM2Krro2XmcFmloDXCTCB46rciCiH
kwzZ9wZMxLawAaMGw9DAMgnR8iFxai6URC4vNuaoIhLqtkrzSccAl7mT/tsW
hsQas9qPhV++5N0hGs0AZOtgrCSTnJQW88agN7ezgUl5eh9ICaNKsXdH15G9
OnrmTYEp2bX0VBxsqcUfbCqslfJM5Gm4qLgGMUljYdVsssrjuUbwtrcC2YXf
tnZsRxENcJkMF4DtOje7Rk6lQYrpbBJ2Jpez4aKI0gvY1Au2S010pPTzxtnT
zVEX1wmVZbp4/k2D4XlB+257qisVMwdD1R9nssJ2I06g7jX+IK3HDzuJioaB
6iaz4F0fkeuLcIAOqRFt9QRFy3aUn8ykJFY0vrm0c40keDmlheEaRYZR06bS
iDPTIajYUmKkKI5XuE7rmvGHy+ITblaaRY0sRfY1cjDnLFBlmoxGOtrKnQq4
zo9aI6DxODfOUCpmxZr7GTq+pQqVNgZxEFPGKBc8S/gqBSUgdFUIsoZz9HNN
kAFzC8HENKG0AleNpThUX9bQ3bSrDY/MXX4UQSI1+qFYgL8scy8lCSS1iqyH
626jmcWhlfa1MlOtzMlF/ipG8+IJXZcuxL9K2o+rmOYfkZOuR+E8uHC4h7t5
TL99tcpqsebeQsZy45KfUCKuTWwiHzpeGa4FfGCYPtdInY9FC1g8DaLp5E8y
csLo9dIY23VxWn9StFXifx2z11bctYzUtdPT9DNVgBFpVmOSxoEH/sl+IC3B
JFGQf5E48h4f83h9Xgg72OZOHviKHyTyDX47R//NSDDtBrl096kkUfmpegx1
ybaqKQW3B5rfWi5zB3S5g7yNlX2+BS9ZXCjcE8ZlyHlzFtNS4i73MOyVMPf7
e4iG4T/7PBP860CCmgyoObq4FlD0t23f6vWO7I0hsFEhNdWMJtHr+EuNZkHz
/GCSKGtjMFackeUg68MsHME1wNQeljGp/3XCbfAqk5iq7Jrb4dWcptENW1A0
4e88gDLT8Mvg3zhsPGOg2oTxlqy9vxGf6EGjd7zpxuvIxCCBtpKLl+tkjm0z
jEtzQ1TRMjxpq8nI95xvoE5cD3vUCDLRH5zTPNb+PlI54uiILVHpKMS2Kmbk
ZpuKnYxaJeaWjoVzVN7kpxuHPYtmlmw9thjO342AHVqujHtodPsTR5f/URPk
pISypbg1lmxQDU76uPrB6kvLUe1gPY/r8cy0K7UtWILWNUZhKZ7SqmhGE9OX
v959bLDntsi/q8Hw89N3Fz36UGXb5ofruxu40DccJ5dz1bS+2bxL4mm0leTG
X7MVftU7xMPXy8yV/MUEaLpl1m07/Hnzw2WYAGwMG8N5aSlMSEflv5sJW3qx
KHKCDcS+cRaqWnA/fL1rXI2a9Wi0il7M8JwCaK7YB78qG2xv4iuRX0md3Fj6
b/0P/egm4/4ALcC+nJT9NzI/0/hyk0rhJa8GyHY0oJnMs2R/eEFTqVH8t395
x+mrt4niFvuQD5zZ2itxScwED3CzsC4kNWbFWyBZ19q2hNvomgi8mYmky3rp
v8au+7ZIxqhLZTUEMWzVugSZGn5c6SdmijHNgA9JzSleXj8tnw2IQFvC6flo
1New2TTn8OWdtpTXRuFx0LcjZkSbYvlpuLt7yP74bcmr5z6XHc22PdE2mIPD
3u7waLfr/hzsDgd7jb+H9u+j3sHx3l5/B4k7qUnG0KZ2LtQvYEF+/YXwWHVc
VQL94cqqO5oQj9bCpiWllptrK11MOhI42LEpfNHyMTSy1do8wWfuQK7Cw0N/
rhf4+Bj7urY7G7F3OmKTCOCrFlOKjQtNattCiDPkheztjpKSfggOjXwd21Os
N9W23notX3oTBpAh10NOdOs0VoLj1MXCVBgk6ElDVz+a6OfPbKwaTmDJHSmJ
nbUScnG8cRoyqRKM+FCJruMy/k0LLE33UZvDFLR+dQctYSKGOlw2kVVDlH/J
V6/v/xc/W+COUBNinAHI+/PV9ri1AlUPuHitm1iyqiFOpfp9nHSEm5AYTTn7
wffkmiOplNYbXf5kwdUPmr0YDbDQSPy6lt8DUYdz4EPYIXZabkIcMghD0CG2
bt6MtjSRwMsqwiz2j/ePUWOeypmcsj/W+Fab3dtNpr7zFBHHh2VtcFG89soO
gkiKq3PpCNSML3luSSmggDvrG+mIziASGAHB9JEaXTOv1YkXgpIkf1Xqw6cj
Y5xJAAjEUhroo27LbA1j9gW395nqpvCxkayjxNcRfG9s14TBvf4czVmmRhEX
3BTmAPGS02E4ToBKlFmM5GDxRltogQmasyFF6I/RqfFvuWx+wQrWJZOSN1Z7
WSPTJNsnIpyi7HpGljUTaM/rkqvlJLIWztpdFT4dG1gJRbE2mV+ovjbo/yhD
x9LRxqe87F7sSZoMP6cLIP+2vc84v+2LYqVbxnWQvO+3CfAOGNBtqIBugnvo
UvRZ+a7LZSX2KyoXJLbJTug4OjuVxRBaaXwkopzSao9zaGpAhqpnye0v8bri
YVakcU7TGNhphADCHHDoacYHZ1Z5PC8OktA1Dk7HcgnXqjT1El/g588/ZLTJ
vyzzB3rXrr5rVHBTCrqFDry2MmqETqoVfT9t2kTEcIn8oaovAeTMA+z3yEHl
MZmDE1TPMH6HK7iFww5pxV660xrXMpYsAoF8JuLK2LWuItF20jKhcnPiOdgs
ikMLozGgDwGTABXaEiC2EMJzx8dB0OOntUIz+OedDx+zWv3QaiN/5EzoFrO7
8cZ7QT9hK3UBqEU0w5GeAWsvb1lBdMgQpwnUSK+W1TkEG3nw1RgogLJ4qGML
Vk3wFduf4BOMULQyZlsDbWnCqF02AuDVwAku/8wmijCQgZb5mHoYbk+kbVfG
qzGStE1u+t0siMkYOBMLTXtO5iT6VaFiIJY07RtVRLfPr252FJ2IGZpO363A
Gu3Y8Ddgyp6SakJvXjj+aTId0DXPhCORhrws4RoANFShmIfKUw2N0EwYUswe
W7pXOs15K8U4H6ipQ7zdoNuYL27fGk5CCrE/q8h0RNUnSQl5AOKtHFJGRrEb
ICuW0MP9yMHm6ffAbKpdkAxIseZVPYUZDScFuRSXBn9N+ieZD+4ClYSr6BmI
mdbUK9BSnE6BrOC0M4CvTNCwsmgCZkVJWRalFim04Fn+v//3/9D50LFptBXh
FDBbo9wAkUk8v5+P/2F6w6zhf4gLZw3aBJh7DonMuFCs19+p/fHkqZAKBu0v
qDxfX9TTF0kwW6ERrKboomiNTbjQ0jmxmq32CMBFqaD00GG82jbLdRlhAs5I
U9jZNEI4CR5Tbe5+3sT+aN5hqvoqU/1tu4V5qAF9QVeWV0DdcZ0p5/EvvqOB
FIdlUrHKczn1B2f3o6ki5ZgTOwEBBaA4VIzOz4IiRsy5rjNVIqYADwD+z053
jbE/iEcxANBi3xdmabKfLKhO8Eno2crKwjNU566drH5mnjxoHZPrn+cIwaEW
C9Tj+o6wF5xHcqtg4hPIk2UG8tYvyKylcITTpaS1E3cQnydsUs3SRegZE7Qp
Xjyfvwl/hlGaVLUrLA+aiqv9325hIStB0zNVmnk9oDSKSKPGUerlaHKVyVoZ
kbCQpzjNmE0zueQrryvTGuzeH6MfGWjCSh4UcPPFoCBIUbFDVmNqxAoG3tgE
sKuFdDaHQ6nyBervMjGhVxBTWDr3VbZtl4HQ0pXVg8w1PYJCp4gJ4LUUBJtK
XFFQ82grAEk22O6mDp4hWPAdKt2aUuGtUb9IOadP8CJWxhlqY0VMgAZZR924
qv9wYaNMwAXIdEQOLHqazlvzkd1Q7RP+AehCEzcCXl9crmwOqqTW1YVB3RXn
x5Jb6mFE28eSLLJFPNzd3bNuag8wmjN8Cj8BhbEYGEhOOFTbufXc+KC1FwhN
a83s7XrYXya7l5gsbINWOMpI8TOkGFbfs7a/PL5pRShmkBQbb1XxNDFUQ+bP
6ZuLsx9vf7oY0appzENgmnb47Kgskh2fJS2d5NfPuRJISDuKLHTmBcRuExav
HMK9mwVovqGHWvpFNTOVNSDyokLk46t6by7tm1XIKIvjTkJYbk2WscoRbOOl
KDdhfznjU0WZNJbHkK17A89pWQluHcttH67VL5PU8DgCCpog3Dpl9We7LBuS
n5m46PWI2G7ihi8VLi4XUlPXb00oNh7Nk0xjFt1BqAmipOWISPmjF5RTFMaV
9Pus2Hzn2T82xwMnM8KlnS6iK17s7bPbq0r6tuAzONEOZQmIWNja3nkCDplW
opLym1My4aTuwa2dg+vWFFSGshKZWY0FH5UGyqD42oIGBsWovcYlOfdlQmEE
3PywmgTx3HkS2ZapxW+C6atfL6tj/lPsJtbApcoGnv/bKxpNuVdtD0QP65DU
31S8MI/gdfRnJX8gkW2ZZjbVUOWrJAwB0sVbVymFihF/NLnGx4NDYKtlxYNM
MH54AH+EzmFgzLSsUqw0TX0hhuaFrGjeWNcyFgiTZWkK5DZoFLkyJHumOHtK
o0EMUMbesR5YgL93rmiAfYU0iwQ0dMNtGpMaWQWWCGxd1D1nttsxMiYodaF7
aYzfVI1MXuTcAvUCEopVJryOZOuqMJuTPHeFFGdkiaYm5ZOr/yQ1E5PDLr/P
e1dwhJwFccWRsAVXlfb+bHSzY8qTjg93JV2V+/bEFcQO+LAyPbX3DcFKSQWZ
+mOjdDfi7ibo6YKyW8jW7AHaawulGXEunKvR7AGZg7Uf0zfZBqo/YM7GhWmV
CIXa6UfbtjSV9UTXDtg7MU55nSR5Gme9YtozzXAN++IqX3mXji2pS7W0N5xO
UaXd31HUIkQyUF7HmTcVBJ1NvXasmAfzkk89irj54dIUgc+W+cMA1TK6k1gE
/0TpHt5qfber6t32e6L6xcA7XZcibGICsoh1vMBebqFSqEKHeLE2LG4WEit5
a8XFiIfC2t/UdDykxbBNa/S7FqY0k7PCry/vrn33vOTyrelllWBPpA95oZxX
yOibyla0S38Anjt9ibdDFR9NTX483NtjAEeY7rDhfFHs1kxhuyYqDQVyT+l2
vuTlRa5s+9ucRPYH5x6OeNTRsQc8twWUdzkCO+L8Aeu2Q1rcNWOy4IuCvQKf
98CaOCLoUnW4J7D0M4FTURqZrwMjMIykP2lGVRf5YPo0tRGdD9qpLAP4ay5x
XfpDwpczRkelB2HKae16aqhd7R0DLNgsnkg8wCJuruEG+NBmXSAD5IWBk7F6
WuQ6I/MsPUCvvqrbSBTc9hHD9ulaCFi5Y5xOTJ3aKFd9trwXfv8N9b1vWm3r
e2VPhyU78RN4K3yRA7PDCjPvlBmDBg2J47EIWeMiRitVIxzNkWID94wWSyWe
AaxdMlChfADW5ew0nCkUb/8eUnZpGw2QBndNkxa62kXLelDEsSc6ClaZEWKt
+mGYXsJoUpJLSkyCEy2ylK1yw+KftOKi9soXTAA4BM6zBr2DVo9IDZ5IKS3p
NkDyNaqvV6ObJ8+ZFq5qeCkoIjXpORbWkXEnpUGsJ4Y8F8h9AefYwjICDZBL
DzgEOd4YDiFzsXl8HDzZoJPLyXZ4Jy3ot85sYQdVUPfssAM3myisd7Fri0EW
a3NYYg5RSHxlyQ5OozCdyE4GqoLdX8ucnPX9s8i9j8q1f27HFtE0NMGs8JAU
2ef1Cb2gQhWbdavJ17yDU/OqoJrFwPoxji1zk7lAnHLEFWdIkvvMyqschF/5
+vTPVv7wBHHAWDQyr++JfBB+paIn2FJDH67B+ytkv1m9c60UEGzzOfE5W8Eo
UtoM1pfQzkNFXzsVwJhxyotUGG+ZQqYqsmvD1DU+NZMYbvQwU+XcLJJh5wqy
8WhRTyNTS2sycZRCDo9fS6sMg03P7SsE5t18tBztQHiaFTJTDPJXC8kDWnoA
g4H7AuAgY5hVJKofOG+38/lkmUtKSDLhjLA4R85X0TnNkk908K6TLE8fi6cu
/fBE2iHpVehUTX/mJNPS6KZY4OK3REI/xJPlY7dzNiuRmET8/C1iBHO694wW
fUV8Dz0FMvpzCUsu+j7JoeBW3c45EXCS0QCzPPqOtCUywfDjE30XDfxLTJKy
27lAOPc2qWgRMxrz8+fPf/3v+OmnVT6GzfVrt/OmhA+UFPDoJs6k20C38xat
DKrorhrPiimpsw/005K+t6b30aZ1O5doNU9W7bJ6iuOShv6+oHlca3sB/fOW
zL0nOpX84u+X2J/or/+d/sMvvkIA5+KBZG1NfySkt9BDZNjx89fxQ066wQc6
G0mZETvBT+jzF50vHxP7x92smMv9xQzZqrQYNPt36fgxGtGCkSGR4895SZt8
+pSW8bzbuYmXWfShWCISRn8hIhZ9t6xJxNG9tyCeUZz9hf5Z8AeP4hXZgeav
D2lW4323BRyatAerLH2mP1fIoM0S+txuZ0RGSHS3JElDOzKq4TvLozcxcU1s
5F06jy5oXvTun8gSIwE9mq+qDATxU/pYA49i+TgrnvK0A/r8gOeITpYAk+mA
QtFCHK0X5BBrLNTluvotvUk/FIyHsO71zlZzVdEDnBzSbSa2ZG5BgdX1IGrK
bZwtZqRD0OJwlOKZmf24kKFU24mODoYHXaOrv4z6j45FZJ+YpxSKycLsx+Gx
81xVOq4P99UcuNfrcX4Azu+5plTb/D7zRulBQVd75dQWz4SjJnSaiD+fqdC7
sSUzNvGbOEFSchxGyspNXovH/KBm0dQqtCIRIZqLrveUmKfYH/6WFJKIWxrb
NPAx4k5R9Ecge6i3UuQYTAhTB41vAtgHMa9emtNhX6BOjiVaC/YDNyYxj7TX
gnIRhKS+aLXNH6MzHHlpg0McSpFgaLW8Zng7QnsC6mg4vdWVeRBtIe4MWLm8
q0J0IDPzHNA0goGxkiFOAe9p1W5GAtTbeeXkJu1xaUv9FWhcL2p2sAfhBVg0
tVE+eXVclTyACUir6WaI2Acq49ZaVzfvhADYJWbykHWGOkbwWjwhTvd3l82F
dqdawkMcu+XqK+gUDLzskku9Sa5h4WNYh4UvmU0xgjC48A5kYFJ6uVROVI79
g6Nffz3BBE+RoHSLxHGoEYKQ2I22OGe6d55WpvoTKa4TTiYBwvaWDI/DBptO
HENRqF59fBruuMQtZ6itrXtzoUWki2sNjWYDzYh2m/nfGj4fU4uC1cA/gXJv
qUCSDYKp4XMLu3+OjuU0tu8nrW2Y3+2ScvveYzYOo91bufLYRFiarVzX+qs2
xvn3B2haJqbzau/16kJ4eNJH4SR2Da8M7VpX4C15qaFO8vMVIzBVAHzsRk9k
Tg2Oh5abZyudideo7mfxPSSTj/MYisBHiZT9LB4N865o240Bt4DIJbgFGweh
a2qqQZLwDojpl+TGSJWaV+Pr3QEWfsVttAuEfziu3jXI6XPhmyig1lrGCD0v
H/wjF9CvHF8+y7nNBaLFfUy0wI47ybTR5BrBNQYzbk0z6ER9v121ka3WnkgT
Aeb1aObDmTux9ic72D0CsoDOiNs3sdwpi0VkmrH66SctSBkIjEj2iOHUGxtG
Gpt807MNgmT7hAj6+u7ytzT8EQZk7R0hQ+3eEsPRwPzDtX354vHfO7Es0wLK
xwuJUxDLO4l2e7d3d+a9QjfhDYHA7PrRCV+84agr28d7Lmwms6B1RgipF11t
ktFMgFdzRhq2i0N1irwsZEm0UlPIWqfNBEBbV2EpDB6z+cLxte+0mK6dLVrP
OC+OwfuSiXnlL1a/c4Xutsq4w3qcyWx6S8ZSUa46nb+lGU7/rg3lc2FKirAH
xoYV54jw4799xc9yMHdSxtO6ZzGYSBmEdnifVr3BgPMU1Bc5QaU355xIcFcV
8PtVFJgR/S8NuhsOenkx+i6aJskECms3Or29o/8Zy5wGb9p+Ap0x+im8a81k
6ktr6ZKJkM+awe4UCco+dks6pihI3ZojWxxhNa3K8FuuRIDTYINyaRUyc2Or
kom3OFUHqivrjZALCpMQLRfcZ8yUPvQYYnLDABOG2BsHcCMvQhuGjwcgnwaG
Dbe80WpCVy3yzM4kTs7ko6BtY9RkamnLw1guQWudfscc9FhqQwSvelFUde+f
l3FeL+dBB9S1reSsf3monTd8iQZ3j0GD0TWOBcjuQYJYHOa3auamdf/C0K9D
8h4l4/O09CjVOj76wX1yAx+nptUcNez9yFrRvKmB8+GL0zsKp3d67r/ZuUMY
CTSG+/kL4x2G4xn0kMveeZRD4y7jtEosertNzyR1A3Js8sXxD8LxP3wXXQF+
+syUc4MHdYOSRxFSvLdjUHi90lptp6du4uRnen/h3JuBxJK7PhSlr1UIXzfp
q0T6D6bKgnkyIiBramYwGVE3OVOlochGVpFtoPeLhH2K5wvD3TxNwkx9rdkL
SQPMm/QR4VTi92XVRCJV2qBKilx43Gfp/icFXRDI0jk3MDjWGsGGn33bKp9b
Or3K7W80idqLWxn9x3xYUw9SXS1JFkHhs043SMgUg0FCsF3ntDdBMH8ZTXSA
RhGlyXwOkkt1VsbHgUql9jQf69H3AgwS5QHaUmqK5oGKFE+07ckLx4Fblr8r
rFfJQrewPmoWCBEXbf9t+rp0vYxoUppGZ6Ofvnj29jh9SRba8XCLl9Zk9SyT
bhXxaJP18sWXDjudHh34X7ReyLF69hWYTUnbYW8revbS+oDM87w23ivrrOrN
Jwe9ahYPepbOvjSxASZ2jVigGEHG4WWdEGA8vf9g7bJnFWl7qn+DQt37rd6e
3n+qt6f3n6A6r23J1/grfJB+b4Smh8A4GBiCNXREfKXvofe7PQgIkYKsB8fD
Lx6pXVDubQJsh8kJRKhzFfeQiMCZd1rbazkS50KK/zBwG+OZ7zSJvGReqNCy
8X3F7ZBVHtRlwTvDHmUaXxkRHr9pAEXRITJ8rM8zNfAa3Cjk7Xv/A0lxgIn6
4jca0Ct2YJ/dmLptm9RhPDg9o4bmgEQkNra10Vm+ZVj9prncjxeDY28ql9wp
EUvEtljXul7Y2S9sreqlVVcxd5HzT9sNZxgbcfRsx/Pfiow3c+t3/j+rng4I
PyMBAA==
</rfc> </rfc>
 End of changes. 194 change blocks. 
3001 lines changed or deleted 767 lines changed or added

This html diff was produced by rfcdiff 1.48.