<?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.7.27 (Ruby 3.3.6) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-uta-require-tls13-12" number="9852" category="bcp" consensus="true" submissionType="IETF" updates="9325" obsoletes="" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.28.1 --> version="3" xml:lang="en">

  <front>
    <title abbrev="require-tls1.3">New abbrev="New Protocols Using TLS Must Require TLS 1.3">New Protocols Using TLS Must Require TLS 1.3</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-uta-require-tls13-12"/> name="RFC" value="9852"/>
    <seriesInfo name="BCP" value="195"/>
    <author fullname="Rich Salz">
      <organization>Akamai Technologies</organization>
      <address>
        <email>rsalz@akamai.com</email>
      </address>
    </author>
    <author fullname="Nimrod Aviram">
      <organization/>
      <address>
        <email>nimrod.aviram@gmail.com</email>
      </address>
    </author>
    <date year="2025" month="April" day="14"/> year="2026" month="January"/>
    <area>Security</area>
    <workgroup>Using TLS in Applications</workgroup>

    <keyword>TLS</keyword>
    <keyword>TLS Transition</keyword>
    <keyword>TLS Support</keyword>
    <keyword>Interoperability</keyword>
    <keyword>features</keyword>

    <abstract>
      <?line 123?>

<t>TLS 1.3 use is widespread, it widely used, has had comprehensive security proofs, and it
improves both security and privacy over deficiencies in TLS 1.2.  Therefore, new protocols
that use TLS must require TLS 1.3.  As DTLS 1.3 is not widely available or
deployed, this prescription does not pertain to DTLS (in any DTLS version);
it pertains to TLS only.</t>
      <t>This document updates RFC9325 and RFC 9325. It discusses post-quantum cryptography and the
security and privacy improvements over in TLS 1.2 1.3 as a the rationale for that the update.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-uta-require-tls13/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Using TLS in Applications Working Group mailing list (<eref target="mailto:uta@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/uta/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/uta/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/richsalz/draft-use-tls13"/>.</t>
    </note>

  </front>
  <middle>
    <?line 134?>

    <section anchor="sec-reasons">
      <name>Introduction</name>

     <t>This document specifies that, since TLS 1.3 use is widespread, that new protocols
that use TLS must require and assume that TLS 1.3 is available and require its existence.  It updates <xref target="RFC9325"/>
as described in <xref target="rfc9325-updates"/>. use.
As DTLS 1.3 is not widely available or
deployed, this prescription does not pertain to DTLS (in any DTLS version);
it pertains to TLS only.</t>
      <t>TLS 1.3 <xref target="TLS13"/> target="RFC9846"/> is in widespread use and fixes most known deficiencies with
TLS 1.2.  Examples of this include encrypting more of the traffic so that it
is not readable by outsiders and removing most cryptographic primitives
now considered weak. Importantly, the protocol has had comprehensive
security proofs and should provide excellent security without any additional
configuration.</t>
      <t>TLS 1.2 <xref target="TLS12"/> target="RFC5246"/> is in use and can be configured such that it provides good
security properties.  However, TLS 1.2 suffers from several deficiencies, as
described in <xref target="sec-considerations"/>.  Addressing them usually requires
      bespoke configuration.</t>

      <t>This document updates RFC9325 and <xref target="RFC9325"/>. It discusses post-quantum cryptography
and fixed weaknesses the security and privacy improvements in TLS 1.2 1.3 as a the rationale for that update.</t> the update. See <xref target="rfc9325-updates"/>.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The anchor="conventions">
      <name>Conventions</name>
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>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 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t>
      <?line -18?> here.
        </t>
    </section>
    <section anchor="implications-for-post-quantum-cryptography-pqc">
      <name>Implications for post-quantum cryptography Post-Quantum Cryptography (PQC)</name>
      <t>Cryptographically-relevant quantum computers (CRQC),
      <t>Cryptographically Relevant Quantum Computers (CRQCs), once available, will
have a huge impact on TLS traffic (see, e.g., <xref section="2" sectionFormat="of" target="I-D.ietf-pquip-pqc-engineers"/>).  To mitigate this, TLS applications will
need to migrate to Post-Quantum Cryptography (PQC) <xref target="PQC"/>.  Detailed
considerations of when an application requires PQC or when a CRQC is a threat
that an application need needs to protect against, against are beyond the scope of this
      document.</t>
      <t>For TLS it

      <t>It is important to note that the focus of these efforts within
the
TLS WG Working Group is focusing its efforts on TLS 1.3
or later, and that later; TLS 1.2 will not be supported (see <xref target="TLS12FROZEN"/>). target="RFC9851"/>).
This is one more reason for new protocols to require TLS to default to TLS 1.3,
where
PQC is actively being standardized, as this gives new applications
the option to use PQC.</t>
    </section>
    <section anchor="tls-use-by-other-protocols-and-applications">
      <name>TLS Use by Other Protocols and Applications</name>
      <t>Any new protocol that uses TLS <bcp14>MUST</bcp14> specify TLS 1.3 as its default TLS 1.3. default.
For example, QUIC <xref target="QUICTLS"/> target="RFC9001"/> requires TLS 1.3 and specifies that endpoints
<bcp14>MUST</bcp14> terminate the connection if an older version is used.</t>
      <t>If deployment considerations are a concern, the protocol <bcp14>MAY</bcp14> specify TLS 1.2 as
an additional, non-default option.
As a counter example, the Usage Profile for DNS over TLS <xref target="DNSTLS"/> target="RFC8310"/> specifies
TLS 1.2 as the default, while also allowing TLS 1.3.
For newer specifications that choose to support TLS 1.2, those preferences are
      to be reversed.</t>

      <t>The initial TLS handshake allows a client to specify which versions of the
TLS protocol it supports supports, and the server is intended to pick the highest
version that it also supports.  This is known as the "TLS version
negotiation," and
negotiation"; protocol and negotiation details are discussed in <xref section="4.2.1" sectionFormat="comma" target="TLS13"/> sectionFormat="of" target="RFC9846"/> and <xref section="E" sectionFormat="comma" target="TLS12"/>. sectionFormat="of" target="RFC5246"/>.  Many TLS libraries provide a way
for applications to specify the range of versions they want, including an
      open interval where only the lowest or highest version is specified.</t>

      <t>If the application is using a TLS implementation that supports this, TLS version negotiation
and if it knows that the TLS implementation will use the highest version
supported, then
clients <bcp14>SHOULD</bcp14> specify just the minimum version they want.
This <bcp14>MUST</bcp14> be TLS 1.3 or TLS 1.2, depending on the circumstances described
in the above paragraphs.</t>
    </section>
    <section anchor="rfc9325-updates">
      <name>Changes to RFC 9325</name>

      <t><xref target="RFC9325"/> provides recommendations for ensuring the security of deployed
services that use TLS and, unlike this document, DTLS as well.
At the time it was published, it described availability of
<xref target="RFC9325"/> describes TLS 1.3
as "widely available." The transition available", and adoption mentioned in that
document the transition to TLS 1.3 has grown, and this further increased since publication of that document.
This document now thus makes two changes
to the recommendations in <xref section="3.1.1" sectionFormat="comma" sectionFormat="of" target="RFC9325"/>:</t>
      <ul spacing="normal">
        <li>
          <t>That section says that TLS 1.3 <bcp14>SHOULD</bcp14> be supported; this document mandates
that TLS 1.3 <bcp14>MUST</bcp14> be supported for new TLS-using protocols.</t> protocols using TLS.</t>
        </li>
        <li>
          <t>That section says that TLS 1.2 <bcp14>MUST</bcp14> be supported; this document says that
TLS 1.2 <bcp14>MAY</bcp14> be supported as described above.</t>
        </li>
      </ul>
      <t>Again, these changes only apply to TLS, and not DTLS.</t>
    </section>
    <section anchor="sec-considerations">
      <name>Security Considerations</name>
      <t>TLS 1.2 was specified with several cryptographic primitives and design choices
that have, over time, become significantly weaker. The purpose of this section is to
briefly survey several such prominent problems that have affected the protocol.
It should be noted, however, that TLS 1.2 can be configured securely; it is
merely much more difficult to configure it securely as opposed to using its
modern successor, TLS 1.3. See <xref target="RFC9325"/> for a more thorough guide on the
      secure deployment of TLS 1.2.</t>
      <t>Firstly, the TLS 1.2 protocol,

      <t>First, without any extensions, TLS 1.2 is vulnerable to
renegotiation attacks (see <xref target="RENEG1"/> and <xref target="RENEG2"/>)  and the
Triple Handshake attack (see <xref target="TRIPLESHAKE"/>).
Broadly, these attacks
exploit the protocol's support for renegotiation in order to inject a prefix
chosen by the attacker into the plaintext stream. This is usually a devastating
threat in practice, that practice (e.g., it allows e.g. obtaining an attacker to obtain secret cookies in a web setting. setting).
In light of
the above problems, <xref target="RFC5746"/> specifies an extension that prevents this
category of attacks. To securely deploy TLS 1.2, either renegotiation must be
disabled entirely, or this extension must be used. Additionally, clients must
      not allow servers to renegotiate the certificate during a connection.</t>
      <t>Secondly,

      <t>Second, the original key exchange methods specified for the protocol, TLS 1.2, namely
RSA key exchange and finite field Diffie-Hellman, suffer from several
weaknesses. Similarly, to To securely deploy the protocol,
most of these key exchange
methods must be disabled.
      See <xref target="I-D.ietf-tls-deprecate-obsolete-kex"/> for details.</t>
      <t>Thirdly,

      <t>Third, symmetric ciphers which were widely-used that are widely used in the protocol, TLS 1.2, namely RC4
and CBC Cipher Block Chaining (CBC) cipher suites, suffer from several weaknesses. RC4 suffers from
exploitable biases in its key stream; see <xref target="RFC7465"/>. CBC cipher suites have
been a source of vulnerabilities throughout the years. A straightforward
implementation of these cipher suites inherently suffers from the Lucky13 timing
attack <xref target="LUCKY13"/>. The first attempt to implement the cipher suites in
constant time introduced an even more severe vulnerability <xref target="LUCKY13FIX"/>.
There have been further similar vulnerabilities throughout the
years exploiting CBC cipher suites; refer to, e.g.,
Refer to <xref target="CBCSCANNING"/>
for an another example of a vulnerability with CBC cipher suites and a survey of similar works.</t>
      <t>In addition, TLS 1.2 was affected by several other attacks that
TLS 1.3 is immune to:
BEAST <xref target="BEAST"/>, Logjam <xref target="WEAKDH"/>, FREAK <xref target="FREAK"/>, and SLOTH <xref target="SLOTH"/>.</t>
      <t>And finally,
      <t>Finally, while
application layer
application-layer traffic in TLS 1.2 is always encrypted, most of the content of the handshake
messages are is not. Therefore, the privacy provided is suboptimal.
This is a protocol issue that cannot be addressed by configuration.</t>
    </section>
    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>This document makes has no requests to IANA.</t> IANA actions.</t>
    </section>
  </middle>
  <back>

    <displayreference target="I-D.ietf-tls-deprecate-obsolete-kex" to="KEY-EXCHANGE"/>
    <displayreference target="I-D.ietf-pquip-pqc-engineers" to="PQC-FOR-ENGINEERS"/>
    <displayreference target="RFC5246" to="TLS12"/>
    <displayreference target="RFC9846" to="TLS13"/>
    <displayreference target="RFC9851" to="TLS12FROZEN"/>
    <displayreference target="RFC9001" to="QUICTLS"/>
    <displayreference target="RFC8310" to="DNSTLS"/>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="TLS12">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
            <author fullname="T. Dierks" initials="T." surname="Dierks"/>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2008"/>
            <abstract>
              <t>This document specifies Version 1.2
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>

<!-- [RFC9846 / TLS13]
draft-ietf-tls-rfc8446bis-14
companion doc RFC 9846
AUTH48 state as 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> 1/5/2026
-->
        <reference anchor="TLS13"> anchor="RFC9846" target="https://www.rfc-editor.org/info/rfc9846">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="Eric Rescorla" initials="E." surname="Rescorla"> surname="Rescorla" fullname="Eric Rescorla">
              <organization>Independent</organization>
            </author>
            <date day="17" month="February" year="2025"/>
            <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.

   This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes
   RFCs 5077, 5246, 6961, 8422, and 8446.  This document also specifies
   new requirements for TLS 1.2 implementations.

              </t>
            </abstract> month='January' year='2026'/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tls-rfc8446bis-12"/> name="RFC" value="9846"/>
          <seriesInfo name="DOI" value="10.17487/RFC9846"/>
        </reference>

<!-- [RFC9851 / TLS12FROZEN]
draft-ietf-tls-tls12-frozen-08
AUTH48 state as of 1/5/2026
-->
        <reference anchor="TLS12FROZEN"> anchor="RFC9851" target="https://www.rfc-editor.org/info/rfc9851">
          <front>
            <title>TLS 1.2 is in Feature Freeze</title>
            <author fullname="Rich Salz" initials="R." surname="Salz"> surname="Salz" fullname="Rich Salz">
              <organization>Akamai Technologies</organization>
            </author>
            <author fullname="Nimrod Aviram" initials="N." surname="Aviram"> surname="Aviram" fullname="Nimrod Aviram">
            </author>
            <date day="3" month="April" year="2025"/>
            <abstract>
              <t>   Use of TLS 1.3, which fixes some known deficiencies in TLS 1.2, is
   growing.  This document specifies that outside of urgent security
   fixes (as determine by TLS WG consensus), new TLS Exporter Labels, or
   new Application-Layer Protocol Negotiation (ALPN) Protocol IDs, no
   changes will be approved for TLS 1.2.  This prescription does not
   pertain to DTLS (in any DTLS version); it pertains to TLS only.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tls-tls12-frozen-08"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to 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">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in 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> month="January" year='2026'/>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/> value="9851"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC9325">
          <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"/>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
            <author fullname="T. Fossati" initials="T." surname="Fossati"/>
            <date month="November" year="2022"/>
            <abstract>
              <t>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, 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>RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="195"/>
          <seriesInfo name="RFC" value="9325"/>
          <seriesInfo name="DOI" value="10.17487/RFC9325"/> value="10.17487/RFC9851"/>
        </reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml"/>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="QUICTLS">
          <front>
            <title>Using TLS to Secure QUIC</title>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <author fullname="S. Turner" initials="S." role="editor" surname="Turner"/>
            <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="DNSTLS">
          <front>
            <title>Usage Profiles for DNS over TLS and DNS over DTLS</title>
            <author fullname="S. Dickinson" initials="S." surname="Dickinson"/>
            <author fullname="D. Gillmor" initials="D." surname="Gillmor"/>
            <author fullname="T. Reddy" initials="T." surname="Reddy"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>This document discusses usage profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS). These profiles can increase the privacy of DNS transactions compared to using only cleartext DNS. This document also specifies new authentication mechanisms -- it describes several ways that a DNS client can use an authentication domain name to authenticate a (D)TLS connection to a DNS server. Additionally, it defines (D)TLS protocol profiles for DNS clients and servers implementing DNS over (D)TLS. This document updates RFC 7858.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8310"/>
          <seriesInfo name="DOI" value="10.17487/RFC8310"/>
        </reference>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5746.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9001.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8310.xml"/>

        <reference anchor="PQC" target="https://www.nist.gov/cybersecurity/what-post-quantum-cryptography">
          <front>
            <title>What Is Post-Quantum Cryptography?</title>
            <author>
              <organization/>
              <organization>NIST</organization>
            </author>
            <date year="2024" month="August"/> year="2025" month="June"/>
          </front>
        </reference>

        <reference anchor="TRIPLESHAKE" target="https://mitls.org/pages/attacks/3SHAKE"> target="https://web.archive.org/web/20250804151857/https://mitls.org/pages/attacks/3SHAKE">
          <front>
            <title>Triple Handshakes Considered Harmful Harmful: Breaking and Fixing Authentication over TLS</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
          <refcontent>Wayback Machine archive</refcontent>
        </reference>
        <reference anchor="RENEG1" target="https://web.archive.org/web/20091231034700/http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html">
          <front>
            <title>Understanding the TLS Renegotiation Attack</title>
            <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
            <date day="5" month="11" year="2009"/>
          </front>
          <refcontent>Wayback Machine archive</refcontent>
        </reference>
        <reference anchor="RENEG2" target="https://web.archive.org/web/20091228061844/http://extendedsubset.com/?p=8">
          <front>
            <title>Authentication Gap in TLS Renegotiation</title>
            <author initials="M." surname="Ray" fullname="Marsh Ray">
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
          <refcontent>Wayback Machine archive</refcontent>
        </reference>
        <reference anchor="LUCKY13" target="http://www.isg.rhul.ac.uk/tls/TLStiming.pdf">
          <front>
            <title>Lucky Thirteen: Breaking the TLS and DTLS record protocols</title>
            <author initials="N. J." surname="Al Fardan">
              <organization/>
            </author>
            <author initials="K. G." surname="Paterson">
              <organization/>
            </author>
            <date>n.d.</date>
            <date month="2" year="2013"/>
          </front>
        </reference>
        <reference anchor="LUCKY13FIX" target="https://nds.rub.de/media/nds/veroeffentlichungen/2016/10/19/tls-attacker-ccs16.pdf">
          <front>
            <title>Systematic fuzzing Fuzzing and testing Testing of TLS libraries</title> Libraries</title>
            <author initials="J." surname="Somorovsky" fullname="Juraj Somorovsky">
              <organization/>
            </author>
            <date>n.d.</date>
            <date month="10" year="2016"/>
          </front>
          <refcontent>CCS '16: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pp. 1492-1504</refcontent>
          <seriesInfo name="DOI" value="10.1145/2976749.2978411"/>
        </reference>
        <reference anchor="CBCSCANNING" target="https://www.usenix.org/system/files/sec19-merget.pdf">
          <front>
            <title>Scalable Scanning and Automatic Classification of TLS Padding Oracle Vulnerabilities</title>
            <author initials="R." surname="Merget" fullname="Robert Merget">
              <organization/>
            </author>
            <author initials="J." surname="Somorovsky" fullname="Juraj Somorovsky">
              <organization/>
            </author>
            <author initials="N." surname="Aviram" fullname="Nimrod Aviram">
              <organization/>
            </author>
            <author initials="C." surname="Young" fullname="Craig Young">
              <organization/>
            </author>
            <author initials="J." surname="Fliegenschmidt" fullname="Janis Fliegenschmidt">
              <organization/>
            </author>
            <author initials="J." surname="Schwenk" fullname="Jörg fullname="Jorg Schwenk">
              <organization/>
            </author>
            <author initials="Y." surname="Shavitt" fullname="Yuval Shavitt">
              <organization/>
            </author>
            <date>n.d.</date>
            <date month="8" year="2019"/>
          </front>
          <refcontent>28th USENIX Security Symposium (USENIX Security 19)</refcontent>
        </reference>
        <reference anchor="BEAST" target="http://www.hpcc.ecs.soton.ac.uk/dan/talks/bullrun/Beast.pdf">
          <front>
            <title>Here come Come the xor ninjas</title> XOR Ninjas</title>
            <author initials="T." surname="Duong" fullname="Thai Duong">
              <organization/>
            </author>
            <author initials="J." surname="Rizzo" fullname="Juliano Rizzo">
              <organization/>
            </author>
            <date>n.d.</date>
            <date month="5" year="2011"/>
          </front>
        </reference>
        <reference anchor="WEAKDH" target="https://dl.acm.org/doi/pdf/10.1145/2810103.2813707">
          <front>
            <title>Imperfect forward secrecy: Forward Secrecy: How Diffie-Hellman fails Fails in practice</title> Practice</title>
            <author initials="D." surname="Adrian">
              <organization/>
            </author>
            <author initials="K." surname="Bhargavan">
              <organization/>
            </author>
            <author initials="Z." surname="Durumeric">
              <organization/>
            </author>
            <author initials="P." surname="Gaudry">
              <organization/>
            </author>
            <author initials="M." surname="Green">
              <organization/>
            </author>
            <author initials="J. A." surname="Halderman">
              <organization/>
            </author>
            <author initials="N." surname="Heninger">
              <organization/>
            </author>
            <author initials="D." surname="Springall">
              <organization/>
            </author>
            <author initials="E." surname="Thomé"> surname="Thome">
              <organization/>
            </author>
            <author initials="L." surname="Valenta">
              <organization/>
            </author>
            <author initials="B." surname="VanderSloot">
              <organization/>
            </author>
            <date>n.d.</date>
            <author initials="E." surname="Wustrow">
              <organization/>
            </author>
            <author initials="S." surname="Zanella-Beguelin">
              <organization/>
            </author>
            <author initials="P." surname="Zimmerman">
              <organization/>
            </author>
            <date month="10" year="2015"/>
          </front>
          <refcontent>CCS '15: Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, pp. 5-17</refcontent>
          <seriesInfo name="DOI" value="10.1145/2810103.2813707"/>
        </reference>
        <reference anchor="FREAK" target="https://inria.hal.science/hal-01114250/file/messy-state-of-the-union-oakland15.pdf">
          <front>
            <title>A messy state Messy State of the union: Union: Taming the composite state machines Composite State Machines of TLS</title>
            <author initials="B." surname="Beurdouche" fullname="Benjamin Beurdouche">
              <organization/>
            </author>
            <author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhargavan">
              <organization/>
            </author>
            <author initials="A." surname="Delignat-Lavaud" fullname="Antoine Delignat-Lavaud">
              <organization/>
            </author>
            <author initials="C." surname="Fournet" fullname="Cédric fullname="Cedric Fournet">
              <organization/>
            </author>
            <author initials="M." surname="Kohlweiss" fullname="Markulf Kohlweiss">
              <organization/>
            </author>
            <author initials="A." surname="Pironti" fullname="Alfredo Pironti">
              <organization/>
            </author>
            <author initials="P.-Y." surname="Strub" fullname="Pierre-Yves Strub">
              <organization/>
            </author>
            <author initials="J. K." surname="Zinzindohoue" fullname="Jean Karim Zinzindohoue">
              <organization/>
            </author>
            <date>n.d.</date>
            <date month="5" year="2015"/>
          </front>
          <refcontent>IEEE Symposium on Security &amp; Privacy 2015</refcontent>
          <seriesInfo name="HAL ID:" value="hal-01114250"/>
        </reference>
        <reference anchor="SLOTH" target="https://inria.hal.science/hal-01244855/file/SLOTH_NDSS16.pdf">
          <front>
            <title>Transcript collision attacks: Collision Attacks: Breaking authentication Authentication in TLS, IKE, and SSH</title>
            <author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhargavan">
              <organization/>
            </author>
            <author initials="G." surname="Leurent" fullname="Gaëtan fullname="Gaetan Leurent">
              <organization/>
            </author>
            <date>n.d.</date>
            <date month="2" year="2016"/>
          </front>
          <refcontent>Network and Distributed System Security Symposium - NDSS 2016</refcontent>
          <seriesInfo name="DOI" value="10.14722/ndss.2016.23418"/>
          <seriesInfo name="HAL ID:" value="hal-01244855"/>
        </reference>
<!-- [I-D.ietf-pquip-pqc-engineers]
draft-ietf-pquip-pqc-engineers-14
IESG State: EDIT as of 1/5/2026

LONG WAY for author name
-->

<reference anchor="I-D.ietf-pquip-pqc-engineers"> anchor="I-D.ietf-pquip-pqc-engineers" target="https://datatracker.ietf.org/doc/html/draft-ietf-pquip-pqc-engineers-14">
<front>
<title>Post-Quantum Cryptography for Engineers</title>
<author fullname="Aritra Banerjee" initials="A." surname="Banerjee">
<organization>Nokia</organization>
</author>
<author fullname="Tirumaleswar Reddy.K" Reddy" initials="T." surname="Reddy.K"> surname="Reddy">
<organization>Nokia</organization>
</author>
<author fullname="Dimitrios Schoinianakis" initials="D." surname="Schoinianakis">
<organization>Nokia</organization>
</author>
<author fullname="Tim Hollebeek" initials="T." surname="Hollebeek">
<organization>DigiCert</organization>
</author>
<author fullname="Mike Ounsworth" initials="M." surname="Ounsworth">
<organization>Entrust Limited</organization>
</author>
<date day="13" month="February" day="25" month="August" year="2025"/>
            <abstract>
              <t>   The advent of a cryptographically relevant quantum computer (CRQC)
   would render state-of-the-art, traditional public-key algorithms
   deployed today obsolete, as the mathematical assumptions underpinning
   their security would no longer hold.  To address this, protocols and
   infrastructure must transition to post-quantum algorithms, which are
   designed to resist both traditional and quantum attacks.  This
   document explains why engineers need to be aware of and understand
   post-quantum cryptography (PQC), detailing the impact of CRQCs on
   existing systems and the challenges involved in transitioning to
   post-quantum algorithms.  Unlike previous cryptographic updates, this
   shift may require significant protocol redesign due to the unique
   properties of post-quantum algorithms.

              </t>
            </abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pquip-pqc-engineers-09"/> value="draft-ietf-pquip-pqc-engineers-14"/>
</reference>
        <reference anchor="RFC5746">
          <front>
            <title>Transport Layer Security (TLS) Renegotiation Indication Extension</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <author fullname="M. Ray" initials="M." surname="Ray"/>
            <author fullname="S. Dispensa" initials="S." surname="Dispensa"/>
            <author fullname="N. Oskov" initials="N." surname="Oskov"/>
            <date month="February" year="2010"/>
            <abstract>
              <t>Secure Socket Layer (SSL) and Transport Layer Security (TLS) 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

<!-- [I-D.ietf-tls-deprecate-obsolete-kex]
draft-ietf-tls-deprecate-obsolete-kex-06
IESG State: IESG Evaluation 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="I-D.ietf-tls-deprecate-obsolete-kex">
          <front>
            <title>Deprecating Obsolete Key Exchange Methods in TLS 1.2</title>
            <author fullname="Carrick Bartle" initials="C." surname="Bartle">
              <organization>Roblox</organization>
            </author>
            <author fullname="Nimrod Aviram" initials="N." surname="Aviram">
         </author>
            <date day="3" month="September" year="2024"/>
            <abstract>
              <t>   This document deprecates the use of RSA key exchange and Diffie
   Hellman over a finite field in TLS 1.2, and discourages the use of
   static elliptic curve Diffie Hellman cipher suites.

   Note that these prescriptions apply only to TLS 1.2 since TLS 1.0 and
   1.1 are deprecated by RFC 8996 and TLS 1.3 either does not use the
   affected algorithm or does not share the relevant configuration
   options.

   This document updates RFCs 9325, 4346, 5246, 4162, 6347, 5932, 5288,
   6209, 6367, 8422, 5289, 5469, 4785, 4279, 5487, 6655, and 7905.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tls-deprecate-obsolete-kex-05"/>
        </reference>
        <reference anchor="RFC7465">
          <front>
            <title>Prohibiting RC4 Cipher Suites</title>
            <author fullname="A. Popov" initials="A." surname="Popov"/>
            <date month="February" year="2015"/>
            <abstract>
              <t>This document requires that Transport Layer Security (TLS) 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> 1/5/2026
-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-deprecate-obsolete-kex.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7465.xml"/>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA81a3XLbRpa+76foVS42mSJBUZIdW5kdh5ZkW2NZVkR5Ms7U
VKoJNMmOADSnG5BEu3S1L7K3W3u/DzD7Yvud0w0QoORKUrUXm0oisNE/5/98
5zSGw6GoTJXrQ7lzrm/lhbOVTW3u5QdvyoW8OpvKd7Wv5KX+R22c5oFxsr8j
1Gzm9A2WufBmWOWeX6Sq0gvr1odylq5Evcrw2x/K5/t7T4TIbFqqAqdlTs2r
odHVfFhXatjdZH843hO+nhXGe2PLar3C/NOTq1eirIuZdoeCtjwUqS29Ln2N
zStXawFi9oVyWoGoqU5rZ6r1jri17nrhbL3C6IYnU8rJapUbEIsj/I641mvM
zA6FHNKE+EdeOVV6Q3OakWm9WllX0c/TstLOrrRTM5PjMBqba1XVTntxo8sa
REr5Gw6XMjC58yOIpVmvaQ2NF8rkGIeIvidZJdYtaHhhqmU9I+GbdOlV/mkU
5Fn7KMIdIVRdLS2ENcT8eZ3nQe6XWCCnWIFRbKZK84mpOJSTa4XT5JVOl6XN
7cKACSl1oMDRId8rnpKkttja9dwUzmZycmOcKjarSh5OFA9/v6BBXixK6woc
e8MCgkjGe6Ds1dGTvYOncWAfKh8eJx0zAV9DN0+fHRw8nRnfrHt1+f6nk/NH
J5Mg9oZzZz/pUghTzruH/vDh9Agb8LHPd3fHGDo+nzYjz/bHuxi5+OGI5kI9
yi10dSiXVbXyh6PR7e1tUhpfJQt7M0rXMEofDW50u1TVcGV9NfxHrcqqLoap
W68qu3BqtVzzbmy+cmdSL+BZA7m3u3ewE44JnvgjtpCnXl7QLj+EXeRRZ5cX
xP3l6cXZyfTN5O3J4zQW2MyTwYxWaqH9SFWVSq/9aJ/XdM+7cmaVa/lGlZlf
qmvt5RHM0mTa6QyjroCi5Us4FtsmZslX5o4eJzAxXVbRkKW90S44j7w8OT95
PT7snvKhxIa+wnJaioXsC5e6RLSoTNhhwjTyqsZ8Jf8TzOwE5o4VPrUuV48r
Rs8S5dIltMys4/dob3f3+XgPGt0/+HZ3d0RTowp1VlO0yha19p4CBa+h+aPx
eFR3Cf4ZBP8Mgf7sIsHJsiryhtO9HqdbYnmtVuTyD7h9hM1hZPSdcn4pL9X6
dzK592z36Rge0jCp7yoNLjJEU68r8r3Ri9W/PcOuZx+O3n6El3Xp3jmr0+u1
vFoaV2mNkNDqvNEW6f6YHpyGDjK5atLFzgNCo4iNXyRuWeeJSpP6egQJjrC+
MgW2TVbZ/FEhmBIx/TyRf07kJJevlMtU2X/5NpGvE3kB5TnPkoz8vDr9a5+l
6dpXmtw+Rbj69KkxYKSkip7tnPnKzcwph4j3kA8SOPwicfUsyfSo0JlRNDCC
sVs9n0PRiOTLulzoEloYPx2Nd0fj58TpMLicdsM09eOnX2A3aPzPtVO/yKkt
rLM3/poUf/TyaHo0OT8/PX/d42maqlzN4LB4KMuGIxidDXwe5QqJc956ZWDx
QmXseO+dSrH2L3VeNokrRPrHoxwySmnu2Mw8i3I0NzmiCeLd+Pmw0LTii3qM
KcciPlbyHc/devcI293X23ml++7IKbOQHy0kv70pspqXr3KjoROfLguTPTj3
f/79n//tFhDh8laX11tvP9Y3KpfTJRJXRStfnkymV327eoPgKOFPmn3jzjok
u/IX9WVHWK7SNNGpTzxcpozuALseVSpHVJ4hl7q6HL3Uyv+aQK+WyNPHtX3I
eJ0bVVok+U+fLN79eDJ5e/ymT/hpAcAy12klkQ9v4VoSqoQ7A6+9sbfy2Mzn
Rg/f6DwvVCnnSNmeotcKZgPj0o87SEb+XbCVZNaMQD68IBmPD56M9p6NdxF6
E/zd/3b32y/7+zGcPXPmEU9/ucRx6mb7zU8JhOBq2KBJ+28uEB1Unbl1f/gd
hh0CW3+UgkzyRuUI9sX2EYhBbzS5mHYPiJ2uHF6oPO+/OUmgH1vAvv6z/+Is
kX9ROcKF6o+/pHFKNdPcWrK2V5dQW19pE1kgQ60lslGlyaPJ6OqScduVKpoQ
DXsE8jCYEiYWCkmiRD4PMeBx3ZkSQk+WKk98anSZ6hGeh7tjaG/vyS67+4hP
H/KmQwt0tdRDPn1o1XUO4sdPfsVkX2o4B+jEQ+0yW6dLvTXjrXLV0gCGw+oe
KjzMmZSVBT/yWOdmUQJnnWFSnW0HBpJ9RlDhla1d+SDmILle1/lcvrXL/Faj
yNg+JZ8D+Fh5YRyqD7P19sJoh0Ll4w3EOkXdMdv2QQ0GwIwp5E+mRMLJ7NLW
xO307P3VljNyeZECflXQXZ4bqndkBGqd9Kv6gCKAiYE8fXsy4Ng/nb75fbrd
Ozh49uRJ0C2T9fP58XT6xRT1e3T0WkH8/wXUJM+galAtxHA4lGrmKwohQsQK
UiKzSITpW+BMvwKn2UCaSi6Vx38Zm7LT4NoD5cgGXRPgsHMfuDaVMJhkSRMz
Wy03s+gtvPNGpesWlOLMvQSweYnAjcinB7JEvdsCGFER6CaaaG5BJa/rl7xY
PPEB/RD5IL20FZOf48QbBEpOytaJTK9yu9ZgCNLyOEMHHZPuMqvDQkThSkGT
lQ17fo1nVa7DD9BMpvDNd8K0Mz1NpZe2zNcJ5Eh7o55GACxBeaizuZxBpc0i
yIxPa+8x2q1HZLceCWAIzvio7KJ46QDfE6SElpR0bI6IaZRKZBAgk5EEnSPv
ZrkW4iuqlJHH65RF8PkrHIaKXwG5+fttRvxKpwAvIJo2HEhUzWmrg8eM5req
kRgDMMIpsBwv9R3qN3IJ6PV0I7/Pn6ME7+8FmMxYdTPUQVDP58+oP+ndMM6+
v/9/ZxSRkM+fuYi+vyeSsMlGYCwcksXc3OHUApYhr0t7Cyo0MCNFCRL+ramW
YuM2J3eqQI3oQ+7hPdO8zrTEdDInilLAcG1ugq8DR6TS22AX5KuBRaKBZTKD
b9YVl5meCXK6sDdhI9DUsVLsA4tEPYtQ4AVolemmPr1FjEwkUI2FQIDF1wMm
oLGIxwOK2AoofL5HnM65prkxxNldChDEJtlMJqGAZlYJwelg/tSImptFHdyh
VcJeVMJeq4RG8oDtckbZOiwDEx4JsRFUQ4CXC2uzHqWkdCgH+gBU07CHQeuQ
vkYpAkHOnS1AMN4BwXY1ipjpxZY5kx82ogy9qGDRWQbr9BFVFKC7BsxZN57k
xQy2ZK83HLSM/1+EJNEYZ9At4AtNjwX0b4o9X1H/4oYSJjgKNSsEUbK6PFGp
JXKYpH6flzvvPkyvdgbhrzx/z8+XJz98OL08Oabn6ZvJ2Vn7IOKM6Zv3H86O
N0+blUfv3707OT8OizEqe0Ni593k405IYDvvL65O359PznaIvaonPAVfgmvD
TAx1GWG6lc4eqPDl0cU//2N8AFX+C6S8Nx4/h7GFH8/G3x7gxy0sPpxGESL+
hFYh5tVKK0e7QLmwyZVBJcJmQp6AeECZEtL8w99IMn8/lH+cpavxwZ/iADHc
G2xk1htkmT0cebA4CPGRoUeOaaXZG9+SdJ/eycfe70buncE/vsgJWQ7Hz178
SXDKKjYdWraxL+fQry9+OPpGiKNuxCKHQY7LNRBSJdtlCEI19Szk10eXWDSA
VpDd2kQxQIhBQYHCE4NyWS805WDAJsxj+2/i6tdeY7JOFskA+p7qkFn3EH7F
C2qFchN0BXdd4f/pUJcLcIdz7++/IRBkJUXTBdUIZHYhjKhOTzrQgSUZWWFh
wFXFBvnFnmSQgvwb/v93HHGskZ5ynYl+fKH8QDYIi+ye14YWarkiW8Y5koRE
wVOBTCSOKqT3rbUNlRTyqa5VC0qMgA7kQzO9tgHiSJ8igDYJTDSeBgt/ZQOw
QeylQN2kEtoTGUuH6EI7zLEmpkCNWK7nsIsq5EpTiqZJ9uNr2iZmYoG9c2pT
DSLUwlZNICMZc06El/twrQBOSLVN6gjdbVJaiK3418JKOdMGAMWm2YNAPdwK
FpAEVJ1XDVAATQNxS74tLqJwU0qsCA4zTSGfO57KZeYTgRXlQ2BaUO7lg7pm
wjzbAGKwPyU4bMohmM764DnNv8cs17la4nZVdxcxQULtMiEbGBfkyPEmAMM1
UUT4rWGrQeesRR1gyoDb+xBi7PIjDrYG1iAkzvg9rAksk61QX1Ze8IFQGirW
4COc68roZmZOJmipY9CAMpIjyM3A+ulcBqzHcXzL/MkkFQ2m2pVbSAVRqmVy
k+sEWXuLNQB3UXU3vAfJJ2LiedOaMsVGBrT5B68QQyB6KvXYVo7Ppxso//lz
uPSAgFpZiE6epS3iYQhNS9oDOcJSxrC3zXVWK31oEPvGjZpAwpJNl9Z6jh/R
zhsGiUp6g/wG+EJwnGUkQupzhGOCVClpcwoHrKG1y+ayItDCAsiNDl7bSBEU
A1dFFTWOy/y1QofPR5J8UwsBPjkSEIO20D/n8GLSa369NAu4fyUa1Te4jSXT
bMalZvDYgK6jNHc6SF50LgMGO7HyinTRj+7NSMbxNBhQA6IiimOkPxBNEjgA
YB9DobRDDCMDcjcwYu7kCSO8d4Rge43vFvYqeavWgiyllw86UiU2nCoXHEtb
4RKmwNIShhJqg9CYFoi5ZcAw1FPlwBOgCG0DzUGSFPCjULv+1FhkdCqa3w37
7HF8SAjeZPTkcuEtK6XVLCc5BpbwXRMKHr+J64+s59hM8ayj8VZvbbBmJytF
sDwvI2RpBPULlZ+0HmHEFMiXG4uJsophncPNbFPlWrfxD8QSHa7MwkKZGofM
RVGanKWFg8KE12oG75Yr5RTnZR/w8JL0xVoENOS7eJTh29WsEJ3qd1OG0F1P
AclkHTBE9+6uaTu2JYptQp+musXdmLQJrU1FDhUMZF3m5lr3Ae8g1LjwkltU
XQhpQXKV4XIdwoKF1rPc+KUOjaINDo7oia/gm9sOyrxYsrNdiSc71AEiGBWv
9UNbIIs5rAhFQ/AsIryFCVxHLhw8uUnkXbRONWnBN6fVrUW0Y2lTEGNf2ZIf
O22U80A2brufjMltD4UYUoOfq05+4dXad3HDfmNmXdTw3RZBBeXwSsd+SLOw
sbMN2GjQA2YMgze1OCL5VUr2Hm64TUe7pM0qlOV6JPS6LGy9OHlCGG4QcVaU
ZwgbFALWEcwEVRCCIuNhS28+/GivsKPQQ9Npq9jdlOpkX228YUDXFtFfakSE
elZ7sygpv5GtB2kTeh+EHEvmOwC7fFFEMzkxUpeCa1vtEjbHVe1WlAWb5koj
cEMeK2aIz3OsgMfdIG40dHHPANpCcCFJ4wn2XUQFhQpiTvc8OuvBjEScVk2r
A3oggAuHWjb9hJ56H2lUkHjhUd8FsCwKTb9kQbQwKs3o/iiNeLNdyGk2LiWF
2xXxmwXMSFYHRCcKC82UxBdE6W3b3NhPoFUdy9oYnDg/hROpUW3rxVIuaspf
IUqGtonuIrE2MuwR5DfOt72iht1GRINeo4fv0DnHDUghN/HiNCc4I1zv84XY
uW8gfPgIok3F4UsBgHnZdl23v7yIO7Q1wOYbD64BXjqrski1byZ7oe/ApKl6
av5X30ItklWfTkQg6wi9Qv6m/IWLJoZg5k6khMdKgu2cTeINNmXwEM1WuaJs
fgeFVihBiqTFOU2bSEHqN4oui6BZEQq37hViNLKI26iGlXZGzUyuPugykmCz
vTah7QNAomcYr2g7WG8J0LJYkj5FJ99F66dq+AV9SfTtwdMuqCXA3ioynL8i
dFlGcNB+tUZmEuWaUJ3cWm2wpE1e1oarmr5gueE80wIIjSwkk5RPaPlAcpfK
+A4VcXKoG6jpFjE+zW4QBc0RFOBYWhGZch7fHBzrE+oNMuyG1YfcrDpFC2we
oRGlcGP01pkFqpucW2H6LsRYJEAYftaNhaG9pjvOQfc8+VpcTif9taFvV9L1
I1YivPTvkgexR9lrUYpNiw9ejtCaK8cUPpR8jwjBPeK2Eu/SIRoeGvk2ykhE
CCObBgl9o4HdkaD5YnPmba7xcK3vYoiJqDu0Nh3Lzq+Ryyu6XUzNaknKCFXG
LQHbADfoM7yIIB7KTV4eHTASPXp5FLeAYCA0/6iAZFdAWNpr9DaeH/rpRsVG
KZXHJJHgoN/JEEzILeAVT6gAeHA2Jwwx09x18bZ2aUD3/a9EqAtDoZZCI/G2
1sqBrAmdpMgp4ycFYgtMt3rqn2lKqgY4G/ba17Q1f4o03pfhSyER4+Lnz/E7
H2KCMuec4jg5rC5WnHLakyNW7p/H3ajQ22FgGa+lCHggPiAchJTCstc97teb
s1+d/hXHC75JDImW5TavHUcEH6z4V2QnWHYyKpC89YFOvpNcFIOrTaev803Q
/X2o0sqm4g9QtoEJkHlDCX3ZRjZ8uukkbC4OCPm0QGG2gReWmWkyWgfC7Ycm
WVGXlAEPBX8cA9L47/39QJ7ZxS+qwEj4/ISG+JMGjPBfGuBba7p4pu4l/SWJ
ikmIICEEcrtBdCu+XK1JHLEFSp2r/JbwZbyDIhzTCQubFoGgzxfoG0iunhFN
k+41cHDScOEZa56My896RlVBofJN8011Ggfe17E1SJ9hhS6eCjcnQZLbtyNf
ydPJ+eQhMDWqVA+uQUM1UVpuXKH25JhP6+Pd6oy+k/xfvvRLZ74tAAA=

-->

</rfc>