<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!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.8) -->
<?rfc rfcedstyle="yes"?>
<?rfc tocindent="yes"?>
<?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" number="9325" docName="draft-ietf-uta-rfc7525bis-11" category="bcp" consensus="true" submissionType="IETF" obsoletes="7525" updates="5288, 6066" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.14.0 -->
  <front>
    <title abbrev="TLS abbrev="TLS/DTLS Recommendations">Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-uta-rfc7525bis-11"/> name="RFC" value="9325"/>
    <seriesInfo name="BCP" value="195"/>
    <author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
      <organization>Intuit</organization>
      <address>
        <email>yaronf.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization>independent</organization>
      <address>
        <email>stpeter@stpeter.im</email>
      </address>
    </author>
    <author initials="T." surname="Fossati" fullname="Thomas Fossati">
      <organization>arm</organization>
      <organization>ARM Limited</organization>
      <address>
        <email>thomas.fossati@arm.com</email>
      </address>
    </author>
    <date year="2022" month="August" day="16"/> month="November"/>
    <area>Applications</area>
    <workgroup>UTA Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <workgroup>UTA</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

    <abstract>
      <t>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols, protocols and can also form the basis for secure transport protocols.  Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation.  This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases.</t>
      <t>An
      <t>RFC 7525, an earlier version of this document the TLS recommendations, was published as RFC 7525 when the industry was in the midst of its transition transitioning to TLS 1.2. Years later later, this transition is largely complete complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, the this document updates RFC RFCs 5288 and RFC 6066 in view of recent attacks.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide variety of application protocols, including HTTP <xref target="HTTP1.1"/> target="RFC9112"/> <xref target="HTTP2"/>, target="RFC9113"/>, IMAP <xref target="RFC9051"/>, POP Post Office Protocol (POP) <xref target="STD53"/>, SIP <xref target="RFC3261"/>, SMTP <xref target="RFC5321"/>, and XMPP the Extensible Messaging and Presence Protocol (XMPP) <xref target="RFC6120"/>.  Such protocols use both the TLS or DTLS handshake protocol and the TLS or DTLS record layer.

<!-- [rfced] FYI: We've replaced hyphens in the following paragraph with parentheses to add clarity to the sentence. Please let us know if this is not preferred.

Original:
   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"/> [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.

Updated:
   Although the TLS handshake protocol can also be used with different
   record layers to define secure transport protocols (the most prominent example
   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 for this document; nevertheless, many of the recommendations here might apply insofar as such protocols use the TLS handshake protocol.</t>

      <t>Over the years leading to 2015, the industry had witnessed serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation.  For instance, both the AES-CBC <xref target="RFC3602"/> and RC4 <xref target="RFC7465"/> encryption algorithms, which together were once the most widely deployed ciphers, were attacked in the context of TLS.  Detailed information about the attacks known prior to 2015 is provided in a companion document (<xref target="RFC7457"/>) <xref target="RFC7457"/> to the previous version of this specification, the TLS recommendations <xref target="RFC7525"/>, which will help the reader understand the rationale behind the recommendations provided here. That document has not been updated in concert with this one; instead, newer attacks are described in this document, as are mitigations for those attacks.</t>
      <t>The TLS community reacted to the attacks described in <xref target="RFC7457"/> in several ways:</t>
      <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"/>, target="RFC6347"/> along with earlier protocol versions. This guidance is included in the original <xref target="RFC7525"/> and mostly retained in this revised version; note that this guidance was mostly adopted by the industry since the publication of RFC 7525 in 2015.</li>
        <li>Versions of TLS earlier than 1.2 were deprecated <xref target="RFC8996"/>.</li>
        <li>Version 1.3 of TLS <xref target="RFC8446"/> was released, followed by version 1.3 of DTLS <xref target="RFC9147"/>; these versions largely mitigate or resolve the described attacks.</li>
      </ul>
      <t>Those who implement and deploy TLS and TLS-based protocols need guidance on how they can be used securely.  This document provides guidance for deployed services as well as for software implementations, assuming the implementer expects their code to be deployed in the environments defined in <xref target="applicability"/>. Concerning deployment, this document targets a wide audience -- namely, audience, namely 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 various mechanisms, their technical maturity and interoperability, and their prevalence in implementations at the time of writing.  Unless it is explicitly called out that a recommendation applies to TLS alone or to DTLS alone, each recommendation applies to both TLS and DTLS.</t>
      <t>This document attempts to minimize new guidance to TLS 1.2 implementations, and the overall approach is to encourage systems to move to TLS 1.3. However, 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 cannot address 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, although it is known that the creation of quantum computers will have a significant 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 too early to make recommendations; once the relevant specifications are standardized in the IETF or elsewhere, this document should be updated to reflect best practices at that time.</t>
      <t>As noted, the TLS 1.3 specification resolves many of the vulnerabilities listed in this document. A system that deploys TLS 1.3 should have fewer vulnerabilities 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 majority of implementation and deployment scenarios, with the exception of unauthenticated TLS (see <xref target="applicability"/>). Other specifications that reference this document can have stricter requirements related to one or more aspects of the protocol, based on their particular circumstances (e.g., for use with a particular specific 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 strongest security possible. For example, based on knowledge about the deployed base for an existing application protocol and a cost-benefit analysis regarding security strength vs. interoperability, a given service provider might decide to disable TLS 1.2 entirely and offer only TLS 1.3.</t>
      <t>Community knowledge about the strength of various algorithms and feasible attacks can change quickly, and experience shows that a Best Current Practice (BCP) document about security is a point-in-time statement.  Readers are advised 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 target="Boeck2016"/> attack. See <xref target="nonce-reuse"/> for the details.</t>
      <t>This document updates <xref target="RFC6066"/> in view of the <xref target="ALPACA"/> attack.  See <xref target="sni"/> for the details.</t>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
      <t>A number of security-related terms in this document are used in the sense defined in <xref target="RFC4949"/>,
including "attack", "authentication", "certificate", "cipher", "compromise", "confidentiality",
"credential", "data integrity", "encryption", "forward secrecy", "key", "key length", "self-signed certificate",
"strength", and "strong".</t>

<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as shown
here.</t>
    </section>
    <section anchor="rec">
      <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>
      <section anchor="protocol-versions">
        <name>Protocol Versions</name>
        <section anchor="rec-versions">
          <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 are the recommendations concerning TLS/SSL protocol versions:</t>
          <ul spacing="normal">
            <li>
              <t>Implementations <bcp14>MUST NOT</bcp14> negotiate SSL version 2.  </t>
              <t>
Rationale: Today, SSLv2 is considered insecure <xref target="RFC6176"/>.</t>
            </li>
            <li>
              <t>Implementations <bcp14>MUST NOT</bcp14> negotiate SSL version 3.  </t>
              <t>
Rationale: SSLv3 <xref target="RFC6101"/> was an improvement over SSLv2 and plugged some significant security holes but did not support strong cipher suites. SSLv3 does not support TLS extensions, some of which (e.g., renegotiation_info <xref target="RFC5746"/>) are security-critical. security critical.  In addition, with the emergence of the POODLE Padding Oracle On Downgraded Legacy Encryption (POODLE) attack <xref target="POODLE"/>, SSLv3 is now widely recognized as fundamentally insecure.  See <xref target="DEP-SSLv3"/> target="RFC7568"/> for further details.</t>
            </li>

            <li>
              <t>Implementations <bcp14>MUST NOT</bcp14> negotiate TLS version 1.0 <xref target="RFC2246"/>.  </t>
              <t>
Rationale: TLS 1.0 (published in 1999) does not support many modern, strong cipher suites. In addition, TLS 1.0 lacks a per-record Initialization Vector (IV) for CBC-based cipher suites based on cipher block chaining (CBC) and does not warn against common padding errors. This and other recommendations in this section are in line with <xref target="RFC8996"/>.</t>
            </li>
            <li>
              <t>Implementations <bcp14>MUST NOT</bcp14> negotiate TLS version 1.1 <xref target="RFC4346"/>.  </t>
              <t>
Rationale: TLS 1.1 (published in 2006) is a security improvement over TLS 1.0 but still does not support certain stronger cipher suites that were introduced with the standardization of TLS 1.2 in 2008, including the cipher suites recommended for TLS 1.2 by this document (see <xref target="rec-cipher"/> below).</t>
            </li>
            <li>
              <t>Implementations <bcp14>MUST</bcp14> support TLS 1.2 <xref target="RFC5246"/>.  </t>
              <t>
Rationale: TLS 1.2 is implemented and deployed more widely than TLS 1.3 at this time and, time, and when the recommendations in this document are followed to mitigate known attacks, the use of TLS 1.2 is as safe as the use of TLS 1.3.  In most application protocols that re-use reuse TLS and DTLS, there is no immediate need to migrate solely to TLS 1.3 and proactively deprecate TLS 1.2, especially 1.3. Indeed, because the existence of large numbers of many application clients are dependent on TLS libraries or operating systems that do not yet support TLS 1.3 1.3, proactively deprecating TLS 1.2 would introduce significant interoperability 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>
            </li>
            <li>
              <t>Implementations <bcp14>SHOULD</bcp14> support TLS 1.3 <xref target="RFC8446"/> and, if implemented, <bcp14>MUST</bcp14> prefer to negotiate TLS 1.3 over earlier versions of TLS.  </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 recommendations regarding TLS 1.2 specified in this document.</t>
            </li>
            <li>
              <t>New transport protocols that integrate the TLS/DTLS handshake protocol and/or record layer <bcp14>MUST</bcp14> use only TLS/DTLS 1.3 (for instance, QUIC <xref target="RFC9001"/> took this approach). New application protocols that employ TLS/DTLS for channel or session encryption <bcp14>MUST</bcp14> integrate with both TLS/DTLS versions 1.2 and 1.3; nevertheless, in rare cases where broad interoperability is not a concern, application protocol designers <bcp14>MAY</bcp14> choose to forego TLS 1.2.  </t>
              <t>
Rationale: Secure deployment of TLS 1.3 is significantly easier and less error-prone error prone than secure deployment of TLS 1.2. When designing a new secure transport protocol such as QUIC, there is no reason to support TLS 1.2. By contrast, new application protocols that re-use reuse TLS <bcp14>MAY</bcp14> need to support both TLS 1.3 and TLS 1.2 in order to take advantage of underlying library or operating system support for both versions.</t>
            </li>
          </ul>
          <t>This BCP applies to TLS 1.3, TLS 1.2, and earlier versions. It is not safe for readers to assume that the recommendations in this BCP apply to any future version of TLS.</t>
        </section>
        <section anchor="dtls-protocol-versions">
          <name>DTLS Protocol Versions</name>

          <t>DTLS, an adaptation of TLS for UDP datagrams, was introduced when TLS 1.1 was published.  The following are the recommendations with respect to DTLS:</t>
          <ul spacing="normal">
            <li>
              <t>Implementations <bcp14>MUST NOT</bcp14> negotiate DTLS version 1.0 <xref target="RFC4347"/>.  </t>
              <t>
Version 1.0 of DTLS correlates to version 1.1 of TLS (see above).</t>
            </li>
            <li>
              <t>Implementations <bcp14>MUST</bcp14> support DTLS 1.2 <xref target="RFC6347"/>.  </t>
              <t>
Version 1.2 of DTLS correlates to version 1.2 of TLS (see above).
(There is no version 1.1 of DTLS.)</t>
            </li>
            <li>
              <t>Implementations <bcp14>SHOULD</bcp14> support DTLS 1.3 <xref target="RFC9147"/> and, if implemented, <bcp14>MUST</bcp14> prefer to negotiate DTLS version 1.3 over earlier versions of DTLS.  </t>
              <t>
Version 1.3 of DTLS correlates to version 1.3 of TLS (see above).</t>
            </li>
          </ul>
        </section>
        <section anchor="rec-fallback">
          <name>Fallback to Lower Versions</name>
          <t>TLS/DTLS 1.2 clients <bcp14>MUST NOT</bcp14> fall back to earlier TLS versions, since those versions have been deprecated <xref target="RFC8996"/>. We note that as As a result of that, result, the downgrade-protection SCSV (Signaling Signaling Cipher Suite Value) Value (SCSV) mechanism <xref target="RFC7507"/> is no longer needed for clients. In addition, TLS 1.3 implements a new version negotiation version-negotiation mechanism.</t>
        </section>
      </section>
      <section anchor="strict-tls">
        <name>Strict TLS</name>
        <t>The following recommendations are provided to help prevent SSL Stripping "SSL Stripping" and STARTTLS Command Injection command injection (attacks that are summarized in <xref target="RFC7457"/>):</t>
        <ul spacing="normal">
          <li>Many existing application protocols were designed before the use of TLS became common. These protocols typically support TLS in one of two ways: either 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-protected TLS protected (e.g., STARTTLS, which is used in protocols such as IMAP and XMPP). Regardless 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, upgrade method, implementations <bcp14>MUST</bcp14> provide a way for administrators to set a strict local policy that forbids use of plaintext in the absence of a negotiated TLS channel, and administrators <bcp14>MUST</bcp14> use this policy.</li>
          <li>HTTP client and server implementations intended for use in the World Wide Web (see
<xref target="applicability"/>) <bcp14>MUST</bcp14> support the HTTP Strict Transport Security (HSTS) header
field <xref target="RFC6797"/>, target="RFC6797"/> so that Web web servers can advertise that they are willing to
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
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" sectionFormat="of" target="RFC6797"/>).
Similar technologies exist for non-HTTP application protocols, such as MTA-STS Mail Transfer Agent Strict Transport Security (MTA-STS) for
mail transfer agents <xref target="RFC8461"/> and methods based on DNS-Based Authentication of
Named Entities (DANE) <xref target="RFC6698"/> for SMTP <xref target="DANE-SMTP"/> target="RFC7672"/> and XMPP <xref target="RFC7712"/>.</li>
        </ul>
        <t>Rationale: Combining unprotected and TLS-protected communication opens the way to SSL Stripping and similar attacks, since an initial part of the communication is not integrity protected and therefore can be manipulated by an attacker whose goal is to keep the communication in the clear.</t>
      </section>

      <section anchor="compression">
        <name>Compression</name>
        <t anchor="rec-compress">In order to help prevent compression-related attacks (summarized in <xref section="2.6" sectionFormat="of" target="RFC7457"/>), target="RFC7457"/>) when using TLS 1.2 1.2, implementations and deployments <bcp14>SHOULD NOT</bcp14> support
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 proven not to be open to such attacks,
however attacks.
However, even in this case case, extreme caution is warranted because of the potential for
	future attacks related to TLS compression. More specifically, the HTTP protocol is known to be vulnerable to compression-related attacks. Note: this (This recommendation applies to TLS 1.2 only, because compression has been removed from TLS 1.3.</t> 1.3.)</t>

<t>Rationale: TLS compression has been subject to security attacks, attacks such as the CRIME Compression Ratio Info-leak Made Easy (CRIME) attack.</t>
        <t>Implementers should note that compression at higher protocol levels can allow an active attacker to extract cleartext information from the connection. The BREACH Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (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">
          <name> Certificate
          <name>Certificate Compression</name>
          <t>Certificate chains often take up the majority most of the bytes transmitted during
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="RFC9191"/> for further suggestions):</t>
          <ul spacing="normal">
            <li>Limit the number of names or extensions;</li> extensions.</li>
            <li>Use keys with small public key representations, like ECDSA;</li> the Elliptic Curve Digital Signature Algorithm (ECDSA).</li>
            <li>Use certificate compression.</li>
          </ul>

          <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
considerations associated with its use.  For the avoidance of doubt, CRIME-style attacks on TLS
compression do not apply to certificate compression.</t>
          <t>Due to the strong likelihood of middlebox interference,
RFC8879-style
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
be used, but it is not supported widely enough supported to be considered a practical
alternative.</t>
        </section>
      </section>
      <section anchor="rec-resume">
        <name>TLS Session Resumption</name>
        <t>Session resumption drastically reduces the number of full TLS handshakes and thus is an essential
performance feature for most deployments.</t>
        <t>Stateless session resumption with session tickets is a popular strategy. For TLS 1.2, it is specified in
<xref target="RFC5077"/>.  For TLS 1.3, a more secure PSK-based 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="Springall16"/> 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>
be authenticated and encrypted to prevent modification or eavesdropping by an attacker.
Further recommendations apply to session tickets:</t>
        <ul spacing="normal">
          <li>A strong cipher <bcp14>MUST</bcp14> be used when encrypting the ticket (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 keys <bcp14>MUST</bcp14> be destroyed at the end of the validity period.</li>
          <li>For similar reasons, session ticket validity <bcp14>MUST</bcp14> be 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 session. Thus, to prevent an attack where the server's ticket-encryption key is stolen 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 that are too old, e.g. e.g., sessions that have been open longer than two ticket-encryption key rotation periods.</li>
        </ul>
        <t>Rationale: session Session resumption is another kind of TLS handshake, handshake and therefore 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. i.e., that prevent an attacker who gains momentary access to the TLS endpoint (either client or server) and its secrets from reading either past or future communication. 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
that is periodically resumed. <xref section="2.2" sectionFormat="of" target="RFC8446"/> recommends that clients <bcp14>SHOULD</bcp14>
send a "key_share" when initiating session resumption.
In order to gain forward secrecy, this document recommends that server implementations <bcp14>SHOULD</bcp14>
select the "psk_dhe_ke" PSK key exchange mode and
respond with a "key_share", "key_share" to complete an ECDHE Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) exchange on each session resumption.
As a more performant alternative, server implementations <bcp14>MAY</bcp14> refrain from responding with a
"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
majority of session resumption requests occurring (which would occur within a few hours, hours) while still ensuring
forward secrecy for longer-lived sessions.</t>
        <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>
      </section>
      <section anchor="renegotiation-in-tls-12">
        <name>Renegotiation in TLS 1.2</name>
        <t>The recommendations in this section apply to TLS 1.2 only, because renegotiation has been removed from TLS 1.3.</t>
        <t>Renegotiation in TLS 1.2 is a handshake that establishes new cryptographic parameters for an existing session. The mechanism existed in TLS 1.2 and in earlier protocol versions, versions and was improved following several major attacks including a plaintext injection attack, CVE-2009-3555 <xref target="CVE"/>.</t>
        <t>TLS 1.2 clients and servers <bcp14>MUST</bcp14> implement the <tt>renegotiation_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 client <bcp14>MUST</bcp14> generate a fatal <tt>handshake_failure</tt> alert prior to terminating the connection.</t>
        <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>, <tt>renegotiation_info</tt> regardless of whether either endpoint actually implements renegotiation.  See also <xref section="4.1" sectionFormat="of" target="RFC5746"/>.</t>
        <t>A related attack resulting from TLS session parameters not being properly authenticated is a Triple Handshake <xref target="triple-handshake"/>. target="Triple-Handshake"/>. To address this attack, TLS 1.2 implementations <bcp14>MUST</bcp14> support the <tt>extended_master_secret</tt> extension defined in <xref target="RFC7627"/>.</t>
      </section>

      <section anchor="post-handshake-authentication">
        <name>Post-Handshake Authentication</name>
        <t>Renegotiation in TLS 1.2 was (partially) replaced in TLS 1.3 by separate 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"/>), target="RFC9113"/>), 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" section="9.2.3" sectionFormat="of" target="HTTP2"/>.</t> target="RFC9113"/>.</t>
      </section>

      <section anchor="sni">
        <name>Server Name Indication (SNI)</name>
        <t>TLS implementations <bcp14>MUST</bcp14> support the Server Name Indication (SNI) extension defined in <xref section="3" sectionFormat="of" target="RFC6066"/> 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 (called Encrypted Client Hello) is being worked on in the TLS Working Group <xref target="I-D.ietf-tls-esni"/>.  Once that method has been standardized and widely implemented, it will likely be appropriate to recommend its usage in a future version of this BCP.</t>
        <t>Rationale: SNI supports deployment of multiple TLS-protected virtual servers on a single
      address, and therefore enables fine-grained security for these virtual servers,
      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
      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
recognize the presented server name <bcp14>SHOULD NOT</bcp14> continue the handshake and
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"/>: "If target="RFC6066"/>, which stated:</t>

<blockquote>If the server understood the
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
<tt>unrecognized_name(112)</tt> alert or continue the handshake." handshake.</blockquote>

<t>
Clients <bcp14>SHOULD</bcp14> abort the handshake if the server acknowledges the SNI extension, extension but presents a certificate with a different hostname than the one sent by the client.</t>
      </section>
      <section anchor="rec-alpn">
        <name>Application-Layer Protocol Negotiation (ALPN)</name>
        <t>TLS implementations (both client- and server-side) <bcp14>MUST</bcp14> support the
Application-Layer Protocol Negotiation (ALPN) extension <xref target="RFC7301"/>.</t>
        <t>In order to prevent "cross-protocol" attacks resulting from failure to ensure
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
behavior prescribed in <xref section="3.2" sectionFormat="of" target="RFC7301"/>: "In
</t>

<blockquote> In the event that the
server supports no protocols that the client advertises, then the server <bcp14>SHALL</bcp14>
respond with a fatal <tt>no_application_protocol</tt> alert." '<tt>no_application_protocol</tt>' alert.</blockquote>

<t>
Clients <bcp14>SHOULD</bcp14>
abort the handshake if the server acknowledges the ALPN extension, extension
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>
        <t>Protocol developers are strongly encouraged to register an ALPN identifier
for their protocols. This applies both to new protocols and to well-established
protocols; however, because the latter might have a large deployed base,
strict enforcement of ALPN usage may not be feasible when an ALPN
identifier is registered for a well-established protocol.</t>
      </section>
      <section anchor="multi-server-deployment">
        <name>Multi-Server Deployment</name>
        <t>Deployments that involve multiple servers or services can increase the 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
protocols (e.g., HTTP and IMAP). In this case case, an attacker might be able to direct
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
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
undesirable effects (see <xref target="ALPACA"/> for more detailed information about this class
of attacks). To mitigate this threat, service providers <bcp14>SHOULD</bcp14> deploy ALPN (see
<xref target="rec-alpn"/> immediately above) and target="rec-alpn"/>). In addition, to the extent possible possible, they <bcp14>SHOULD</bcp14> ensure that multiple
services handling the same domain name provide equivalent levels of security
(including both the TLS configuration and protections against compromise of
server credentials) that are consistent with the recommendations in this document.</li> document; such measures <bcp14>SHOULD</bcp14> include the handling of configurations across multiple TLS servers and protections against compromise of credentials held by those servers.</li>
          <li>Deployments in which multiple servers providing the same service have different
TLS configurations. In this case, an attacker might be able to direct a connecting
endpoint to a server with a TLS configuration that is more easily exploitable (see
<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 providing the same
service provide equivalent levels of security that are consistent with the
recommendations in this document.</li>
        </ol>
      </section>
      <section anchor="zero-round-trip-time-0-rtt-data-in-tls-13">
        <name>Zero Round Trip 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 latency
when TLS connections are resumed, at the potential cost of certain security properties.
As a result, it requires special attention from implementers on both
the server and the client side. Typically, this extends to both the
TLS library as well as protocol layers above it.</t>
        <t>For use in HTTP-over-TLS, readers are referred HTTP over TLS, refer to <xref target="RFC8470"/> for guidance.</t>
        <t>For QUIC-on-TLS, QUIC on TLS, refer to <xref section="9.2" sectionFormat="of" target="RFC9001"/>.</t>

        <t>For other protocols, generic guidance is given in Section <xref target="RFC8446" section="8" sectionFormat="bare"/> and Appendix <xref target="RFC8446" section="E.5" sectionFormat="bare"/> of <xref target="RFC8446"/>.
To paraphrase Appendix E.5, <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 clarify
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 protocol.</t>
      </section>
    </section>
    <section anchor="detail">
      <name>Recommendations: Cipher Suites</name>
      <t>TLS 1.2 provided considerable flexibility in the selection of cipher suites. Unfortunately, the security of some of these cipher suites has degraded over 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">
        <name>General Guidelines</name>
        <t>Cryptographic algorithms weaken over time as cryptanalysis improves: algorithms that were once considered strong become weak. Consequently, they cipher suites using weak algorithms need to be phased out over time and replaced with more secure cipher suites. This helps to ensure that the desired security properties still hold. SSL/TLS has been in existence for almost well over 20 years and many of the cipher suites that have been recommended in various versions of SSL/TLS are now considered weak or at least not as strong as desired. Therefore, this section modernizes the recommendations concerning cipher suite selection.</t>
        <ul spacing="normal">
          <li>
            <t>Implementations <bcp14>MUST NOT</bcp14> negotiate the cipher suites with NULL encryption.  </t>
            <t>
Rationale: The NULL cipher suites do not encrypt traffic and
             so provide no confidentiality services. Any entity in the
             network with access to the connection can view the plaintext
             of contents being exchanged by the client and server.<br/> server. Nevertheless, this document does not discourage software from
             implementing NULL cipher suites, since they can be useful for
             testing and debugging.</t>
          </li>
          <li>
            <t>Implementations <bcp14>MUST NOT</bcp14> negotiate RC4 cipher suites.  </t>
            <t>
Rationale: The RC4 stream cipher has a variety of cryptographic
             weaknesses, as documented in <xref target="RFC7465"/>.
     Note that DTLS specifically forbids the use of RC4 already.</t>
          </li>
          <li>
            <t>Implementations <bcp14>MUST NOT</bcp14> negotiate cipher suites offering less
             than 112 bits of security, including so-called "export-level"
             encryption (which provide provides 40 or 56 bits of security).  </t>
            <t>
Rationale: Based on <xref target="RFC3766"/>, at least 112 bits
             of security is needed.  40-bit and 56-bit security (found in
             so-called "export ciphers") are considered
             insecure today.</t>
          </li>
          <li>
            <t>Implementations <bcp14>SHOULD NOT</bcp14> negotiate cipher suites that use
             algorithms offering less than 128 bits of security.  </t>
            <t>
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
             expected that their useful lifespan is short enough to justify
             supporting stronger cipher suites at this time.  128-bit ciphers
             are expected to remain secure for at least several years, years and
             256-bit ciphers until the next fundamental technology
             breakthrough.  Note that, because of so-called
             "meet-in-the-middle" attacks <xref target="Multiple-Encryption"/>,
             some legacy cipher suites (e.g., 168-bit 3DES) Triple DES (3DES)) have an effective
             key length that is smaller than their nominal key length (112
             bits in the case of 3DES).  Such cipher suites should be
             evaluated according to their effective key length.</t>
          </li>
          <li>
            <t>Implementations <bcp14>SHOULD NOT</bcp14> negotiate cipher suites based on
             RSA key transport, a.k.a. "static RSA".  </t>
            <t>
Rationale: These cipher suites, which have assigned values starting
             with the string "TLS_RSA_WITH_*", have several drawbacks, especially
             the fact that they do not support forward secrecy.</t>
          </li>
          <li>
            <t>Implementations <bcp14>SHOULD NOT</bcp14> negotiate cipher suites based on
             non-ephemeral (static) finite-field Diffie-Hellman (DH) key agreement. Similarly, implementations <bcp14>SHOULD NOT</bcp14> negotiate non-ephemeral elliptic curve Elliptic Curve DH key agreement.  </t>
            <t>
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, secrecy and are subject to invalid curve attacks <xref target="Jager2015"/>.</t>
          </li>
          <li>
            <t>Implementations <bcp14>MUST</bcp14> support and prefer to negotiate cipher suites
             offering forward secrecy.  However, TLS 1.2 implementations <bcp14>SHOULD NOT</bcp14> negotiate
             cipher suites based on ephemeral finite-field Diffie-Hellman key
             agreement (i.e., "TLS_DHE_*" suites).  This is justified by the known fragility
             of the construction (see <xref target="RACCOON"/>) and the limitation around
             negotiation --
             negotiation, including using <xref target="RFC7919"/>, which has seen very
             limited uptake.  </t>
            <t>
Rationale: Forward secrecy (sometimes called "perfect forward
             secrecy") prevents the recovery of information that was encrypted
             with older session keys, thus limiting how far back in time data
             can be decrypted when an attack is successful.  See Sections <xref target="sec-pfs"/> target="sec-pfs" format="counter"/>
             and <xref target="sec-dhe"/> target="sec-dhe" format="counter"/> for a detailed discussion.</t>
          </li>
        </ul>
      </section>

      <section anchor="rec-cipher">
        <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>
        <ul spacing="normal">
          <li>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</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_256_GCM_SHA384</li>
        </ul>
        <t>As these are authenticated encryption Authenticated Encryption with Associated Data (AEAD) algorithms <xref target="RFC5116"/>, these cipher suites are supported only in TLS 1.2 and not in earlier protocol versions.</t>
        <t>Typically, in order to prefer these suites, the order of suites needs to be explicitly configured in server software.  It would be ideal if server software implementations were to prefer these suites by default.</t>
        <t>Some devices have hardware support for AES-CCM AES Counter Mode with CBC-MAC (AES-CCM) but not AES-GCM, AES Galois/Counter Mode (AES-GCM), so they are unable to follow the foregoing recommendations regarding cipher suites.  There are even devices 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.,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) <bcp14>SHOULD NOT</bcp14> be used unless the
encrypt_then_mac
<tt>encrypt_then_mac</tt> extension <xref target="RFC7366"/> is also successfully negotiated.
This requirement applies to both client and server implementations.</t>
        <t>When using ECDSA signatures for authentication of TLS peers, it is <bcp14>RECOMMENDED</bcp14> that implementations use the NIST curve P-256. In addition, to avoid predictable or repeated nonces (that would allow revealing (which could reveal the long term long-term signing key), it is <bcp14>RECOMMENDED</bcp14> that implementations implement "deterministic 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
side-channel and fault injection attacks precisely because of their
determinism.  While most fault injection attacks described in the literature assume
physical access to the device (and therefore are more relevant in IoT Internet of Things (IoT)
deployments with poor or non-existent physical security), some can be carried
out remotely <xref target="Poddebniak2017"/>, e.g., as Rowhammer <xref target="Kim2014"/> variants.  In
deployments where side-channel attacks and fault injection attacks are a
concern, implementation strategies combining both randomness and determinism
(for example, as described in <xref target="I-D.mattsson-cfrg-det-sigs-with-noise"/>) can
be used to avoid the risk of successful extraction of the signing key.</t>
        <section anchor="detail-neg">
          <name>Implementation Details</name>
          <t>Clients <bcp14>SHOULD</bcp14> include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the first proposal to any server.  Servers <bcp14>MUST</bcp14> prefer this cipher suite over weaker cipher suites whenever it is proposed, even if it is not the first proposal.  Clients are of course free to offer stronger cipher suites, e.g., using AES-256; when they do, the server <bcp14>SHOULD</bcp14> prefer the stronger cipher suite unless there are compelling reasons (e.g., seriously degraded performance) to choose otherwise.</t>
          <t>The previous version of this document the TLS recommendations <xref target="RFC7525"/> implicitly allowed the old RFC 5246 mandatory-to-implement cipher suite, TLS_RSA_WITH_AES_128_CBC_SHA. At the time of writing, this cipher suite does not provide additional interoperability, except with very old clients. As with other cipher suites that do not provide forward secrecy, implementations <bcp14>SHOULD NOT</bcp14> support this cipher suite. Other application protocols specify other cipher suites as mandatory to implement (MTI).</t>
          <t><xref target="RFC8422"/> allows clients and servers to negotiate ECDH parameters (curves). Both clients and servers <bcp14>SHOULD</bcp14> include the "Supported Elliptic Curves" extension Curves Extension" <xref target="RFC8422"/>.  Clients and servers <bcp14>SHOULD</bcp14> support the NIST P-256 P&nbhy;256 (secp256r1) <xref target="RFC8422"/> and X25519 (x25519) <xref target="RFC7748"/> curves.  Note that <xref target="RFC8422"/> deprecates all but the uncompressed point format.  Therefore, if the client sends an ec_point_formats <tt>ec_point_formats</tt> extension, the ECPointFormatList <bcp14>MUST</bcp14> contain a single element, "uncompressed".</t>
        </section>
      </section>
      <section anchor="cipher-suites-for-tls-13">
        <name>Cipher Suites for TLS 1.3</name>
        <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 cipher suite recommendations.</t>
      </section>

      <section anchor="limits-on-key-usage">
        <name>Limits on Key Usage</name>
        <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
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
encrypted.</li>
          <li>Integrity limit (IL), i.e., the number of records that are allowed to fail
authentication.</li>
        </ol>
        <t>The latter applies to DTLS (and also to QUIC) but not to TLS itself, since TLS connections are torn down on the
first decryption failure.</t>
        <t>When a sender is approaching CL, the implementation <bcp14>SHOULD</bcp14> initiate a new handshake (in TLS 1.3, this can be achieved by sending a KeyUpdate message on the established session) to rotate the session key. When a receiver has reached IL, the implementation <bcp14>SHOULD</bcp14> close the connection. Although these recommendations are a best practice, implementers need to be aware that it is not always easy to accomplish them in protocols that are built on top of TLS/DTLS without introducing coordination across layer boundaries.  See <xref section="6" sectionFormat="of" target="RFC9001"/> for an example of the cooperation that was necessary in QUIC between the crypto and transport layers to support key updates.  Note that in general, application protocols might not be able to emulate that method given their more constrained interaction with TLS/DTLS. As a result of these complexities, these recommendations are not mandatory.</t>
        <t>For all TLS 1.3 cipher suites, readers are referred to <xref section="5.5" sectionFormat="of" target="RFC8446"/> for the values of CL and IL. For all DTLS 1.3 cipher suites, readers are referred to <xref section="4.5.3" sectionFormat="of" target="RFC9147"/>.</t>
        <t>For all AES-GCM cipher suites recommended for TLS 1.2 and DTLS 1.2 in this
document, CL can be derived by plugging the corresponding parameters into the
inequalities in <xref section="6.1" sectionFormat="of" target="I-D.irtf-cfrg-aead-limits"/> that apply to
random, partially implicit nonces, i.e., the nonce construction used in TLS
1.2.  Although the obtained figures are slightly higher than those for TLS 1.3,
it is <bcp14>RECOMMENDED</bcp14> that the same limit of 2<sup>24.5</sup> records is used for
both versions.</t>
        <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>
      </section>
      <section anchor="rec-keylength">
        <name>Public Key Length</name>
        <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 agreement
      and one for server authentication. Where a client certificate is used, a third
      public key is added.</t>

      <t>With a key exchange based on modular exponential (MODP) Diffie-Hellman groups ("DHE" cipher suites), DH key lengths of at least 2048 bits are <bcp14>REQUIRED</bcp14>.</t>
        <t>Rationale: For various reasons, in practice, DH keys are typically generated 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).
 Because a DH key of 1228 bits would be roughly equivalent to only an 80-bit symmetric key
<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 <xref target="RFC3766"/>.
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"/>, target="NIST.SP.800-56A"/> as of this writing
(see in particular  Appendix D).</t> D of that document).</t>
        <t>As noted in <xref target="RFC3766"/>, correcting for the emergence of a TWIRL The Weizmann Institute Relation Locator (TWIRL) machine <xref target="TWIRL"/> would imply that 1024-bit DH keys yield about 61 bits of equivalent strength and 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 Diffie-Hellman parameters
should be avoided.</t>
        <t>With regard to ECDH keys, implementers are referred to the IANA "Supported Groups Registry" (former "TLS Supported Groups" registry (formerly known as the "EC Named Curve
Registry"),
Registry") within the
   "Transport Layer Security (TLS) Parameters" registry <xref target="IANA_TLS"/>, target="IANA_TLS"/> and in particular to the "recommended"
   groups.  Curves of less than 224 bits <bcp14>MUST NOT</bcp14> be used. This recommendation is in-line in line with the latest
revision of <xref target="NIST.SP.800-56A"/>.</t>
<t>When using RSA, servers <bcp14>MUST</bcp14> authenticate using certificates with 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>MUST NOT</bcp14> be used (<xref target="RFC9155"/>, and <xref target="RFC9155"/> (for more details, see also <xref target="CAB-Baseline"/> target="CAB-Baseline"/>, for more details). which the current version at the time of writing is 1.8.4). Clients <bcp14>MUST</bcp14> indicate to servers that they request SHA-256, 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 for advice on how to best handle this constantly updated guidance from the CA/Browser Forum.  In particular: which URL to use, which (if any) version to reference</cref></t>
      </section>
      <section anchor="truncated-hmac">
        <name>Truncated HMAC</name>
        <t>Implementations <bcp14>MUST NOT</bcp14> use the Truncated HMAC extension, Extension, defined in <xref section="7" sectionFormat="of" target="RFC6066"/>.</t>
        <t>Rationale: the The extension does not apply to the AEAD
      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>
      </section>
    </section>
    <section anchor="applicability">
      <name>Applicability Statement</name>
      <t>The recommendations of this document primarily apply to the implementation 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">
        <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, Post Office Protocol version 3 (POP3), or SMTP traffic with TLS.</li>
        <li>Instant-messaging software and services that wish to protect Extensible 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 Realtime Transport Protocol (SRTP) traffic with DTLS.</li>
      </ul>
      <t>This document does not modify the implementation and deployment recommendations (e.g., mandatory-to-implement cipher suites) prescribed by existing application protocols that employ TLS or DTLS. If the community that uses such an application protocol wishes to modernize its usage of TLS or DTLS to be consistent with the best practices recommended here, it needs to explicitly update the existing 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
  Standards Process <xref target="RFC2026"/> are expected at minimum to conform to the best
  practices recommended here, unless they provide documentation of
  compelling reasons that would prevent such conformance (e.g.,
  widespread deployment on constrained devices that lack support for
  the necessary algorithms).</t>
      <t>Although many of the recommendations provided here might also apply to QUIC insofar
that it uses the TLS 1.3 handshake protocol, QUIC and other such secure transport protocols
are out of scope of this document. For QUIC specifically, readers are
referred to <xref section="9.2" sectionFormat="of" target="RFC9001"/>.</t>
      <t>This document does not address the use of TLS in constrained-node networks
<xref target="RFC7228"/>.  For recommendations regarding the profiling of TLS and DTLS for
small devices with severe constraints on power, memory, and processing
resources, the reader is referred to <xref target="RFC7925"/> and
<xref target="I-D.ietf-uta-tls13-iot-profile"/>.</t>
      <section anchor="security-services">
        <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>
        <ul spacing="normal">
          <li>Confidentiality: all

	<dl>

 <dt>Confidentiality:
</dt>
<dd>all application-layer communication is encrypted with the goal
that no party should be able to decrypt it except the intended receiver.</li>
          <li>Data receiver.
</dd>

 <dt>Data integrity: any
</dt>
<dd>any changes made to the communication in transit are detectable
by the receiver.</li>
          <li>Authentication: an receiver.
</dd>

 <dt>Authentication:
</dt>
<dd>an endpoint of the TLS communication is authenticated as the
intended entity to communicate with.</li>
        </ul> with.
</dd>

</dl>

<t>With regard to authentication, TLS enables authentication of one or both endpoints in the communication.  In the context of opportunistic security <xref target="RFC7435"/>, TLS is sometimes used without authentication. As discussed in <xref target="oppsec"/>, considerations for opportunistic security are not in scope 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 security services.</t>
        <t>This document applies only to environments where confidentiality is required. It requires algorithms and configuration options that enforce secrecy of the data in transit.</t>
        <t>This document also assumes that data integrity protection is always one of the goals of a deployment. In cases where integrity is not required, it does not make sense to employ TLS in the first place. There are attacks against confidentiality-only protection that utilize the lack of integrity to also break confidentiality (see, for instance, <xref target="DegabrieleP07"/> in the context of IPsec).</t>
        <t>This document addresses itself to application protocols that are most commonly used on the Internet with TLS and DTLS. Typically, all communication between TLS clients and TLS servers requires all three of the above security services. This is particularly true where TLS clients are user agents like Web web browsers or email software.</t> clients.</t>
        <t>This document does not address the rarer deployment scenarios where one of the above three properties is not desired, such as the use case described in <xref target="oppsec"/> below. target="oppsec"/>.  As another scenario where confidentiality is not needed, consider a monitored network where the authorities in charge of the respective traffic domain require full access to unencrypted (plaintext) traffic, traffic and where users collaborate and send their traffic in the clear.</t>
      </section>
      <section anchor="oppsec">
        <name>Opportunistic Security</name>
        <t>There are several important scenarios in which the use of TLS is optional, i.e., the client decides dynamically ("opportunistically") whether to use TLS with a particular server or to connect in the clear.  This practice, often called "opportunistic security", is described at length in <xref target="RFC7435"/> and is often motivated by a desire for backward compatibility with legacy deployments.</t>
        <t>In these scenarios, some of the recommendations in this document might be too strict, since adhering to them could cause fallback to cleartext, a worse outcome than using TLS with an outdated protocol version or cipher suite.</t>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>

    <section anchor="sec">
      <name>Security Considerations</name>
      <t>This entire document discusses the security practices directly affecting applications
    using the TLS protocol. This section contains broader security considerations related
    to technologies used in conjunction with or by TLS.
    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 target="RFC5246"/> target="RFC5246"/>, and DTLS 1.2 <xref target="RFC6347"/>
    for further context.</t>
      <section anchor="host-name-validation">
        <name>Host Name Validation</name>
        <t>Application authors should take note that some TLS implementations
  do not validate host names.  If the TLS implementation they are
  using does not validate host names, authors might need to write their
  own validation code or consider using a different TLS implementation.</t>
  <t>It is noted that the requirements regarding host name validation (and, in general, binding between the TLS layer and the protocol that runs above it) vary between different protocols. For HTTPS, these requirements are defined by Sections 4.3.3, 4.3.4

  <xref target="RFC9110"  section="4.3.3" sectionFormat="bare" />, <xref target="RFC9110"
sectionFormat="bare" section="4.3.4" />, and 4.3.5 <xref target="RFC9110"
sectionFormat="bare" section="4.3.5" /> of <xref target="HTTP-SEMA"/>.</t> target="RFC9110"/>.</t>
        <t>Host name validation is security-critical for all common TLS use cases. Without it, TLS ensures that the certificate is valid and guarantees possession of the private key, key but does not ensure that the connection terminates at the desired endpoint. Readers are referred to <xref target="RFC6125"/> for further details regarding generic host name validation in the TLS context. In addition, that RFC contains a long list of example application protocols, some of which implement a policy very different from HTTPS.</t>
        <t>If the host name is discovered indirectly and insecurely (e.g., by a clear-text cleartext DNS query for an SRV or MX Mail Exchange (MX) record), it <bcp14>SHOULD NOT</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 name is discovered securely (for further discussion, see <xref target="DANE-SRV"/> target="RFC7673"/> and <xref target="DANE-SMTP"/>).</t> 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>
      </section>
      <section anchor="sec-aes">
        <name>AES-GCM</name>
        <t><xref target="rec-cipher"/> above recommends the use of the AES-GCM authenticated 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">
          <name> Nonce Reuse in TLS 1.2</name>
          <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
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"/>
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 deterministic
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
could still choose their own (potentially insecure) nonce generation methods.</t>
          <t>It is therefore <bcp14>RECOMMENDED</bcp14> that TLS 1.2 implementations use the 64-bit
sequence number to populate the <tt>nonce_explicit</tt> part of the GCM nonce, as
described in the first two paragraphs of <xref section="5.3" sectionFormat="of" target="RFC8446"/>. This stronger recommendation updates <xref section="3" sectionFormat="of" target="RFC5288"/>, which specified specifies that the use of 64-bit sequence numbers to populate the <tt>nonce_explicit</tt> field was is optional.</t>
          <t>We note that at the time of writing writing, there are no cipher suites defined for nonce
reuse resistant nonce-reuse-resistant algorithms such as AES-GCM-SIV <xref target="RFC8452"/>.</t>
        </section>
      </section>
      <section anchor="sec-pfs">
        <name>Forward Secrecy</name>
        <t>Forward secrecy (also called "perfect forward secrecy" or "PFS" and defined in <xref target="RFC4949"/>) is a defense against an attacker who records encrypted conversations where the session keys are only encrypted with the communicating parties' long-term keys.</t>
        <t>Should the attacker be able to obtain these long-term keys at some point later in time, the session keys and thus the entire conversation could be decrypted.</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">
          <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 otherwise decommissioned without prior wiping.</li>
          <li>A long-term key used on a device as a default key <xref target="Heninger2012"/>.</li>
          <li>A key generated by a trusted third party like a CA, CA and later retrieved from it either by either extortion or compromise <xref target="Soghoian2011"/>.</li>
          <li>A cryptographic break-through, breakthrough or the use of asymmetric keys with insufficient length <xref target="Kleinjung2010"/>.</li>
          <li>Social engineering attacks against system administrators.</li>
          <li>Collection of private keys from inadequately protected backups.</li>
        </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 long-term keys some time after the conversation. It also protects against an attacker who is in possession of the long-term keys but remains passive during the conversation.</t>
        <t>Forward secrecy is generally achieved by using the Diffie-Hellman scheme to derive session keys. The Diffie-Hellman scheme has both parties maintain private secrets and send parameters over the network as modular powers over certain cyclic groups. The properties of the so-called Discrete Logarithm Problem (DLP) allow the parties to derive the session keys without an eavesdropper being able to do so. There is currently no known attack against DLP if sufficiently large parameters are chosen. A variant of the Diffie-Hellman scheme uses elliptic curves instead of the originally proposed modular arithmetic. Given the current state of the art, elliptic-curve Elliptic Curve Diffie-Hellman appears to be more efficient, permits 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 feature forward secrecy, e.g., TLS_RSA_WITH_AES_256_CBC_SHA256.  This document therefore advocates strict use of forward-secrecy-only ciphers.</t>
      </section>
      <section anchor="sec-dhe">
        <name>Diffie-Hellman Exponent Reuse</name>
        <t>For performance reasons, it is not uncommon for TLS implementations to reuse Diffie-Hellman and Elliptic Curve Diffie-Hellman exponents across multiple connections. Such reuse can result in major security issues:</t>
        <ul spacing="normal">
          <li>If exponents are reused for too long (in some cases, even as little 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 secrecy.</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. These tests are not standardized in TLS at the time of writing, although general guidance in this area is provided by <xref target="NIST.SP.800-56A"/> and available 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>An "invalid curve" attack can be mounted against elliptic-curve 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 varying the points to recover the full secret (see <xref target="Antipa2003"/> and <xref target="Jager2015"/>).</li>
        </ul>
        <t>To address these concerns:</t>
        <ul spacing="normal">
          <li>TLS implementations <bcp14>SHOULD NOT</bcp14> use static finite-field DH keys and <bcp14>SHOULD NOT</bcp14> reuse ephemeral finite-field DH keys across multiple connections.</li>
          <li>Server implementations that want to reuse elliptic-curve Elliptic Curve DH keys <bcp14>SHOULD</bcp14> either use a "safe curve" <xref target="SAFECURVES"/> (e.g., X25519), X25519) or perform the checks described in <xref target="NIST.SP.800-56A"/> on the received points.</li>
        </ul>
      </section>
      <section anchor="certificate-revocation">
        <name>Certificate Revocation</name>
        <t>The following considerations and recommendations represent the current 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">
          <li>Certificate revocation is an important tool when recovering from attacks on the TLS implementation, implementation as well as cases of misissued certificates. TLS implementations <bcp14>MUST</bcp14> implement a strategy to distrust revoked certificates.</li>
          <li>Although Certificate Revocation Lists (CRLs) are the most widely supported mechanism for distributing revocation information, they have known scaling challenges that limit their usefulness, despite workarounds such as partitioned 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 Certificate Transparency <xref target="RFC9162"/> logs and aggressive compression to allow 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 web browser's configuration database cannot scale beyond the few, few most heavily used Web web servers.</li>
          <li>The On-Line Online Certification Status Protocol (OCSP) <xref target="RFC6960"/> in its basic form presents both scaling and privacy issues. In addition, clients typically "soft-fail", meaning that they do not abort the TLS connection if the OCSP server does not respond. (However, this might be a workaround to avoid denial-of-service attacks if an OCSP responder is taken offline.). offline.) For an up-to-date a recent survey of the status of OCSP deployment in the Web PKI web PKI, see <xref target="Chung18"/>.</li>
          <li>The TLS Certificate Status Request extension (<xref section="8" sectionFormat="of" target="RFC6066"/>), commonly called "OCSP stapling", resolves the operational issues with OCSP. However, it is still ineffective in the presence of a MITM an active on-path attacker because the attacker can simply ignore the client's request for a stapled OCSP response.</li>
          <li>
            <xref target="RFC7633"/> defines a certificate extension that indicates 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 certificates within a certificate chain. The Multiple Certificate Status extension <xref target="RFC6961"/> addresses this shortcoming, but it has seen little deployment and had been deprecated by <xref target="RFC8446"/>. As a result, we no longer recommend although this extension was recommended for TLS 1.2.</li> 1.2 in <xref target="RFC7525"/>, it is no longer recommended by this document.</li>
          <li>TLS 1.3 (<xref section="4.4.2.1" sectionFormat="of" target="RFC8446"/>) allows the association of OCSP information with intermediate certificates by using an extension to the CertificateEntry structure. However, using this facility remains impractical because many CAs certification authorities (CAs) either do not publish OCSP for CA certificates or publish OCSP reports with a lifetime that is too long to be useful.</li>
          <li>Both CRLs and OCSP depend on relatively reliable connectivity to the Internet, which might not be available to certain kinds of nodes. A common example is newly provisioned devices that need to establish a secure connection in order to boot up for the first time.</li>
        </ul>
        <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 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 defined in <xref target="RFC6066"/>. Note that the exact mechanism for embedding the <tt>status_request</tt> extension differs between TLS 1.2 and 1.3. As a matter of local policy, server operators <bcp14>MAY</bcp14> request that CAs issue must-staple <xref target="RFC7633"/> certificates for the server and/or for client authentication, but we recommend to review reviewing the operational conditions before deciding on this approach.</t>
        <t>The considerations in this section do not apply to scenarios where the DANE-TLSA DNS-Based
              Authentication of Named Entities (DANE) TLSA resource record <xref target="RFC6698"/> is used to signal to a client which certificate a server considers valid and good to use for TLS connections.</t>
      </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 of this document.</t>
    </section>

  </middle>
  <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-DET-SIGS"/>

    <references>
      <name>References</name>
<references>
        <name>Normative References</name>
        <reference anchor="RFC7465" target="https://www.rfc-editor.org/info/rfc7465">
          <front>
            <title>Prohibiting RC4 Cipher Suites</title>
            <author fullname="A. Popov" initials="A." surname="Popov">
              <organization/>
            </author>
            <date month="February" year="2015"/>
            <abstract>
              <t>This document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections.  This applies to all TLS versions.  This document updates RFCs 5246, 4346, and 2246.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7465"/>
          <seriesInfo name="DOI" value="10.17487/RFC7465"/>
        </reference>
        <reference anchor="RFC5246" target="https://www.rfc-editor.org/info/rfc5246">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
            <author fullname="T. Dierks" initials="T." surname="Dierks">
              <organization/>
            </author>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla">
              <organization/>
            </author>
            <date month="August" year="2008"/>
            <abstract>
              <t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5246"/>
          <seriesInfo name="DOI" value="10.17487/RFC5246"/>
        </reference>
        <reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6347">
          <front>
            <title>Datagram Transport Layer Security Version 1.2</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla">
              <organization/>
            </author>
            <author fullname="N. Modadugu" initials="N." surname="Modadugu">
              <organization/>
            </author>
            <date month="January" year="2012"/>
            <abstract>
              <t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.  This document updates DTLS 1.0 to work with TLS version 1.2.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6347"/>
          <seriesInfo name="DOI" value="10.17487/RFC6347"/>
        </reference>
        <reference anchor="RFC8996" target="https://www.rfc-editor.org/info/rfc8996">
          <front>
            <title>Deprecating TLS 1.0 and TLS 1.1</title>
            <author fullname="K. Moriarty" initials="K." surname="Moriarty">
              <organization/>
            </author>
            <author fullname="S. Farrell" initials="S." surname="Farrell">
              <organization/>
            </author>
            <date month="March" year="2021"/>
            <abstract>
              <t>This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance. </t>
              <t>This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1.</t>
              <t>This document updates many RFCs that normatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in

	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3766.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5246.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5288.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5746.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6066.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6125.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6176.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6347.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6979.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7301.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7366.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7465.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7627.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7748.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8422.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8446.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8996.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9147.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9155.xml"/>

	  </references>
      <references>
        <name>Informative References</name>

	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2026.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2246.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3261.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3602.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4346.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4347.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4949.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5077.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5116.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5280.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5321.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6101.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6120.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6698.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6797.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6960.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6961.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7228.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7507.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7525.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7590.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7435.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7457.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7633.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7672.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7673.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7568.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9110.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9112.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9113.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7712.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7919.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7924.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7925.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8452.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8461.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8470.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8879.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9000.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9001.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9051.xml"/>
 	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9162.xml"/>

<!-- Note: RFC 7525; hence, it is part of BCP 195.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="195"/>
          <seriesInfo name="RFC" value="8996"/>
          <seriesInfo name="DOI" value="10.17487/RFC8996"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla">
              <organization/>
            </author>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements 9191 library has wrong name for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC9147" target="https://www.rfc-editor.org/info/rfc9147">
          <front>
            <title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla">
              <organization/>
            </author>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig">
              <organization/>
            </author>
            <author fullname="N. Modadugu" initials="N." surname="Modadugu">
              <organization/>
            </author>
            <date month="April" year="2022"/>
            <abstract>
              <t>This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a J. Preuß Mattsson. Long way that is designed to prevent eavesdropping, tampering, 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 exception 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/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <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 signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  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/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <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 protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC6176" target="https://www.rfc-editor.org/info/rfc6176">
          <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  Secure Sockets Layer (SSL) version 2.0.  This document updates the  backward compatibility 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/rfc5746">
          <front>
            <title>Transport Layer Security (TLS) Renegotiation Indication Extension</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) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection 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 specification defines a TLS extension to cryptographically tie renegotiations to the 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/rfc7627">
          <front>
            <title>Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension</title>
            <author fullname="K. Bhargavan" initials="K." role="editor" surname="Bhargavan">
              <organization/>
            </author>
            <author fullname="A. Delignat-Lavaud" initials="A." surname="Delignat-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 cryptographically bound to important session parameters such as the server certificate.  Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same.  Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server.  This specification defines a TLS extension 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/rfc7301">
          <front>
            <title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation 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) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol 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/rfc3766">
          <front>
            <title>Determining Strengths For Public Keys Used For Exchanging Symmetric 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 exchange symmetric keys need to make the public keys resistant to some predetermined level of attack.  That level of attack resistance is the strength of the system, and the symmetric keys that are exchanged must be at least as strong as the system strength requirements.  The three quantities, system strength, symmetric key strength, and public key strength, must be consistently matched for any network protocol usage.  While it is fairly easy to express the system strength requirements 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 requirement.  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 estimating equivalent resistance to large-scale attacks on various algorithms are given.  The document also addresses how changing the sizes of the underlying large integers (moduli, group sizes, exponents, and so on) changes the time to use the algorithms for key exchange.  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="86"/>
          <seriesInfo name="RFC" value="3766"/>
          <seriesInfo name="DOI" value="10.17487/RFC3766"/>
        </reference>
        <reference anchor="RFC7366" target="https://www.rfc-editor.org/info/rfc7366">
          <front>
            <title>Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram 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 encrypt-then-MAC security mechanism in place of the existing MAC-then-encrypt mechanism in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS).  The MAC-then-encrypt mechanism has been the subject of a number of security vulnerabilities over a period of many years.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7366"/>
          <seriesInfo name="DOI" value="10.17487/RFC7366"/>
        </reference> instead.
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9191.xml"/>
-->
 <reference anchor="RFC6979" target="https://www.rfc-editor.org/info/rfc6979"> anchor="RFC9191" target="https://www.rfc-editor.org/info/rfc9191">
          <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 generation procedure.  Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures
            <title>Handling Large Certificates and can be processed with unmodified verifiers, which need not be aware of the procedure described therein.  Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented Long Certificate Chains in various environments, since they do not need access to a source 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/rfc8422">
          <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> TLS-Based EAP Methods</title>
            <author fullname="M. Pegourie-Gonnard" fullname="Mohit Sethi" initials="M." surname="Pegourie-Gonnard">
              <organization/>
            </author>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol.  In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) 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/rfc7748">
          <front>
            <title>Elliptic Curves for Security</title>
            <author fullname="A. Langley" initials="A." surname="Langley"> surname="Sethi">
              <organization/>
            </author>
            <author fullname="M. Hamburg" initials="M." surname="Hamburg"> fullname="John Preuß Mattsson" initials="J." surname="Preuß Mattsson">
              <organization/>
            </author>
            <author fullname="S. fullname="Sean 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, including Transport Layer Security (TLS).  These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically 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/rfc9155">
          <front>
            <title>Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 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 vulnerable to attack, and this document deprecates their use in TLS 1.2 and DTLS 1.2 digital signatures. However, this document does not deprecate SHA-1 with Hashed Message Authentication Code (HMAC), as used in record protection. This document updates 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/rfc6125">
          <front>
            <title>Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates 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 between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services 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/rfc5288">
          <front>
            <title>AES Galois Counter Mode (GCM) Cipher Suites for TLS</title>
            <author fullname="J. Salowey" initials="J." surname="Salowey">
              <organization/>
            </author>
            <author fullname="A. Choudhury" initials="A." surname="Choudhury">
              <organization/>
            </author>
            <author fullname="D. McGrew" initials="D." surname="McGrew">
              <organization/>
            </author>
            <date month="August" year="2008"/>
            <abstract>
              <t>This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) authenticated encryption operation.  GCM provides both confidentiality and data origin authentication, can be efficiently implemented in hardware for speeds of 10 gigabits 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-Hellman-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/rfc6066">
          <front>
            <title>Transport Layer Security (TLS) Extensions: Extension Definitions</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd">
              <organization/>
            </author>
            <date month="January" year="2011"/>
            <abstract>
              <t>This document provides specifications for existing TLS extensions.  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_request.  [STANDARDS-TRACK]</t>
            </abstract> month="February" year="2022"/>
          </front>
          <seriesInfo name="RFC" value="6066"/> value="9191"/>
          <seriesInfo name="DOI" value="10.17487/RFC6066"/> value="10.17487/RFC9191"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>

	<reference anchor="TWIRL" target="http://cs.tau.ac.il/~tromer/papers/twirl.pdf"> target="https://cs.tau.ac.il/~tromer/papers/twirl.pdf">
          <front>
            <title>Factoring Large Numbers with the TWIRL Device</title>
            <author initials="A." surname="Shamir" fullname="Adi Shamir">
              <organization/>
            </author>
            <author initials="E." surname="Tromer" fullname="Eran Tromer">
              <organization/>
            </author>
            <date year="2003"/> year="2004"/>
          </front>
	  <seriesInfo name="proc. Crypto 2003, LNCS 2729, 1-26, Springer-Verlag" value=""/> name="DOI" value="10.1007/978-3-540-45146-4_1"/>
          <refcontent>2014 IEEE Symposium on Security and Privacy</refcontent>
        </reference>

<reference anchor="Chung18">
          <front>
            <title>Is the Web Ready for OCSP Must-Staple?</title>
            <author fullname="Taejoong Chung" initials="T." surname="Chung">
              <organization>Rochester Institute of Technology and Northeastern University</organization>
            </author>
            <author fullname="Jay Lok" initials="J." surname="Lok">
              <organization>Northeastern University</organization>
            </author>
            <author fullname="Balakrishnan Chandrasekaran" initials="B." surname="Chandrasekaran">
              <organization>Max Planck Institute for Informatics</organization>
            </author>
            <author fullname="David Choffnes" initials="D." surname="Choffnes">
              <organization>Northeastern University</organization>
            </author>
            <author fullname="Dave Levin" initials="D." surname="Levin">
              <organization>University of Maryland</organization>
            </author>
            <author fullname="Bruce M. Maggs" initials="B." surname="Maggs">
              <organization>Duke University and Akamai Technologies</organization>
            </author>
            <author fullname="Alan Mislove" initials="A." surname="Mislove">
              <organization>Northeastern University</organization>
            </author>
            <author fullname="John Rula" initials="J." surname="Rula">
              <organization>Akamai Technologies</organization>
            </author>
            <author fullname="Nick Sullivan" initials="N." surname="Sullivan">
              <organization>Cloudflare</organization>
            </author>
            <author fullname="Christo Wilson" initials="C." surname="Wilson">
              <organization>Northeastern University</organization>
            </author>
            <date month="October" year="2018"/>
          </front>
          <seriesInfo name="Proceedings name="DOI" value="10.1145/3278532.3278543"/>
	  <refcontent>Proceedings of the Internet Measurement Conference" value="2018"/>
          <seriesInfo name="DOI" value="10.1145/3278532.3278543"/> Conference 2018</refcontent>
        </reference>

        <reference anchor="CRLite">
          <front>
            <title>CRLite: A Scalable System for Pushing All TLS Revocations to All Browsers</title>
            <author fullname="James Larisch" initials="J." surname="Larisch">
              <organization/>
            </author>
            <author fullname="David Choffnes" initials="D." surname="Choffnes">
              <organization/>
            </author>
            <author fullname="Dave Levin" initials="D." surname="Levin">
              <organization/>
            </author>
            <author fullname="Bruce M. Maggs" initials="B." surname="Maggs">
              <organization/>
            </author>
            <author fullname="Alan Mislove" initials="A." surname="Mislove">
              <organization/>
            </author>
            <author fullname="Christo Wilson" initials="C." surname="Wilson">
              <organization/>
            </author>
            <date month="May" year="2017"/>
          </front>
          <seriesInfo name="2017
          <refcontent>2017 IEEE Symposium on Security and Privacy" value="(SP)"/> Privacy (SP)</refcontent>
          <seriesInfo name="DOI" value="10.1109/sp.2017.17"/>
        </reference>

	<reference anchor="LetsRevoke">
          <front>
            <title>Let's Revoke: Scalable Global Certificate Revocation</title>
            <author fullname="Trevor Smith" initials="T." surname="Smith">
              <organization/>
            </author>
            <author fullname="Luke Dickinson" initials="L." surname="Dickinson">
              <organization/>
            </author>
            <author fullname="Kent Seamons" initials="K." surname="Seamons">
              <organization/>
            </author>
            <date month="February" year="2020"/>
          </front>
          <seriesInfo name="Proceedings
          <refcontent>Proceedings 2020 Network and Distributed System Security" value="Symposium"/> Security Symposium</refcontent>
          <seriesInfo name="DOI" value="10.14722/ndss.2020.24084"/>
        </reference>

	<reference anchor="DegabrieleP07">
          <front>
            <title>Attacking the IPsec Standards in Encryption-only Configurations</title>
            <author fullname="Jean Paul Degabriele" initials="J." surname="Degabriele">
              <organization/>
            </author>
            <author fullname="Kenneth G. Paterson" initials="K." surname="Paterson">
              <organization/>
            </author>
            <date month="May" year="2007"/>
          </front>
          <seriesInfo name="2007
          <refcontent>2007 IEEE Symposium on Security and Privacy (SP" value="'07)"/> (SP '07)</refcontent>
          <seriesInfo name="DOI" value="10.1109/sp.2007.8"/>
        </reference>

	<reference anchor="triple-handshake"> anchor="Triple-Handshake">
          <front>
            <title>Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS</title>
            <author fullname="Karthikeyan Bhargavan" initials="K." surname="Bhargavan">
              <organization/>
            </author>
            <author fullname="Antoine Delignat Lavaud" initials="A." surname="Lavaud">
              <organization/>
            </author>
            <author fullname="Cedric Fournet" initials="C." surname="Fournet">
              <organization/>
            </author>
            <author fullname="Alfredo Pironti" initials="A." surname="Pironti">
              <organization/>
            </author>
            <author fullname="Pierre Yves Strub" initials="P." surname="Strub">
              <organization/>
            </author>
            <date month="May" year="2014"/>
          </front>
          <seriesInfo name="2014
          <refcontent>2014 IEEE Symposium on Security and" value="Privacy"/> and Privacy</refcontent>
          <seriesInfo name="DOI" value="10.1109/sp.2014.14"/>
        </reference>

	<reference anchor="Soghoian2011">
          <front>
            <title>Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL</title>
            <author fullname="Christopher Soghoian" initials="C." surname="Soghoian">
              <organization/>
            </author>
            <author fullname="Sid Stamm" initials="S." surname="Stamm">
              <organization/>
            </author>
            <date month="April" year="2010"/>
          </front>
          <seriesInfo name="SSRN Electronic" value="Journal"/>
          <refcontent>SSRN Electronic Journal</refcontent>
          <seriesInfo name="DOI" value="10.2139/ssrn.1591033"/>
	</reference>

	<reference anchor="Logjam">
          <front>
            <title>Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice</title>
            <author fullname="David Adrian" initials="D." surname="Adrian">
              <organization>University of Michigan, Ann Arbor, MI, USA</organization>
            </author>
            <author fullname="Karthikeyan Bhargavan" initials="K." surname="Bhargavan">
              <organization>INRIA Paris-Rocquencourt, Paris, France</organization>
            </author>
            <author fullname="Zakir Durumeric" initials="Z." surname="Durumeric">
              <organization>University of Michigan, Ann Arbor, MI, USA</organization>
            </author>
            <author fullname="Pierrick Gaudry" initials="P." surname="Gaudry">
              <organization>INRIA Nancy-Grand Est, CNRS and Université de Lorraine, Nancy, France</organization>
            </author>
            <author fullname="Matthew Green" initials="M." surname="Green">
              <organization>Johns Hopkins University, Baltimore, MD, USA</organization>
            </author>
            <author fullname="J. Alex Halderman" initials="J." surname="Halderman">
              <organization>University of Michigan, Ann Arbor, MI, USA</organization>
            </author>
            <author fullname="Nadia Heninger" initials="N." surname="Heninger">
              <organization>University of Pennsylvania, Philadelphia, PA, USA</organization>
            </author>
            <author fullname="Drew Springall" initials="D." surname="Springall">
              <organization>University of Michigan, Ann Arbor, MI, USA</organization>
            </author>
            <author fullname="Emmanuel Thomé" initials="E." surname="Thomé">
              <organization>INRIA Nancy-Grand Est, CNRS and Université de Lorraine, Nancy, France</organization>
            </author>
            <author fullname="Luke Valenta" initials="L." surname="Valenta">
              <organization>University of Pennsylvania, Philadelphia, PA, USA</organization>
            </author>
            <author fullname="Benjamin VanderSloot" initials="B." surname="VanderSloot">
              <organization>University of Michigan, Ann Arbor, MI, USA</organization>
            </author>
            <author fullname="Eric Wustrow" initials="E." surname="Wustrow">
              <organization>University of Michigan, Ann Arbor, MI, USA</organization>
            </author>
            <author fullname="Santiago Zanella-Béguelin" initials="S." surname="Zanella-Béguelin">
              <organization>Microsoft Research, Cambridge, United Kingdom</organization>
            </author>
            <author fullname="Paul Zimmermann" initials="P." surname="Zimmermann">
              <organization>INRIA Nancy-Grand Est, CNRS and Université de Lorraine, Nancy, France</organization>
            </author>
            <date month="October" year="2015"/>
          </front>
          <seriesInfo name="Proceedings
          <refcontent>Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications" value="Security"/> Communications Security, pp. 5-17</refcontent>
          <seriesInfo name="DOI" value="10.1145/2810103.2813707"/>
        </reference>

        <reference anchor="POODLE" target="https://www.us-cert.gov/ncas/alerts/TA14-290A">
          <front>
            <title>SSL 3.0 Protocol Vulnerability and POODLE Attack</title>
            <author>
              <organization>US-CERT</organization>
            </author>
            <date year="2014" month="October"/>
          </front>
        </reference>

        <reference anchor="CAB-Baseline" target="https://cabforum.org/documents/">
          <front>
            <title>Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates Version 1.1.6</title> Certificates</title>
            <author>
              <organization>CA/Browser Forum</organization>
            </author>
            <date year="2013"/> month="April" year="2022"/>
          </front>
	    <seriesInfo name="Version" value="1.8.4"/>
        </reference>

        <reference anchor="Heninger2012">
          <front>
            <title>Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices</title>
            <author initials="N." surname="Heninger" fullname="Nadia Heninger">
              <organization/>
            </author>
            <author initials="Z." surname="Durumeric" fullname="Zakir Durumeric">
              <organization/>
            </author>
            <author initials="E." surname="Wustrow" fullname="Eric Wustrow">
              <organization/>
            </author>
            <author initials="J. A." surname="Halderman" fullname="J. Alex Halderman">
              <organization/>
            </author>
            <date year="2012"/> year="2012" month="August"/>
          </front>
          <seriesInfo name="Usenix
          <refcontent>21st Usenix Security Symposium" value="2012"/> Symposium</refcontent>
        </reference>

        <reference anchor="Sy2018">
          <front>
            <title>Tracking Users across the Web via TLS Session Resumption</title>
            <author fullname="Erik Sy" initials="E." surname="Sy">
              <organization>University of Hamburg</organization>
            </author>
            <author fullname="Christian Burkert" initials="C." surname="Burkert">
              <organization>University of Hamburg</organization>
            </author>
            <author fullname="Hannes Federrath" initials="H." surname="Federrath">
              <organization>University of Hamburg</organization>
            </author>
            <author fullname="Mathias Fischer" initials="M." surname="Fischer">
              <organization>University of Hamburg</organization>
            </author>
            <date month="December" year="2018"/>
          </front>
          <seriesInfo name="Proceedings
          <refcontent>Proceedings of the 34th Annual Computer Security Applications" value="Conference"/> Applications Conference, pp. 289-299</refcontent>
          <seriesInfo name="DOI" value="10.1145/3274694.3274708"/>
        </reference>

        <reference anchor="DANE-SMTP" target="https://www.rfc-editor.org/info/rfc7672">
          <front>
            <title>SMTP Security via Opportunistic DNS-Based Authentication of Named 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 transport security between Message Transfer Agents (MTAs), based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol 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">
          <front>
            <title>Tag Size Does Matter: Attacks and Proofs for the TLS Record Protocol</title>
            <author fullname="Kenneth G. Paterson" initials="K." surname="Paterson">
              <organization/>
            </author>
            <author fullname="Thomas Ristenpart" initials="T." surname="Ristenpart">
              <organization/>
            </author>
            <author fullname="Thomas Shrimpton" initials="T." surname="Shrimpton">
              <organization/>
            </author>
            <date year="2011"/>
          </front>
          <seriesInfo name="Lecture Notes in Computer Science" value="pp. 372-389"/>
          <seriesInfo name="DOI" value="10.1007/978-3-642-25385-0_20"/>
        </reference>
        <reference anchor="DANE-SRV" target="https://www.rfc-editor.org/info/rfc7673">
          <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) specification (RFC 6698) describes how to use TLSA resource records secured by DNSSEC (RFC 4033) to associate a server's connection endpoint with its Transport Layer Security (TLS) certificate (thus enabling administrators of domain names to specify the keys used in that domain's TLS servers).  However, application protocols that use SRV records (RFC 2782) to indirectly name the target server connection endpoints for a service domain name cannot apply the rules from RFC 6698.  Therefore, this document provides guidelines that enable such protocols to locate and use TLSA records.</t>
            </abstract> month="December" year="2011" />
          </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/rfc9110">
          <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="Reschke">
              <organization/>
            </author>
            <date month="June" year="2022"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, 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, 7232, 7233, 7235, 7538, 7615, 7694, and portions
          <refcontent>Proceedings 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/rfc9112">
          <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="Reschke">
              <organization/>
            </author>
            <date month="June" year="2022"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, 17th International conference on The Theory 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/rfc9113">
          <front>
            <title>HTTP/2</title>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson">
              <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 semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use Application of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection.</t>
              <t>This document obsoletes RFCs 7540 Cryptology and 8740.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9113"/> Information Security, pp. 372-389</refcontent>
          <seriesInfo name="DOI" value="10.17487/RFC9113"/> value="10.1007/978-3-642-25385-0_20"/>
        </reference>

        <reference anchor="Kleinjung2010">
          <front>
            <title>Factorization of a 768-Bit RSA Modulus</title>
            <author fullname="Thorsten Kleinjung" initials="T." surname="Kleinjung">
              <organization/>
            </author>
            <author fullname="Kazumaro Aoki" initials="K." surname="Aoki">
              <organization/>
            </author>
            <author fullname="Jens Franke" initials="J." surname="Franke">
              <organization/>
            </author>
            <author fullname="Arjen K. Lenstra" initials="A." surname="Lenstra">
              <organization/>
            </author>
            <author fullname="Emmanuel Thomé" initials="E." surname="Thomé">
              <organization/>
            </author>
            <author fullname="Joppe W. Bos" initials="J." surname="Bos">
              <organization/>
            </author>
            <author fullname="Pierrick Gaudry" initials="P." surname="Gaudry">
              <organization/>
            </author>
            <author fullname="Alexander Kruppa" initials="A." surname="Kruppa">
              <organization/>
            </author>
            <author fullname="Peter L. Montgomery" initials="P." surname="Montgomery">
              <organization/>
            </author>
            <author fullname="Dag Arne Osvik" initials="D." surname="Osvik">
              <organization/>
            </author>
            <author fullname="Herman te Riele" initials="H." surname="te Riele">
              <organization/>
            </author>
            <author fullname="Andrey Timofeev" initials="A." surname="Timofeev">
              <organization/>
            </author>
            <author fullname="Paul Zimmermann" initials="P." surname="Zimmermann">
              <organization/>
            </author>
            <date year="2010"/>
          </front>
          <seriesInfo name="Advances
          <refcontent>Advances in Cryptology - CRYPTO 2010" value="pp. 333-350"/> 2010, pp. 333-350</refcontent>
          <seriesInfo name="DOI" value="10.1007/978-3-642-14623-7_18"/>
        </reference>

        <reference anchor="IANA_TLS" target="https://www.iana.org/assignments/tls-parameters">
          <front>
            <title>Transport Layer Security (TLS) Parameters</title>
            <author>
              <organization abbrev="IANA">Internet Assigned Numbers Authority</organization>
            </author>
            <date day="23" month="August" year="2005"/>
          </front>
        </reference>

        <reference anchor="Multiple-Encryption">
          <front>
            <title>On the security of multiple encryption</title>
            <author fullname="Ralph C. Merkle" initials="R." surname="Merkle">
              <organization>Elxsi, Int., Sunnyvale, CA</organization>
            </author>
            <author fullname="Martin E. Hellman" initials="M." surname="Hellman">
              <organization>Stanford Univ., Stanford, CA</organization>
            </author>
            <date month="July" year="1981"/>
          </front>
          <seriesInfo name="Communications
          <refcontent>Communications of the ACM" value="vol. ACM, Vol. 24, no. Issue 7, pp. 465-467"/> 465-467</refcontent>
          <seriesInfo name="DOI" value="10.1145/358699.358718"/>
        </reference>

<reference anchor="NIST.SP.800-56A">
<front>
            <title>Recommendation
<title>
Recommendation for pair-wise key-establishment schemes using discrete logarithm cryptography</title>
            <author fullname="Elaine Barker" initials="E." surname="Barker">
              <organization/>
            </author>
            <author fullname="Lily Chen" initials="L." surname="Chen">
              <organization/>
            </author>
            <author fullname="Allen Roginsky" initials="A." surname="Roginsky">
              <organization/>
            </author>
            <author fullname="Apostol Vassilev" initials="A." surname="Vassilev">
              <organization/>
            </author>
            <author fullname="Richard Davis" initials="R." surname="Davis">
              <organization/> Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography
</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="April" year="2018"/>
</front>
<refcontent>Revision 3</refcontent>
<seriesInfo name="National Institute of Standards and Technology" value="report"/> name="NIST Special Publication" value="800-56A"/>
<seriesInfo name="DOI" value="10.6028/nist.sp.800-56ar3"/> value="10.6028/NIST.SP.800-56Ar3"/>
</reference>

        <reference anchor="Springall16">
          <front>
            <title>Measuring the Security Harm of TLS Crypto Shortcuts</title>
            <author fullname="Drew Springall" initials="D." surname="Springall">
              <organization>University of Michigan, Ann Arbor, MI, USA</organization>
            </author>
            <author fullname="Zakir Durumeric" initials="Z." surname="Durumeric">
              <organization>University of Michigan, Ann Arbor, MI, USA</organization>
            </author>
            <author fullname="J. Alex Halderman" initials="J." surname="Halderman">
              <organization>University of Michigan, Ann Arbor, MI, USA</organization>
            </author>
            <date month="November" year="2016"/>
          </front>
          <seriesInfo name="Proceedings
          <refcontent>Proceedings of the 2016 Internet Measurement" value="Conference"/> Measurement Conference, pp. 33-47</refcontent>
          <seriesInfo name="DOI" value="10.1145/2987443.2987480"/>
        </reference>

<reference anchor="DEP-SSLv3" target="https://www.rfc-editor.org/info/rfc7568">
          <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 RFC 6101, is not sufficiently secure.  This document requires that SSLv3 not be used.  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.pdf">
          <front>
            <title>Nonce-Disrespecting Adversaries: Practical Forgery Attacks on GCM in TLS</title>
            <author initials="H." surname="Böck" fullname="Hanno Böck">
              <organization/>
            </author>
            <author initials="A." surname="Zauner" fullname="Aaron Zauner">
              <organization/>
            </author>
            <author initials="S." surname="Devlin" fullname="Sean Devlin">
              <organization/>
            </author>
            <author initials="J." surname="Somorovsky" fullname="Juraj Somorovsky">
              <organization/>
            </author>
            <author initials="P." surname="Jovanovic" fullname="Philipp Jovanovic">
              <organization/>
            </author>
            <date year="2016" month="May"/>
          </front>
        </reference>

	<reference anchor="Joux2006" target="https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/comments/800-38-series-drafts/gcm/joux_comments.pdf">
          <front>
            <title>Authentication Failures in NIST version of GCM</title>
            <author initials="A." surname="Joux" fullname="Antoine Joux">
              <organization/>
            </author>
            <date year="2006"/>
          </front>
        </reference>

        <reference anchor="CVE" target="https://cve.mitre.org">
          <front>
            <title>Common
            <title>CVE Program</title>
            <author>
              <organization>Common Vulnerabilities and Exposures</title>
            <author>
              <organization>MITRE</organization> Exposures</organization>
            </author>
            <date/>
          </front>
	  <refcontent>MITRE</refcontent>
        </reference>

        <reference anchor="ALPACA" target="https://www.usenix.org/conference/usenixsecurity21/presentation/brinkmann">
          <front>
            <title>ALPACA: Application Layer Protocol Confusion - Analyzing and Mitigating Cracks in TLS Authentication</title>
            <author initials="M." surname="Brinkmann" fullname="Marcus Brinkmann">
              <organization/>
            </author>
            <author initials="C." surname="Dresen" fullname="Christian Dresen">
              <organization/>
            </author>
            <author initials="R." surname="Merget" fullname="Robert Merget">
              <organization/>
            </author>
            <author initials="D." surname="Poddebniak" fullname="Damian Poddebniak">
              <organization/>
            </author>
            <author initials="J." surname="Müller" fullname="Jens Müller">
              <organization/>
            </author>
            <author initials="J." surname="Somorovsky" fullname="Juraj Somorovsky">
              <organization/>
            </author>
            <author initials="J." surname="Schwenk" fullname="Jörg Schwenk">
              <organization/>
            </author>
            <author initials="S." surname="Schinzel" fullname="Sebastian Schinzel">
              <organization/>
            </author>
            <date month="August" year="2021"/>
          </front>
          <seriesInfo name="30th
          <refcontent>30th USENIX Security Symposium (USENIX Security 21)" value=""/> 21)</refcontent>
        </reference>

        <reference anchor="DROWN" target="https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/aviram">
          <front>
            <title>DROWN: Breaking TLS using SSLv2</title>
            <author initials="N." surname="Aviram" fullname="Nimrod Aviram">
              <organization/>
            </author>
            <author initials="S." surname="Schinzel" fullname="Sebastian Schinzel">
              <organization/>
            </author>
            <author initials="J." surname="Somorovsky" fullname="Juraj Somorovsky">
              <organization/>
            </author>
            <author initials="N." surname="Heninger" fullname="Nadia Heninger">
              <organization/>
            </author>
            <author initials="M." surname="Dankel" fullname="Maik Dankel">
              <organization/>
            </author>
            <author initials="J." surname="Steube" fullname="Jens Steube">
              <organization/>
            </author>
            <author initials="L." surname="Valenta" fullname="Luke Valenta">
              <organization/>
            </author>
            <author initials="D." surname="Adrian" fullname="David Adrian">
              <organization/>
            </author>
            <author initials="J." surname="Halderman" fullname="J. Alex Halderman">
              <organization/>
            </author>
            <author initials="V." surname="Dukhovni" fullname="Viktor Dukhovni">
              <organization/>
            </author>
            <author initials="E." surname="Käsper" fullname="Emilia Käsper">
              <organization/>
            </author>
            <author initials="S." surname="Cohney" fullname="Shaanan Cohney">
              <organization/>
            </author>
            <author initials="S." surname="Engels" fullname="Susanne Engels">
              <organization/>
            </author>
            <author initials="C." surname="Paar" fullname="Christof Paar">
              <organization/>
            </author>
            <author initials="Y." surname="Shavitt" fullname="Yuval Shavitt">
              <organization/>
            </author>
            <date month="August" year="2016"/>
          </front>
          <seriesInfo name="25th
          <refcontent>25th USENIX Security Symposium (USENIX Security 16)" value=""/> 16)</refcontent>
        </reference>

        <reference anchor="RACCOON" target="https://www.usenix.org/conference/usenixsecurity21/presentation/merget">
          <front>
            <title>Raccoon Attack: Finding and Exploiting Most-Significant-Bit-Oracles in TLS-DH(E)</title>
            <author initials="R." surname="Merget" fullname="Robert Merget">
              <organization/>
            </author>
            <author initials="M." surname="Brinkmann" fullname="Marcus Brinkmann">
              <organization/>
            </author>
            <author initials="N." surname="Aviram" fullname="Nimrod Aviram">
              <organization/>
            </author>
            <author initials="J." surname="Somorovsky" fullname="Juraj Somorovsky">
              <organization/>
            </author>
            <author initials="J." surname="Mittmann" fullname="Johannes Mittmann">
              <organization/>
            </author>
            <author initials="J." surname="Schwenk" fullname="Jörg Schwenk">
              <organization/>
            </author>
            <date year="2021"/>
          </front>
          <seriesInfo name="30th
          <refcontent>30th USENIX Security Symposium (USENIX Security 21)" value=""/> 21)</refcontent>
        </reference>

        <reference anchor="Antipa2003"> anchor="Antipa2003" target="https://doi.org/10.1007/3-540-36288-6_16">
          <front>
            <title>Validation of Elliptic Curve Public Keys</title>
            <author initials="A." surname="Antipa" fullname="Adrian Antipa">
              <organization/>
            </author>
            <author initials="D. R. L." surname="Brown" fullname="Daniel R. L. Brown">
              <organization/>
            </author>
            <author initials="A." surname="Menezes" fullname="Alfred Menezes">
              <organization/>
            </author>
            <author initials="R." surname="Struik" fullname="Rene Struik">
              <organization/>
            </author>
            <author initials="S. A." initials="S." surname="Vanstone" fullname="Scott A. Vanstone">
              <organization/>
            </author>
            <date month="December" year="2003"/>
          </front>
          <seriesInfo name="Public
          <refcontent>Public Key Cryptography - PKC 2003" value=""/> 2003</refcontent>
        </reference>

        <reference anchor="Jager2015">
          <front>
            <title>Practical Invalid Curve Attacks on TLS-ECDH</title>
            <author fullname="Tibor Jager" initials="T." surname="Jager">
              <organization/>
            </author>
            <author fullname="Jörg Schwenk" initials="J." surname="Schwenk">
              <organization/>
            </author>
            <author fullname="Juraj Somorovsky" initials="J." surname="Somorovsky">
              <organization/>
            </author>
            <date year="2015"/>
          </front>
          <seriesInfo name="Computer
          <refcontent>Computer Security -- ESORICS 2015" value="pp. 407-425"/> 2015, pp. 407-425</refcontent>
          <seriesInfo name="DOI" value="10.1007/978-3-319-24174-6_21"/>
        </reference>

        <reference anchor="SAFECURVES" target="https://safecurves.cr.yp.to">
          <front>
            <title>SafeCurves: Choosing Safe Curves choosing safe curves for Elliptic-Curve Cryptography</title> elliptic-curve cryptography</title>
            <author initials="D. J." surname="Bernstein" fullname="Daniel J. Bernstein">
              <organization/>
            </author>
            <author initials="T." surname="Lange" fullname="Tanja Lange">
              <organization/>
            </author>
            <date year="2014" month="December"/>
          </front>
        </reference>

	<reference anchor="Poddebniak2017" target="https://eprint.iacr.org/2017/1014.pdf">
          <front>
            <title>Attacking Deterministic Signature Schemes using Fault Attacks</title>
            <author initials="D." surname="Poddebniak" fullname="Damian Poddebniak">
              <organization/>
            </author>
            <author initials="J." surname="Somorovsky" fullname="Juraj Somorovsky">
              <organization/>
            </author>
            <author initials="S." surname="Schinzel" fullname="Sebastian Schinzel">
              <organization/>
            </author>
            <author initials="M." surname="Lochter" fullname="Manfred Lochter">
              <organization/>
            </author>
            <author initials="P." surname="Rösler" fullname="Paul Rösler">
              <organization/>
            </author>
            <date year="2017"/> month="April" year="2018"/>
          </front>
	  <refcontent>Conference: 2018 IEEE European Symposium on Security and Privacy</refcontent>
	   <seriesInfo name="DOI" value="10.1109/EuroSP.2018.00031"/>
        </reference>

        <reference anchor="Kim2014" target="https://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf">
          <front>
            <title>Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors</title>
            <author initials="Y." surname="Kim" fullname="Yoongu Kim">
              <organization/>
            </author>
            <author initials="R." surname="Daly" fullname="Ross Daly">
              <organization/>
            </author>
            <author initials="J." surname="Kim" fullname="Jeremie Kim">
              <organization/>
            </author>
            <author initials="C." surname="Fallin" fullname="Chris Fallin">
              <organization/>
            </author>
            <author initials="J. H." surname="Lee" fullname="Ji Jye Lee">
              <organization/>
            </author>
            <author initials="D." surname="Lee" fullname="Donghyuk Lee">
              <organization/>
            </author>
            <author initials="C." surname="Wilkerson" fullname="Chris Wilkerson">
              <organization/>
            </author>
            <author initials="K." surname="Lai" fullname="Konrad Lai">
              <organization/>
            </author>
            <author initials="O." surname="Mutlu" fullname="Onur Mutlu">
              <organization/>
            </author>
            <date month="July" year="2014"/>
          </front>
        </reference>
        <reference anchor="RFC9051" target="https://www.rfc-editor.org/info/rfc9051">
          <front>
            <title>Internet Message Access Protocol (IMAP) - Version 4rev2</title>
            <author fullname="A. Melnikov" initials="A." role="editor" surname="Melnikov">
              <organization/>
            </author>
            <author fullname="B. Leiba" initials="B." role="editor" surname="Leiba">
              <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 that is functionally equivalent to local folders.  IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. </t>
              <t>IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; removing messages permanently; setting and clearing flags; parsing per RFCs 5322, 2045, and 2231; searching; and selective fetching of message attributes, texts, and portions thereof.  Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. </t>
              <t>IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified in RFC 6409.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9051"/>
	   <seriesInfo name="DOI" value="10.17487/RFC9051"/> value="10.1109/ISCA.2014.6853210"/>
     </reference>

        <referencegroup anchor="STD53" target="https://www.rfc-editor.org/info/std53">
          <reference anchor="RFC1939" target="https://www.rfc-editor.org/info/rfc1939">
            <front>
              <title>Post Office Protocol - Version 3</title>
              <author fullname="J. Myers" initials="J" surname="Myers"/>
              <author fullname="M. Rose" initials="M" surname="Rose"/>
              <date month="May" year="1996"/>
              <abstract>
                <t>The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion. [STANDARDS-TRACK]</t>
              </abstract>
            </front>
            <seriesInfo name="STD" value="53"/>
            <seriesInfo name="RFC" value="1939"/>
            <seriesInfo name="DOI" value="10.17487/RFC1939"/>
          </reference>
        </referencegroup>
        <reference anchor="RFC3261" target="https://www.rfc-editor.org/info/rfc3261">
          <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 application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants.  These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.  [STANDARDS-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/rfc5321">
          <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 Internet electronic mail transport.  It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete.  It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions.  Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use

<!--draft-ietf-tls-esni-15; I-D exists as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments.  [STANDARDS-TRACK]</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/rfc6120">
          <front>
            <title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
            <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 application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities.  This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-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/rfc9000">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar">
              <organization/>
            </author>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson">
              <organization/>
            </author>
            <date month="May" year="2021"/>
            <abstract>
              <t>This document defines the core of 11/15/22-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.draft-ietf-tls-esni.xml"/>

<!--[rfced] FYI: draft-mattsson-cfrg-det-sigs-with-noise-04 was
replaced by draft-irtf-cfrg-det-sigs-with-noise-00, so we updated
the QUIC transport protocol.  QUIC provides applications with flow-controlled streams entry for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances.  Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion 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/rfc3602">
          <front>
            <title>The AES-CBC Cipher Algorithm [CFRG-DET-SIGS] accordingly.

Original:
   [I-D.mattsson-cfrg-det-sigs-with-noise]
              Mattsson, J. P., Thormarker, E., and S. Ruohomaa,
              "Deterministic ECDSA and Its Use EdDSA Signatures 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 Standard (AES) Cipher Algorithm Additional
              Randomness", Work in Cipher Block Chaining (CBC) Mode, with an explicit 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/rfc7457">
          <front>
            <title>Summarizing Known Attacks on Transport Layer Security (TLS) and 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 attacks on Transport Layer Security (TLS), including attacks on its most commonly used ciphers 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>.

Updated:
   [CFRG-DET-SIGS]
              Preuß Mattsson, J., Thormarker, E., and S. Ruohomaa,
              "Deterministic ECDSA and modes of operation.  This document summarizes these attacks, EdDSA Signatures with the 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/rfc7525">
          <front>
            <title>Recommendations for Secure Use of Transport Layer Security (TLS) 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 Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP.  Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation.  This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The 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/rfc4949">
          <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 explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow 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, dictionary 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/rfc6101">
          <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 over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  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/rfc2246">
          <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 Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. 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/rfc4346">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.1</title>
            <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 Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  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="4346"/>
          <seriesInfo name="DOI" value="10.17487/RFC4346"/>
        </reference>
        <reference anchor="RFC4347" target="https://www.rfc-editor.org/info/rfc4347">
          <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 Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate Additional
              Randomness", Work in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying 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/rfc7507">
          <front>
            <title>TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing 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) that 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/rfc6797">
          <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 declare themselves accessible only via secure connections and/or for users to be able 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 Security (HSTS).  The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or 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 other means, such draft-irtf-cfrg-det-sigs-with-noise-00; I-D exists as user agent configuration, 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/rfc8461">
          <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="Ramakrishnan">
              <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 enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted 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/rfc6698">
          <front>
            <title>The DNS-Based Authentication of Named Entities (DANE) Transport 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 Layer Security (TLS), which depends on third parties to certify the keys used.  This document improves on that situation by enabling the administrators of domain names to specify the keys 11/15/22. Long way used in that domain's TLS servers.  This requires matching 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/rfc7712">
          <front>
            <title>Domain Name Associations (DNA) in the Extensible Messaging and 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 domain name (e.g., example.com) to a target server hostname (e.g., hosting.example.net); this is especially important in multi-tenanted environments where the same target 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/rfc9191">
          <front>
            <title>Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods</title>
            <author fullname="M. Sethi" initials="M." surname="Sethi">
              <organization/>
            </author>
            <author fullname="J. correctly display "John Preuß Mattsson" initials="J." surname="Preuß Mattsson">
              <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 3748, provides a standard mechanism for support of multiple authentication methods. EAP-TLS and other TLS-based EAP methods are widely deployed and used for network access authentication. Large certificates and long certificate chains combined 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 describes 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/rfc8879">
          <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 majority of the bytes transmitted.</t>
              <t>This document describes how certificate chains can be compressed 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/rfc7924">
          <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 certification authorities (CAs).  This information can be of considerable size, particularly 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 already 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/rfc5077">
          <front>
            <title>Transport Layer Security (TLS) Session Resumption without Server-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 session state.  The TLS server encapsulates the session state into a ticket and forwards it to the client.  The client can subsequently resume a session using the obtained 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/archive/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 Security (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
   https://github.com/tlswg/draft-ietf-tls-esni
   (https://github.com/tlswg/draft-ietf-tls-esni).

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-14"/>
        </reference>
        <reference anchor="RFC8470" target="https://www.rfc-editor.org/info/rfc8470">
          <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 communicate with servers about HTTP requests that are sent in early data.  Techniques are 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/rfc9001">
          <front>
            <title>Using TLS to Secure QUIC</title>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson">
              <organization/>
            </author>
            <author fullname="S. Turner" initials="S." role="editor" surname="Turner">
              <organization/>
            </author>
            <date month="May" year="2021"/>
            <abstract>
              <t>This document describes how Transport Layer Security (TLS) is used 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/rfc7919">
          <front>
            <title>Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for 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 security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and 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 finite field DH parameters with known structure and a mechanism for peers to negotiate support for these groups.</t>
              <t>This document updates TLS versions 1.0 (RFC 2246), 1.1 (RFC 4346), and 1.2 (RFC 5246), as well as the TLS Elliptic Curve Cryptography (ECC) extensions (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/rfc5116">
          <front>
            <title>An Interface and Algorithms for Authenticated Encryption</title>
            <author fullname="D. McGrew" initials="D." surname="McGrew">
              <organization/>
            </author>
            <date month="January" year="2008"/>
            <abstract>
              <t>This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms.  The interface and registry can be used as an application-independent set of cryptoalgorithm suites.  This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations.  [STANDARDS-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"> anchor="I-D.mattsson-cfrg-det-sigs-with-noise">
<front>
            <title>Deterministic
<title>
Deterministic ECDSA and EdDSA Signatures with Additional Randomness</title> Randomness
</title>
<author initials="J" surname="Preuß Mattsson" fullname="John Preuß Mattsson">
              <organization>Ericsson</organization>
</author>
<author initials="E" surname="Thormarker" fullname="Erik Thormarker">
              <organization>Ericsson</organization>
</author>
<author initials="S" surname="Ruohomaa" fullname="Sini Ruohomaa">
              <organization>Ericsson</organization>
            </author>
            <date day="15" month="February" year="2022"/>
            <abstract>
              <t>   Deterministic elliptic-curve signatures such as deterministic 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.org/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) algorithm
   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>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-aead-limits-05"/>
        </reference>
        <reference anchor="RFC7590" target="https://www.rfc-editor.org/info/rfc7590">
          <front>
            <title>Use of Transport Layer Security (TLS) in the Extensible Messaging 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/rfc2026">
          <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 the standardization process, the requirements for moving a document between stages and the types of documents used during this process. 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="9"/>
          <seriesInfo name="RFC" value="2026"/>
          <seriesInfo name="DOI" value="10.17487/RFC2026"/>
        </reference>
        <reference anchor="RFC7228" target="https://www.rfc-editor.org/info/rfc7228">
          <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 devices 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/rfc7925">
          <front>
            <title>Transport Layer Security (TLS) / Datagram Transport Layer Security (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 actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments.</t>
              <t>This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery.  The lack of communication security is a common vulnerability in IoT 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.ietf.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" month="August" day="8" year="2022"/>
            <abstract>
              <t>   This document is a companion to RFC 7925 and defines TLS/DTLS 1.3
   profiles for Internet of Things devices.  It also updates RFC 7925
   with regards to the X.509 certificate profile.

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
   https://github.com/thomas-fossati/draft-tls13-iot.

              </t>
            </abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-uta-tls13-iot-profile-05"/>
        </reference>
        <reference anchor="RFC7435" target="https://www.rfc-editor.org/info/rfc7435">
          <front>
            <title>Opportunistic Security: Some Protection Most of the Time</title>
            <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 the context of communications protocols.  Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption 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/rfc5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate 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 certificate revocation list (CRL) for use in the Internet.  An overview of this approach and model is provided as an introduction.  The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms.  Standard certificate extensions are described and two Internet-specific extensions are defined.  A set of required certificate extensions is specified.  The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions.  An algorithm for X.509 certification path validation is described.  An ASN.1 module and examples are provided in the 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/rfc8452">
          <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 that 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/rfc9162">
          <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 Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The 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 the 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 operations 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"/> value="draft-irtf-cfrg-det-sigs-with-noise-00"/>
</reference>
        <reference anchor="RFC6960" target="https://www.rfc-editor.org/info/rfc6960">
          <front>
            <title>X.509 Internet Public Key Infrastructure Online Certificate Status 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 current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents.  This document obsoletes RFCs 2560 and 6277.  It 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/rfc7633">
          <front>
            <title>X.509v3 Transport Layer Security (TLS) Feature Extension</title>
            <author fullname="P. Hallam-Baker" initials="P." surname="Hallam-Baker">
              <organization/>
            </author>
            <date month="October" year="2015"/>
            <abstract>
              <t>The purpose of the TLS feature extension is to prevent downgrade 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

<!--draft-irtf-cfrg-aead-limits-05; I-D exists 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.  This 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/rfc6961">
          <front>
            <title>The Transport Layer Security (TLS) Multiple Certificate Status 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) Certificate Status Version 2 Extension to allow clients to specify and support several certificate status methods.  (The use of the Certificate Status extension is commonly referred to 11/15/22-->
<xi:include                                                                                         href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.draft-irtf-cfrg-aead-limits.xml"/>

<!--draft-ietf-uta-tls13-iot-profile-05; I-D exists as "OCSP stapling".)  Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status 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> 11/15/22-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.draft-ietf-uta-tls13-iot-profile.xml"/>
</references>
    </references>
    <section anchor="diff-rfc">
      <name>Differences from RFC 7525</name>
      <t>This revision of the Best Current Practices contains numerous changes, and this section is focused
on the normative changes.</t>
      <ul spacing="normal">
        <li>
          <t>High level
          <t>High-level differences:
          </t>
          <ul spacing="normal">
            <li>Described the expectations from new TLS-incorporating transport protocols and from new application protocols layered on TLS.</li>
            <li>Clarified items (e.g. (e.g., renegotiation) that only apply to TLS 1.2.</li>
            <li>Changed the status of TLS 1.0 and 1.1 from <bcp14>SHOULD NOT</bcp14> "<bcp14>SHOULD NOT</bcp14>" to <bcp14>MUST NOT</bcp14>.</li> "<bcp14>MUST NOT</bcp14>".</li>
            <li>Added TLS 1.3 at a <bcp14>SHOULD</bcp14> "<bcp14>SHOULD</bcp14>" level.</li>
            <li>Similar
            <li>Made similar changes to DTLS.</li>
            <li>Specific
            <li>Included specific guidance for multiplexed protocols.</li>
            <li>
              <bcp14>MUST</bcp14>-level implementation requirement for ALPN, ALPN and more specific <bcp14>SHOULD</bcp14>-level guidance for ALPN and SNI.</li>
            <li>Clarified discussion of strict TLS policies, including <bcp14>MUST</bcp14>-level recommendations.</li>
            <li>Limits on key usage.</li>
            <li>New attacks since <xref target="RFC7457"/>: ALPACA, Raccoon, Logjam, and "Nonce-Disrespecting Adversaries".</li>
            <li>RFC 6961 (OCSP status_request_v2) has been deprecated.</li>
            <li>
              <bcp14>MUST</bcp14>-level requirement for server-side RSA certificates to have a 2048-bit modulus at a minimum, replacing a <bcp14>SHOULD</bcp14>.</li> "<bcp14>SHOULD</bcp14>".</li>
          </ul>
        </li>
        <li>
          <t>Differences specific to TLS 1.2:
          </t>
          <ul spacing="normal">
            <li>
              <bcp14>SHOULD</bcp14>-level guidance on AES-GCM nonce generation.</li>
            <li>
              <bcp14>SHOULD NOT</bcp14> use (static or ephemeral) finite-field DH key agreement.</li>
            <li>
              <bcp14>SHOULD NOT</bcp14> reuse ephemeral finite-field DH keys across multiple connections.</li>
            <li>
              <bcp14>SHOULD NOT</bcp14> use static elliptic curve Elliptic Curve DH key exchange.</li>
            <li>2048-bit DH is now a <bcp14>MUST</bcp14>, "<bcp14>MUST</bcp14>" and ECDH minimal curve size is 224, vs. 224 (vs. 192 previously.</li> previously).</li>
            <li>Support for <tt>extended_master_secret</tt> is now a <bcp14>MUST</bcp14> "<bcp14>MUST</bcp14>" (previously it was a soft recommendation, as the RFC had not been published at the time). Also removed other, more complicated, related mitigations.</li>
            <li>
              <bcp14>MUST</bcp14>-level restriction on session ticket validity, replacing a <bcp14>SHOULD</bcp14>.</li> "<bcp14>SHOULD</bcp14>".</li>
            <li>
              <bcp14>SHOULD</bcp14>-level restriction on the TLS session duration, depending on the rotation period of an <xref target="RFC5077"/> ticket key.</li>
            <li>Drop
            <li>Dropped TLS_DHE_RSA_WITH_AES from the recommended ciphers</li>
            <li>Add ciphers.</li>
            <li>Added TLS_ECDHE_ECDSA_WITH_AES to the recommended ciphers</li> ciphers.</li>
            <li>
              <bcp14>SHOULD NOT</bcp14> use the old MTI cipher suite, TLS_RSA_WITH_AES_128_CBC_SHA.</li>
            <li>Recommend
            <li>Recommended curve X25519 alongside NIST P-256</li> P-256.</li>
          </ul>
        </li>
        <li>
          <t>Differences specific to TLS 1.3:
          </t>
          <ul spacing="normal">
            <li>New TLS 1.3 capabilities: 0-RTT.</li>
            <li>Removed capabilities: renegotiation, renegotiation and compression.</li>
            <li>Added mention of TLS Encrypted Client Hello, but no recommendation to for use until it is finalized.</li>
            <li>
              <bcp14>SHOULD</bcp14>-level requirement for forward secrecy in TLS 1.3 session resumption.</li>
            <li>Generic <bcp14>SHOULD</bcp14>-level <bcp14>MUST</bcp14>-level guidance to avoid 0-RTT unless it is documented for the particular protocol.</li>
          </ul>
        </li>
      </ul>
    </section>

    <section anchor="document-history">
      <name>Document History</name>
      <t><cref>Note numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>Thanks to RFC Editor: please remove before publication.</cref></t>
      <section anchor="draft-ietf-uta-rfc7525bis-11">
        <name>draft-ietf-uta-rfc7525bis-11</name>
        <ul spacing="normal">
          <li>Addressed outstanding comments by Peter Gutmann.</li>
        </ul>
      </section>
      <section anchor="draft-ietf-uta-rfc7525bis-10">
        <name>draft-ietf-uta-rfc7525bis-10</name>
        <ul spacing="normal">
          <li>Addressed IESG feedback, ARTART review by Cullen Jennings, and TSVART review by Magnus Westerlund.</li>
          <li>Improved the rationale for still recommending TLS 1.2.</li>
          <li>Specified TLS 1.3 as a <bcp14>MUST</bcp14> for new transport protocols
<contact fullname="Alexey Melnikov"/>,
<contact fullname="Alvaro Retana"/>,
<contact fullname="Andrei Popov"/>,
<contact fullname="Ben Kaduk"/>,
<contact fullname="Christian Huitema"/>,
<contact fullname="Corey Bonnell"/>,
<contact fullname="Cullen Jennings"/>,
<contact fullname="Daniel Kahn Gillmor"/>,
<contact fullname="David Benjamin"/>,
<contact fullname="Eric Rescorla"/>,
<contact fullname="Éric Vyncke"/>,
<contact fullname="Francesca Palombini"/>,
<contact fullname="Hannes Tschofenig"/>,
<contact fullname="Hubert Kario"/>,
<contact fullname="Ilari Liusvaara"/>,
<contact fullname="John Preuß Mattsson"/>,
<contact fullname="John R. Levine"/>,
<contact fullname="Julien Élie"/>,
<contact fullname="Lars Eggert"/>,
<contact fullname="Leif Johansson"/>,
<contact fullname="Magnus Westerlund"/>,
<contact fullname="Martin Duke"/>,
<contact fullname="Martin Thomson"/>,
<contact fullname="Mohit Sahni"/>,
<contact fullname="Nick Sullivan"/>,
<contact fullname="Nimrod Aviram"/>,
<contact fullname="Paul Wouters"/>,
<contact fullname="Peter Gutmann"/>,
<contact fullname="Rich Salz"/>,
<contact fullname="Robert Sayre"/>,
<contact fullname="Robert Wilton"/>,
<contact fullname="Roman Danyliw"/>,
<contact fullname="Ryan Sleevi"/>,
<contact fullname="Sean Turner"/>,
<contact fullname="Stephen Farrell"/>,
<contact fullname="Tim Evans"/>,
<contact fullname="Valery Smyslov"/>,
<contact fullname="Viktor Dukhovni"/>,
and a <bcp14>SHOULD</bcp14> for new application protocols.</li>
          <li>Clarified TLS-only vs. dynamic upgrade <contact fullname="Warren Kumari"/>
for non-HTTP protocols.</li>
          <li>Clarified distinction between implementation helpful comments and deployment.</li>
          <li>Clarified applicability to QUIC.</li>
          <li>Further specified what to do on reaching discussions that have shaped this document.</t>
      <t>The authors gratefully acknowledge the confidentiality limit or integrity limit.</li>
          <li>Added contribution of <contact fullname="Ralph Holz"/>, who was a note about post-quantum cryptography.</li>
          <li>Improved the text about Encrypted Client Hello.</li>
        </ul>
      </section>
      <section anchor="draft-ietf-uta-rfc7525bis-09">
        <name>draft-ietf-uta-rfc7525bis-09</name>
        <ul spacing="normal">
          <li>More background on strict TLS for non-HTTP protocols.</li>
        </ul>
      </section>
      <section anchor="draft-ietf-uta-rfc7525bis-08">
        <name>draft-ietf-uta-rfc7525bis-08</name>
        <ul spacing="normal">
          <li>Addressed SecDir review by Ben Kaduk.</li>
          <li>Addressed reviews by Stephen Farrell, Martin Thomson, Tim Evans and John Mattsson.</li>
        </ul>
      </section>
      <section anchor="draft-ietf-uta-rfc7525bis-07">
        <name>draft-ietf-uta-rfc7525bis-07</name>
        <ul spacing="normal">
          <li>Addressed AD reviews by Francesca and Paul.</li>
        </ul>
      </section>
      <section anchor="draft-ietf-uta-rfc7525bis-06">
        <name>draft-ietf-uta-rfc7525bis-06</name>
        <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 finite field DH cipher suites.</li>
              <li>Revamped the recommended TLS 1.2 cipher suites, removing DHE and adding ECDSA. The latter due to the wide adoption coauthor of ECDSA certificates and in line with RFC 8446.</li>
              <li>Recommendation to use deterministic ECDSA.</li>
              <li>Finally deprecated 7525, the old TLS 1.2 MTI cipher suite.</li>
              <li>Deeper discussion of ECDH public key reuse issues, and as a result, recommended support previous version of X25519.</li>
              <li>Reworded the section on certificate revocation and OCSP following 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 TLS 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 recommendations.</t>
      <t>See RFC 7525 for ALPN, and more additional acknowledgments specific <bcp14>SHOULD</bcp14>-level guidance for ALPN and SNI.</li>
              <li>Generic <bcp14>SHOULD</bcp14>-level guidance to avoid 0-RTT unless 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 previous version 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 editorial
changes to the references.</li>
        </ul>
      </section> TLS recommendations.</t>
    </section>
  </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>