<?xml version="1.0" encoding="US-ASCII"?>
<!-- this is version 5 of this xml2rfc template -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2223 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.2223.xml">
<!ENTITY rfc2578 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml">
<!ENTITY rfc2579 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.2579.xml">
<!ENTITY rfc2580 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.2580.xml">
<!ENTITY rfc2629 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY rfc3261 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc3316 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3316.xml">
<!ENTITY rfc3329 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3329.xml">
<!ENTITY rfc3410 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml">
<!ENTITY rfc3436 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3436.xml">
<!ENTITY rfc3470 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3470.xml">
<!ENTITY rfc3489 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3489.xml">
<!ENTITY rfc3501 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3501.xml">
<!ENTITY rfc3546 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3546.xml">
<!ENTITY rfc3552 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY rfc3568 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3568.xml">
<!ENTITY rfc3588 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml">
<!ENTITY rfc3656 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3656.xml">
<!ENTITY rfc3734 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3734.xml">
<!ENTITY rfc3749 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3749.xml">
<!ENTITY rfc3767 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3767.xml">
<!ENTITY rfc3856 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3856.xml">
<!ENTITY rfc3887 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3887.xml">
<!ENTITY rfc3903 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3903.xml">
<!ENTITY rfc3920 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3920.xml">
<!ENTITY rfc3943 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3943.xml">
<!ENTITY rfc3983 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.3983.xml">
<!ENTITY rfc4097 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4097.xml">
<!ENTITY rfc4111 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4111.xml">
<!ENTITY rfc4132 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4132.xml">
<!ENTITY rfc4162 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4162.xml">
<!ENTITY rfc4168 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4168.xml">
<!ENTITY rfc4181 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4181.xml">
<!ENTITY rfc4217 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4217.xml">
<!ENTITY rfc4235 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4235.xml">
<!ENTITY rfc4244 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4244.xml">
<!ENTITY rfc4261 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4261.xml">
<!ENTITY rfc4279 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4279.xml">
<!ENTITY rfc4366 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4366.xml">
<!ENTITY rfc4492 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4492.xml">
<!ENTITY rfc4497 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4497.xml">
<!ENTITY rfc4507 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4507.xml">
<!ENTITY rfc4513 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4513.xml">
<!ENTITY rfc4531 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4531.xml">
<!ENTITY rfc4540 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4540.xml">
<!ENTITY rfc4572 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4572.xml">
<!ENTITY rfc4582 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4582.xml">
<!ENTITY rfc4616 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4616.xml">
<!ENTITY rfc4642 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4642.xml">
<!ENTITY rfc4680 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4680.xml">
<!ENTITY rfc4681 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4681.xml">
<!ENTITY rfc4712 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4712.xml">
<!ENTITY rfc4732 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4732.xml">
<!ENTITY rfc4743 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4743.xml">
<!ENTITY rfc4744 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4744.xml">
<!ENTITY rfc4785 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4785.xml">
<!ENTITY rfc4791 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4791.xml">
<!ENTITY rfc4823 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4823.xml">
<!ENTITY rfc4851 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4851.xml">
<!ENTITY rfc4934 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4934.xml">
<!ENTITY rfc4964 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4964.xml">
<!ENTITY rfc4975 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4975.xml">
<!ENTITY rfc4976 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4976.xml">
<!ENTITY rfc4992 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4992.xml">
<!ENTITY rfc5018 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5018.xml">
<!ENTITY rfc5019 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5019.xml">
<!ENTITY rfc5023 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5023.xml">
<!ENTITY rfc5024 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5024.xml">
<!ENTITY rfc5049 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5049.xml">
<!ENTITY rfc5054 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5054.xml">
<!ENTITY rfc5077 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5077.xml">
<!ENTITY rfc5081 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5081.xml">
<!ENTITY rfc5091 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5091.xml">
<!ENTITY rfc5101 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5101.xml">
<!ENTITY rfc5158 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5158.xml">
<!ENTITY rfc5216 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5216.xml">
<!ENTITY rfc5238 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5238.xml">
<!ENTITY rfc5281 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5281.xml">
<!ENTITY rfc5364 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5364.xml">
<!ENTITY rfc5422 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5422.xml">
<!ENTITY rfc5469 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5469.xml">
<!ENTITY rfc5734 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5734.xml">
<!ENTITY rfc5878 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5878.xml">
<!ENTITY rfc5953 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5953.xml">
<!ENTITY rfc6042 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.6042.xml">
<!ENTITY rfc6176 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.6176.xml">
<!ENTITY rfc6353 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.6353.xml">
<!ENTITY rfc6367 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.6367.xml">
<!ENTITY rfc6614 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.6614.xml">
<!ENTITY rfc6739 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.6739.xml">
<!ENTITY rfc6749 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.6749.xml">
<!ENTITY rfc6750 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.6750.xml">
<!ENTITY rfc7030 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.7030.xml">
<!ENTITY rfc7465 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.7465.xml">
<!ENTITY rfc7507 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.7507.xml">
<!ENTITY rfc7562 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.7562.xml">
<!ENTITY rfc7568 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.7568.xml">
<!ENTITY rfc8422 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.8422.xml">
<!ENTITY rfc8143 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.8261.xml">
<!ENTITY rfc6347 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY rfc6460 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.6460.xml">
<!ENTITY rfc6084 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.6084.xml">
<!ENTITY rfc6083 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.6083.xml">
<!ENTITY rfc6012 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.6012.xml">
<!ENTITY rfc5456 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5456.xml">
<!ENTITY rfc5415 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.5415.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?> version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="bcp" consensus="true" docName="draft-ietf-tls-oldversions-deprecate-12" indexInclude="true" ipr="trust200902"
     updates="8422 8261 7568 7562 7525 7465 7030 6750 6749 6739 6460 6614 6367 6353 6347 6176 6084 6083 6042 6012 5953 5878 5734 5456 5422 5415 5364 5281 5263 5238 5216 5158 5091 5054 5049 5024 5023 5019 5018 4992 4976 4975 4964 4851 4823 4791 4785 4744 4743 4732 4712 4681 4680 4642 4616 4582 4540 4531 4513 4497 4279 4261 4235 4217 4168 4162 4111 4097 3983 3943 3903 3887 3871 3856 3767 3749 3656 3568 3552 3501 3470 3436 3329 3261"
     obsoletes="5469 7507"> number="8996" obsoletes="5469, 7507" prepTime="2021-03-22T15:03:43" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" updates="3261, 3329, 3436, 3470, 3501, 3552, 3568, 3656, 3749, 3767, 3856, 3871, 3887, 3903, 3943, 3983, 4097, 4111,​ 4162, 4168, 4217, 4235, 4261, 4279, 4497, 4513, 4531, 4540, 4582, 4616, 4642, 4680, 4681, 4712, 4732, 4743,​ 4744, 4785, 4791, 4823, 4851, 4964, 4975, 4976, 4992, 5018, 5019, 5023, 5024, 5049, 5054, 5091, 5158, 5216,​ 5238, 5263, 5281, 5364, 5415, 5422, 5456, 5734, 5878, 5953, 6012, 6042, 6083, 6084, 6176, 6347, 6353, 6367,​ 6460, 6614, 6739, 6749, 6750, 7030, 7465, 7525, 7562, 7568, 8261, 8422" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate-12" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8996" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Deprecating TLSv1.0 TLS 1.0 and TLSv1.1">Deprecating TLSv1.0 TLS 1.1">Deprecating TLS 1.0 and
    TLSv1.1</title> TLS 1.1</title>
    <seriesInfo name="RFC" value="8996" stream="IETF"/>
    <seriesInfo name="BCP" value="195" stream="IETF"/>
    <author fullname="Kathleen Moriarty" initials="K" surname="Moriarty">
      <organization>Dell EMC</organization>
      <organization abbrev="CIS" showOnFrontPage="true">Center for Internet Security (CIS)</organization>
      <address>
        <postal>
          <street>176 South Street</street>

          <city>Hopkinton</city>
          <street/>
          <city>East Greenbush</city>
          <region>NY</region>
          <country>United States</country> States of America</country>
        </postal>
        <email>Kathleen.Moriarty.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Stephen Farrell" initials="S." surname="Farrell">
      <organization>Trinity
      <organization showOnFrontPage="true">Trinity College Dublin</organization>
      <address>
        <postal>
          <street/>
          <city>Dublin</city>
          <region/>
          <code>2</code>
          <country>Ireland</country>
        </postal>
        <phone>+353-1-896-2354</phone>
        <email>stephen.farrell@cs.tcd.ie</email>
      </address>
    </author>
    <date month="03" year="2021"/>
    <area>Security Area</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <keyword>TLS</keyword>
    <keyword>deprecate</keyword>
    <keyword>TLSv1.0</keyword>
    <keyword>TLSv1.1</keyword>

    <abstract>
        <t>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">

            This document, if approved, document formally deprecates Transport Layer
            Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346).
            Accordingly, those documents (will be moved|have have been moved) 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. TLSv1.2 TLS version 1.2
            became the recommended version for IETF protocols in 2008, 2008
            (subsequently being obsoleted by TLSv1.3 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
      <t indent="0" pn="section-abstract-2">This document also deprecates Datagram TLS (DTLS) version 1.0
      (RFC 4347), 4347) but not DTLS version 1.2, and there is no DTLS
      version 1.1.</t>

      <t>This
      <t indent="0" pn="section-abstract-3">This document updates many RFCs that normatively refer to TLSv1.0 TLS version 1.0 or
      TLSv1.1
      TLS version 1.1, as described herein. This document also updates the best
      practices for TLS usage in RFC 7525 and hence 7525; hence, it is part of BCP 195.</t>
    </abstract>
  </front>

  <middle>
    <boilerplate>
      <section title="Introduction">
      <!--
      <t>[[Text in double-square brackets anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This memo documents an Internet Best Current Practice.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is intended a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further information
            on BCPs is available in Section 2 of RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be fixed obtained at
            <eref target="https://www.rfc-editor.org/info/rfc8996" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the draft evolves. You've seen that we need
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to
      figure out BCP 78 and the list of RFCs that this'd update IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the abstract.
	  There is a repo for date of
            publication of this at: https://github.com/tlswg/oldversions-deprecate
	  - PRs (on document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the xml file) Trust Legal Provisions and are welcome there.]]</t>
		-->

      <t>Transport provided without
            warranty as described in the Simplified BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rfcs-updated">RFCs Updated</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-support-for-deprecation">Support for Deprecation</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sha-1-usage-problematic-in-">SHA-1 Usage Problematic in TLS 1.0 and TLS 1.1</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-do-not-use-tls-10">Do Not Use TLS 1.0</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-do-not-use-tls-11">Do Not Use TLS 1.1</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-updates-to-rfc-7525">Updates to RFC 7525</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operational-considerations">Operational Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">Transport Layer Security (TLS) versions 1.0 <xref target="RFC2246"/> target="RFC2246" format="default" sectionFormat="of" derivedContent="RFC2246"/>
      and 1.1 <xref target="RFC4346"/> target="RFC4346" format="default" sectionFormat="of" derivedContent="RFC4346"/> were superseded by TLSv1.2 TLS 1.2 <xref
      target="RFC5246"/> target="RFC5246" format="default" sectionFormat="of" derivedContent="RFC5246"/> in 2008, which has now itself been superseded by
      TLSv1.3
      TLS 1.3 <xref target="RFC8446"/>. target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>. Datagram Transport Layer Security
      (DTLS) version 1.0 <xref target="RFC4347"/> target="RFC4347" format="default" sectionFormat="of" derivedContent="RFC4347"/> was superseded by DTLSv1.2 DTLS 1.2
      <xref target="RFC6347"/> target="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"/> in 2012.  It  Therefore, it is therefore timely to further
          deprecate TLSv1.0, TLSv1.1 TLS 1.0, TLS 1.1, and DTLSv1.0. DTLS 1.0.
      Accordingly,
      those the aforementioned documents (will be moved|have have been moved) moved to Historic status.</t>

      <!--The expectation is that TLSv1.2 will
      continue to be used for many years alongside TLSv1.3.</t>
      -->

      <!--
      <t>TLSv1.1 and TLSv1.0 are also actively being deprecated in accordance
      with guidance from government agencies (e.g. <xref
      target="NIST800-52r2"/>) and industry consortia
      such as the Payment Card Industry Association (PCI) <xref
      target="PCI-TLS1"/>.</t>

      <t>3GPP have deprecated TLSv1.0 and DTLSv1.0 since their release-14 in
      2016. <xref target="TGPP33310"/></t>
      -->

      <t>Technical
      <t indent="0" pn="section-1-2">Technical reasons for deprecating these versions include:</t>

      <t><list style="symbols">
          <t>They
      <ul spacing="compact" bare="false" empty="false" indent="3" pn="section-1-3">
        <li pn="section-1-3.1">They require the implementation of older cipher suites that are no
          longer desirable for cryptographic reasons, e.g., TLSv1.0 TLS 1.0 makes
          TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA mandatory to implement</t>

          <t>Lack implement.</li>
        <li pn="section-1-3.2">There is a lack of support for current recommended cipher suites, especially
          AEAD ciphers which are not
          authenticated encryption with associated data (AEAD) ciphers,
	  which were not supported prior to TLSv1.2. Note: TLS 1.2. Note that
          registry entries for no-longer-desirable ciphersuites remain in the
          registries, but many TLS registries are being were updated through by <xref
          target="RFC8447"/> target="RFC8447" format="default" sectionFormat="of" derivedContent="RFC8447"/>, which indicates that such entries are not
          recommended by the IETF.</t>

          <t>Integrity IETF.</li>
        <li pn="section-1-3.3">The integrity of the handshake depends on SHA-1 hash.</t>

          <t>Authentication hash.</li>
        <li pn="section-1-3.4">The authentication of the peers depends on SHA-1 signatures.</t>

          <t>Support signatures.</li>
        <li pn="section-1-3.5">Support for four TLS protocol versions increases the likelihood of
          misconfiguration.</t>

          <t>At
          misconfiguration.</li>
        <li pn="section-1-3.6">At least one widely-used widely used library has plans to drop TLSv1.1 TLS 1.1 and
          TLSv1.0
          TLS 1.0 support in upcoming releases; products using such libraries
          would need to use older versions of the libraries to support TLSv1.0 TLS 1.0
          and TLSv1.1, TLS 1.1, which is clearly undesirable.</t>
        </list></t>

      <t>Deprecation undesirable.</li>
      </ul>
      <t indent="0" pn="section-1-4">Deprecation of these versions is intended to assist developers as
      additional justification to no longer support older (D)TLS versions and to
      migrate to a minimum of (D)TLSv1.2. (D)TLS 1.2. Deprecation also assists product teams
      with phasing out support for the older versions, to reduce the attack
      surface and the scope of maintenance for protocols in their
      offerings.</t>

      <!-- duplication - already said in the bullet list above
      <t>Some TLS libraries are considering dropping support for TLSv1.0 and
      TLSv1.1 in upcoming releases. If products do not follow suit because the
      protocol has not been deprecated, multiple libraries may be needed for a
      very small number of deployments. While fixes have been developed to
      address the known vulnerabilities in TLSv1.0 and TLSv1.1, this may not
      continue if library support is eliminated for new releases.</t>
		-->

      <!--
      <t>[[This draft is being written now so that the TLS WG chairs can just
      hit the "publication requested" button as soon as there is WG consensus
      to deprecate these ancient versions of TLS. The authors however think
      that deprecation now is timely.]]</t>
		-->

      <!-- adding the boilerplate below for 2119 and 8174
          -->
      <section anchor="updates" title="RFCs Updated">
        <t>This numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-rfcs-updated">RFCs Updated</name>
        <t indent="0" pn="section-1.1-1">This document updates the following RFCs that normatively reference
        TLSv1.0 or TLSv1.1
        TLS 1.0, TLS 1.1, or DTLS1.0. DTLS 1.0. The update is to obsolete usage of
        these older versions. Fallback to these versions is prohibited
        through this update. Specific references to mandatory minimum protocol
        versions of TLSv1.0 TLS 1.0 or TLSv1.1 TLS 1.1 are replaced by TLSv1.2, TLS 1.2, and references
        to minimum protocol version DTLSv1.0 DTLS 1.0 are replaced by DTLSv1.2. DTLS 1.2.
        Statements that "TLSv1.0 "TLS 1.0 is the most widely deployed version and will
        provide the broadest interoperability" are removed without
        replacement.</t>

    <t>

		<xref target="RFC8422"/>
		<xref target="RFC8261"/>
		<xref target="RFC7568"/>
		<xref target="RFC7562"/>
		<xref target="RFC7525"/>
		<xref target="RFC7465"/>
		<xref target="RFC7030"/>
		<xref target="RFC6750"/>
		<xref target="RFC6749"/>
		<xref target="RFC6739"/>
		<xref target="RFC6084"/>
		<xref target="RFC6083"/>
		<xref target="RFC6367"/>
		<xref target="RFC6353"/>
		<xref target="RFC6176"/>
		<xref target="RFC6042"/>
		<xref target="RFC6012"/>
		<xref target="RFC5878"/>
		<xref target="RFC5734"/>
		<xref target="RFC5456"/>
		<xref target="RFC5422"/>
		<xref target="RFC5415"/>
		<xref target="RFC5364"/>
		<xref target="RFC5281"/>
		<xref target="RFC5263"/>
		<xref target="RFC5238"/>
		<xref target="RFC5216"/>
		<xref target="RFC5158"/>
		<xref target="RFC5091"/>
		<xref target="RFC5054"/>
		<xref target="RFC5049"/>
		<xref target="RFC5024"/>
		<xref target="RFC5023"/>
		<xref target="RFC5019"/>
		<xref target="RFC5018"/>
		<xref target="RFC4992"/>
		<xref target="RFC4976"/>
		<xref target="RFC4975"/>
		<xref target="RFC4964"/>
		<xref target="RFC4851"/>
		<xref target="RFC4823"/>
		<xref target="RFC4791"/>
		<xref target="RFC4785"/>
		<xref target="RFC4732"/>
		<xref target="RFC4712"/>
		<xref target="RFC4681"/>
		<xref target="RFC4680"/>
		<xref target="RFC4642"/>
		<xref target="RFC4616"/>
		<xref target="RFC4582"/>
		<xref target="RFC4540"/>
		<xref target="RFC4531"/>
		<xref target="RFC4513"/>
		<xref target="RFC4497"/>
		<xref target="RFC4279"/>
		<xref target="RFC4261"/>
		<xref target="RFC4235"/>
		<xref target="RFC4217"/>
		<xref target="RFC4168"/>
		<xref target="RFC4162"/>
		<xref target="RFC4111"/>
		<xref target="RFC4097"/>
		<xref target="RFC3983"/>
		<xref target="RFC3943"/>
		<xref target="RFC3903"/>
		<xref target="RFC3887"/>
		<xref target="RFC3871"/>
		<xref target="RFC3856"/>
		<xref target="RFC3767"/>
		<xref target="RFC3749"/>
		<xref target="RFC3656"/>
		<xref target="RFC3568"/>
		<xref target="RFC3552"/>
		<xref target="RFC3501"/>
		<xref target="RFC3470"/>
		<xref target="RFC3436"/>
		<xref target="RFC3329"/>
		<xref target="RFC3261"/>
        <t indent="0" pn="section-1.1-2">
          <xref target="RFC3261" format="default" sectionFormat="of" derivedContent="RFC3261"/>
          <xref target="RFC3329" format="default" sectionFormat="of" derivedContent="RFC3329"/>
          <xref target="RFC3436" format="default" sectionFormat="of" derivedContent="RFC3436"/>
          <xref target="RFC3470" format="default" sectionFormat="of" derivedContent="RFC3470"/>
          <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/>
          <xref target="RFC3552" format="default" sectionFormat="of" derivedContent="RFC3552"/>
          <xref target="RFC3568" format="default" sectionFormat="of" derivedContent="RFC3568"/>
          <xref target="RFC3656" format="default" sectionFormat="of" derivedContent="RFC3656"/>
          <xref target="RFC3749" format="default" sectionFormat="of" derivedContent="RFC3749"/>
          <xref target="RFC3767" format="default" sectionFormat="of" derivedContent="RFC3767"/>
          <xref target="RFC3856" format="default" sectionFormat="of" derivedContent="RFC3856"/>
          <xref target="RFC3871" format="default" sectionFormat="of" derivedContent="RFC3871"/>
          <xref target="RFC3887" format="default" sectionFormat="of" derivedContent="RFC3887"/>
          <xref target="RFC3903" format="default" sectionFormat="of" derivedContent="RFC3903"/>
          <xref target="RFC3943" format="default" sectionFormat="of" derivedContent="RFC3943"/>
          <xref target="RFC3983" format="default" sectionFormat="of" derivedContent="RFC3983"/>
          <xref target="RFC4097" format="default" sectionFormat="of" derivedContent="RFC4097"/>
          <xref target="RFC4111" format="default" sectionFormat="of" derivedContent="RFC4111"/>
          <xref target="RFC4162" format="default" sectionFormat="of" derivedContent="RFC4162"/>
          <xref target="RFC4168" format="default" sectionFormat="of" derivedContent="RFC4168"/>
          <xref target="RFC4217" format="default" sectionFormat="of" derivedContent="RFC4217"/>
          <xref target="RFC4235" format="default" sectionFormat="of" derivedContent="RFC4235"/>
          <xref target="RFC4261" format="default" sectionFormat="of" derivedContent="RFC4261"/>
          <xref target="RFC4279" format="default" sectionFormat="of" derivedContent="RFC4279"/>
          <xref target="RFC4497" format="default" sectionFormat="of" derivedContent="RFC4497"/>
          <xref target="RFC4513" format="default" sectionFormat="of" derivedContent="RFC4513"/>
          <xref target="RFC4531" format="default" sectionFormat="of" derivedContent="RFC4531"/>
          <xref target="RFC4540" format="default" sectionFormat="of" derivedContent="RFC4540"/>
          <xref target="RFC4582" format="default" sectionFormat="of" derivedContent="RFC4582"/>
          <xref target="RFC4616" format="default" sectionFormat="of" derivedContent="RFC4616"/>
          <xref target="RFC4642" format="default" sectionFormat="of" derivedContent="RFC4642"/>
          <xref target="RFC4680" format="default" sectionFormat="of" derivedContent="RFC4680"/>
          <xref target="RFC4681" format="default" sectionFormat="of" derivedContent="RFC4681"/>
          <xref target="RFC4712" format="default" sectionFormat="of" derivedContent="RFC4712"/>
          <xref target="RFC4732" format="default" sectionFormat="of" derivedContent="RFC4732"/>
          <xref target="RFC4785" format="default" sectionFormat="of" derivedContent="RFC4785"/>
          <xref target="RFC4791" format="default" sectionFormat="of" derivedContent="RFC4791"/>
          <xref target="RFC4823" format="default" sectionFormat="of" derivedContent="RFC4823"/>
          <xref target="RFC4851" format="default" sectionFormat="of" derivedContent="RFC4851"/>
          <xref target="RFC4964" format="default" sectionFormat="of" derivedContent="RFC4964"/>
          <xref target="RFC4975" format="default" sectionFormat="of" derivedContent="RFC4975"/>
          <xref target="RFC4976" format="default" sectionFormat="of" derivedContent="RFC4976"/>
          <xref target="RFC4992" format="default" sectionFormat="of" derivedContent="RFC4992"/>
          <xref target="RFC5018" format="default" sectionFormat="of" derivedContent="RFC5018"/>
          <xref target="RFC5019" format="default" sectionFormat="of" derivedContent="RFC5019"/>
          <xref target="RFC5023" format="default" sectionFormat="of" derivedContent="RFC5023"/>
          <xref target="RFC5024" format="default" sectionFormat="of" derivedContent="RFC5024"/>
          <xref target="RFC5049" format="default" sectionFormat="of" derivedContent="RFC5049"/>
          <xref target="RFC5054" format="default" sectionFormat="of" derivedContent="RFC5054"/>
          <xref target="RFC5091" format="default" sectionFormat="of" derivedContent="RFC5091"/>
          <xref target="RFC5158" format="default" sectionFormat="of" derivedContent="RFC5158"/>
          <xref target="RFC5216" format="default" sectionFormat="of" derivedContent="RFC5216"/>
          <xref target="RFC5238" format="default" sectionFormat="of" derivedContent="RFC5238"/>
          <xref target="RFC5263" format="default" sectionFormat="of" derivedContent="RFC5263"/>
          <xref target="RFC5281" format="default" sectionFormat="of" derivedContent="RFC5281"/>
          <xref target="RFC5364" format="default" sectionFormat="of" derivedContent="RFC5364"/>
          <xref target="RFC5415" format="default" sectionFormat="of" derivedContent="RFC5415"/>
          <xref target="RFC5422" format="default" sectionFormat="of" derivedContent="RFC5422"/>
          <xref target="RFC5456" format="default" sectionFormat="of" derivedContent="RFC5456"/>
          <xref target="RFC5734" format="default" sectionFormat="of" derivedContent="RFC5734"/>
          <xref target="RFC5878" format="default" sectionFormat="of" derivedContent="RFC5878"/>
          <xref target="RFC6012" format="default" sectionFormat="of" derivedContent="RFC6012"/>
          <xref target="RFC6042" format="default" sectionFormat="of" derivedContent="RFC6042"/>
          <xref target="RFC6083" format="default" sectionFormat="of" derivedContent="RFC6083"/>
          <xref target="RFC6084" format="default" sectionFormat="of" derivedContent="RFC6084"/>
          <xref target="RFC6176" format="default" sectionFormat="of" derivedContent="RFC6176"/>
          <xref target="RFC6353" format="default" sectionFormat="of" derivedContent="RFC6353"/>
          <xref target="RFC6367" format="default" sectionFormat="of" derivedContent="RFC6367"/>
          <xref target="RFC6739" format="default" sectionFormat="of" derivedContent="RFC6739"/>
          <xref target="RFC6749" format="default" sectionFormat="of" derivedContent="RFC6749"/>
          <xref target="RFC6750" format="default" sectionFormat="of" derivedContent="RFC6750"/>
          <xref target="RFC7030" format="default" sectionFormat="of" derivedContent="RFC7030"/>
          <xref target="RFC7465" format="default" sectionFormat="of" derivedContent="RFC7465"/>
          <xref target="RFC7525" format="default" sectionFormat="of" derivedContent="RFC7525"/>
          <xref target="RFC7562" format="default" sectionFormat="of" derivedContent="RFC7562"/>
          <xref target="RFC7568" format="default" sectionFormat="of" derivedContent="RFC7568"/>
          <xref target="RFC8261" format="default" sectionFormat="of" derivedContent="RFC8261"/>
          <xref target="RFC8422" format="default" sectionFormat="of" derivedContent="RFC8422"/>
        </t>

	<t>The
        <t indent="0" pn="section-1.1-3">The status of <xref target="RFC7562"/>, <xref target="RFC6042"/>,
		<xref target="RFC5456"/>, <xref target="RFC5024"/>,
		<xref target="RFC4540"/>, and <xref target="RFC3656"/> target="RFC7562" format="default" sectionFormat="of" derivedContent="RFC7562"/>, <xref target="RFC6042" format="default" sectionFormat="of" derivedContent="RFC6042"/>,
		<xref target="RFC5456" format="default" sectionFormat="of" derivedContent="RFC5456"/>, <xref target="RFC5024" format="default" sectionFormat="of" derivedContent="RFC5024"/>,
		<xref target="RFC4540" format="default" sectionFormat="of" derivedContent="RFC4540"/>, and <xref target="RFC3656" format="default" sectionFormat="of" derivedContent="RFC3656"/> will be
		updated with permission of the Independent Stream Submissions Editor.
        </t>

        <t>In addition
        <t indent="0" pn="section-1.1-4">In addition, these RFCs normatively refer to TLSv1.0 TLS 1.0 or TLSv1.1 TLS 1.1 and
        have already been obsoleted; they are still listed here and marked as
        updated by this document in order to reiterate that any usage of the
            obsolete protocol should still use modern TLS:
	        <xref target="RFC5953"/>
        <xref target="RFC5101"/> <xref target="RFC5081"/>
        <xref target="RFC5077"/> <xref target="RFC4934"/> <xref
        target="RFC4572"/> <xref target="RFC4507"/> <xref target="RFC4492"/>
        <xref target="RFC4366"/> <xref target="RFC4347"/> <xref
        target="RFC4244"/> <xref target="RFC4132"/> <xref target="RFC3920"/>
        <xref target="RFC3734"/> <xref target="RFC3588"/> <xref
        target="RFC3546"/> <xref target="RFC3489"/> <xref
        target="RFC3316"/></t>

	<t>Note target="RFC3316" format="default" sectionFormat="of" derivedContent="RFC3316"/>,
	        <xref target="RFC3489" format="default" sectionFormat="of" derivedContent="RFC3489"/>,
	        <xref target="RFC3546" format="default" sectionFormat="of" derivedContent="RFC3546"/>,
	        <xref target="RFC3588" format="default" sectionFormat="of" derivedContent="RFC3588"/>,
                <xref target="RFC3734" format="default" sectionFormat="of" derivedContent="RFC3734"/>,
		<xref target="RFC3920" format="default" sectionFormat="of" derivedContent="RFC3920"/>,
		<xref target="RFC4132" format="default" sectionFormat="of" derivedContent="RFC4132"/>,
		<xref target="RFC4244" format="default" sectionFormat="of" derivedContent="RFC4244"/>,
		<xref target="RFC4347" format="default" sectionFormat="of" derivedContent="RFC4347"/>,
		<xref target="RFC4366" format="default" sectionFormat="of" derivedContent="RFC4366"/>,
		<xref target="RFC4492" format="default" sectionFormat="of" derivedContent="RFC4492"/>,
		<xref target="RFC4507" format="default" sectionFormat="of" derivedContent="RFC4507"/>,
		<xref target="RFC4572" format="default" sectionFormat="of" derivedContent="RFC4572"/>,
		<xref target="RFC4582" format="default" sectionFormat="of" derivedContent="RFC4582"/>,
		<xref target="RFC4934" format="default" sectionFormat="of" derivedContent="RFC4934"/>,
		<xref target="RFC5077" format="default" sectionFormat="of" derivedContent="RFC5077"/>,
		<xref target="RFC5081" format="default" sectionFormat="of" derivedContent="RFC5081"/>,
		<xref target="RFC5101" format="default" sectionFormat="of" derivedContent="RFC5101"/>, and
		<xref target="RFC5953" format="default" sectionFormat="of" derivedContent="RFC5953"/>.</t>
        <t indent="0" pn="section-1.1-5">Note that <xref target="RFC4642"/> target="RFC4642" format="default" sectionFormat="of" derivedContent="RFC4642"/> has already been
        updated by <xref target="RFC8143"/>, target="RFC8143" format="default" sectionFormat="of" derivedContent="RFC8143"/>, which makes an overlapping, but
        not quite identical, update as this document.</t>

        <t><xref target="RFC6614"/>
        <t indent="0" pn="section-1.1-6"><xref target="RFC6614" format="default" sectionFormat="of" derivedContent="RFC6614"/> has a requirement for TLSv1.1 TLS 1.1 or later, although it
            only makes an informative reference to <xref target="RFC4346"/>. target="RFC4346" format="default" sectionFormat="of" derivedContent="RFC4346"/>.
            This requirement is updated to be for TLSv1.2 TLS 1.2 or later.</t>

	<t><xref target="RFC6460"/>, <xref target="RFC4744"/>, and <xref target="RFC4743"/>
        <t indent="0" pn="section-1.1-7"><xref target="RFC6460" format="default" sectionFormat="of" derivedContent="RFC6460"/>, <xref target="RFC4744" format="default" sectionFormat="of" derivedContent="RFC4744"/>, and <xref target="RFC4743" format="default" sectionFormat="of" derivedContent="RFC4743"/>
	are already Historic; they are still listed here and marked as
        updated by this document in order to reiterate that any usage of the
        obsolete protocol should still use modern TLS.</t>

        <t>This
        <t indent="0" pn="section-1.1-8">This document updates DTLS <xref target="RFC6347"/>.  <xref
        target="RFC6347"/> target="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"/>.  <xref target="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"/> had allowed for negotiating the use of DTLSv1.0, DTLS 1.0,
        which is now forbidden.</t>

        <t>The
        <t indent="0" pn="section-1.1-9">The DES and IDEA International Data Encryption Algorithm (IDEA) cipher suites
	specified in <xref
        target="RFC5469"/> target="RFC5469" format="default" sectionFormat="of" derivedContent="RFC5469"/> were specifically removed from TLSv1.2 TLS 1.2 by
        <xref target="RFC5246"/>; target="RFC5246" format="default" sectionFormat="of" derivedContent="RFC5246"/>; since the only versions of TLS for which
        their usage is defined are now Historic, RFC 5469 (will be|has been) <xref target="RFC5469" format="default" sectionFormat="of" derivedContent="RFC5469"/> has been
        moved to Historic as well.</t>

        <t>The
        <t indent="0" pn="section-1.1-10">The version-fallback Signaling Cipher Suite Value specified in
        <xref target="RFC7507"/> target="RFC7507" format="default" sectionFormat="of" derivedContent="RFC7507"/> was defined to detect when a given client
        and server negotiate a lower version of (D)TLS than their highest
        shared version.  TLSv1.3  TLS 1.3 (<xref target="RFC8446"/>) target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>) incorporates a
        different mechanism that achieves this purpose, via sentinel values in
        the ServerHello.Random field.  With (D)TLS versions prior to 1.2 fully
        deprecated, the only way for (D)TLS implementations to negotiate a
        lower version than their highest shared version would be to negotiate
        (D)TLSv1.2
        (D)TLS 1.2 while supporting (D)TLSv1.3; (D)TLS 1.3; supporting (D)TLSv1.3 (D)TLS 1.3 implies
        support for the ServerHello.Random mechanism.  Accordingly, the
        functionality from <xref target="RFC7507"/> target="RFC7507" format="default" sectionFormat="of" derivedContent="RFC7507"/> has been superseded, and
        this document marks it as Obsolete.</t>
      </section>
      <section title="Terminology">
        <t>The numbered="true" toc="include" removeInRFC="false" pn="section-1.2">
        <name slugifiedName="name-terminology">Terminology</name>
        <t indent="0" pn="section-1.2-1">
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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
        "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP
        14 BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
    </section>
    <section title="Support for Deprecation">
      <!-- Removing per WGLC Feedback from Martin Thomson
      <t>Industry has actively followed guidance provided by NIST and the PCI
      Council to deprecate TLSv1.0 and TLSv1.1 by June 30, 2018. TLSv1.2
      should remain a minimum baseline numbered="true" toc="include" anchor="support" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-support-for-deprecation">Support for TLS support at this time.</t>
      -->

      <t>Specific Deprecation</name>
      <t indent="0" pn="section-2-1">Specific details on attacks against TLSv1.0 TLS 1.0 and TLSv1.1, TLS 1.1, as well as
      their mitigations, are provided in <xref target="NIST800-52r2"/>,
      RFC 7457 <xref target="RFC7457"/> target="NIST800-52r2" format="default" sectionFormat="of" derivedContent="NIST800-52r2"/>,
      <xref target="RFC7457" format="default" sectionFormat="of" derivedContent="RFC7457"/>, and other
      RFCs referenced therein. Although mitigations for the current known
      vulnerabilities have been developed, any future issues discovered in old
      protocol versions might not be mitigated in older library versions when
      newer library versions do not support those old protocols.</t>

      <!--
          Note that the use of "TLS 1.1" etc in the
      <t indent="0" pn="section-2-2">For example, NIST quote below is
          deliberately not as used elsewhere in this document where we try
          be consistent with e.g. "TLSv1.1" - that's just because this
          is a quote from NIST.
      -->

      <t>NIST for example has provided the following rationale, copied with
      permission from <xref target="NIST800-52r2"/>,
      section 1.2 Section 1.1, "History of TLS" (with references changed for RFC
          formatting).

      <list>
          <t>TLS TLS", of <xref target="NIST800-52r2" format="default" sectionFormat="of" derivedContent="NIST800-52r2"/>:
      </t>
      <blockquote pn="section-2-3">
        <t indent="0" pn="section-2-3.1">TLS 1.1, specified in <xref target="RFC4346"/>, RFC 4346 [24], was developed to
          address weaknesses discovered in TLS 1.0, primarily in the areas of
          initialization vector selection and padding error processing.
          Initialization vectors were made explicit to prevent a certain class
          of attacks on the Cipher Block Chaining (CBC) mode of operation used
          by TLS. The handling of padding errors was altered to treat a
          padding error as a bad message authentication code, code rather than a
          decryption failure. In addition, the TLS 1.1 RFC acknowledges
          attacks on CBC mode that rely on the time to compute the message
          authentication code (MAC). The TLS 1.1 specification states that to
          defend against such attacks, an implementation must process records
          in the same manner regardless of whether padding errors exist.
          Further implementation considerations for CBC modes (which were not
          included in <xref target="RFC4346">RFC4346</xref>) RFC 4346 [24]) are discussed in
          Section 3.3.2.</t>

          <!--subcompact="yes" above isn't nice here - add lines -->

          <t/>

          <t>TLSv1.2,
        <t indent="0" pn="section-2-3.2">TLS 1.2, specified in <xref target="RFC5246">RFC5246</xref>, RFC 5246 [25], made
          several cryptographic enhancements, particularly in the area of hash
          functions, with the ability to use or specify the SHA-2 family of
          algorithms for hash, MAC, and Pseudorandom Function (PRF)
          computations. TLSv1.2 TLS 1.2 also adds authenticated encryption with
          associated data (AEAD) cipher suites.</t>

          <t/>

          <t>TLSv1.3,
        <t indent="0" pn="section-2-3.3">TLS 1.3, specified in <xref target="RFC8446">TLSv1.3</xref>, RFC 8446 [57],
          represents a significant change to TLS that aims to address threats
          that have arisen over the years.  Among the changes are a new handshake protocol, a new key derivation process that uses the HMAC-based Extract-and-Expand Key Derivation Function (HKDF), (HKDF) [37], and the removal of cipher suites that use static RSA key transport or DH static Diffie-Hellman ( DH) [sic] key exchanges, the CBC mode of operation, or SHA-1. The list of Many extensions that can be used with TLSv1.3 has been reduced
          considerably.</t>
        </list></t>

      <!--
      <t>The German Federal Office defined for Information Security, recommends
      against use of with TLS versions less than 1.2 in the publication <xref
      target="TR-02102-2">Cryptographic Mechanisms: Recommendations and Key
      Lengths</xref>.</t>
-->

      <!--  Removing per WGLC feedback from Martin Thomson
      <t>The Canadian government treasury board have also mandated that these
      old previous versions of TLS not cannot be used. <xref target="Canada"/></t>

      <t>Various companies and web sites have announced plans to deprecate
      these old versions of TLS.</t>
      --> used with TLS 1.3.</t>
      </blockquote>
    </section>

    <!--
		 removing as per IETF-103 meeting
    <section title="Removing Support">

      <t>[[This section can be removed upon publication - or maybe keep it?]]</t>

      <t>Support for TLSv1.0 has been removed by the July 2018 PCI deadline from the
      following standards, products, numbered="true" toc="include" anchor="sha-1" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-sha-1-usage-problematic-in-">SHA-1 Usage Problematic in TLS 1.0 and services:</t>

      <t><list style="symbols">
          <t>3GPP 5G</t>
          <t>Amazon Elastic Load Balancing <xref target="Amazon"/></t>
          <t>CloudFlare <xref target="CloudFlare"/></t>
	  	  <t>Digicert <xref target="Digicert"/></t>
          <t>GitHub <xref target="GIT"/></t>
          <t>KeyCDN <xref target="KeyCDN"/></t>
          <t>PayPal <xref target="paypal"/></t>
		  <t>Stripe <xref target="stripe"/></t>
          <t>Google Chrome <xref target="chrome"/></t>
          <t>Microsoft Edge <xref target="edge"/></t>
          <t>[[Numerous web sites...]]</t>

        </list></t>

      <t>Many web sites have taken the action TLS 1.1</name>
      <t indent="0" pn="section-3-1">The integrity of including the deprecation both TLS 1.0 and TLS 1.1 depends on a running SHA-1
      hash of
      TLSv1.1 into their plans for deprecating TLSv1.0 for the PCI council
      deadline. Support for TLSv1.1 has been removed exchanged messages. This makes it possible to perform a
      downgrade attack on the handshake by an attacker able to perform 2<sup>77</sup>
      operations, well below the July 2018 PCI deadline
      from acceptable modern security margin.</t>
      <t indent="0" pn="section-3-2">Similarly, the following standards, products, and services:</t>

      <t><list style="symbols">
          <t>3GPP 5G Release 16</t>
          <t>Amazon Elastic Load Balancing <xref target="Amazon"/></t>
          <t>CloudFlare <xref target="CloudFlare"/></t>
          <t>GitHub <xref target="GIT"/></t>
          <t>PayPal <xref target="paypal"/></t>
		  <t>Stripe <xref target="stripe"/></t>
          <t>[[Numerous web sites...]]</t>

        </list></t>
	</section>

	-->

    <!--
		 removing as per IETF-103 meeting

    <section title="Usage">
      <t>[[This section can be removed upon publication - or maybe keep it?]]</t>

	  <section title="Web">

			  <t>Usage statistics for TLSv1.0 and TLSv1.1 on authentication of the public web vary, but have
					 been in general very low handshake depends on signatures
      made using a SHA-1 hash or a concatenation of MD5 and declined further with SHA-1
      hashes that is not appreciably stronger than a SHA-1 hash, allowing the impending
      PCI deadline attacker to migrate off of TLSv1.0 by June 30, 2018. As of January
	  2018, <xref target="StackExchange"/> quoted 4 percent
      of browsers using TLSv1.0.</t>

    <t> The number of websites supporting TLSv1.2 impersonate a server when it is still growing (+0.4%), and has
     reached 92% according able to sslpulse as of June 19, 2018.
	 <xref target="SSLpulse"/> Deprecating
      break the severely weakened SHA-1 hash.</t>
      <t indent="0" pn="section-3-3">Neither TLS 1.0 and nor TLS 1.1 will thus not have allows the peers to select a major impact on browser stronger hash
      for signatures in the ServerKeyExchange or web server
	 implementations.
     </t>

	-->

    <!--
      <t><xref target="Alexa">The Top 1 Million Analysis</xref> from
      February 2018 shows that CertificateVerify messages,
      making the only upgrade path the use of a newer protocol version.</t>
      <t indent="0" pn="section-3-4">See <xref target="Bhargavan2016" format="default" sectionFormat="of" derivedContent="Bhargavan2016"/> for additional details.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-do-not-use-tls-10">Do Not Use TLS 1.0</name>
      <t indent="0" pn="section-4-1">TLS 1.0 <bcp14>MUST NOT</bcp14> be used.
      Negotiation of TLS 1.0 from any version of TLS <bcp14>MUST NOT</bcp14> be
      permitted.</t>
      <t indent="0" pn="section-4-2">Any other version of TLS is more secure than TLS 1.0. While TLS 1.0 can be
      configured to prevent some types of interception, using the sites surveyed, highest version
      available is preferred.</t>
      <t indent="0" pn="section-4-3">Pragmatically, clients <bcp14>MUST NOT</bcp14> send a ClientHello with
      ClientHello.client_version set to {03,01}.  Similarly, servers <bcp14>MUST NOT</bcp14>
      send a ServerHello with ServerHello.server_version set to {03,01}.  Any
      party receiving a Hello message with the vast majority
      support TLSv1.2 (97.9 percent), protocol version set to {03,01}
      <bcp14>MUST</bcp14> respond with a mere 2.0 percent using TLSv1.0 "protocol_version" alert message and an even smaller percentage using TLSv1.1.
	-->

    <!--
	<t><xref target="web-stats"/> presents statistics for use of close the
      connection.</t>
      <t indent="0" pn="section-4-4">Historically, TLS versions in specifications were not clear on what the web.</t>

<figure anchor="web-stats" title="Web Statistics" >
<artwork><![CDATA[
+- - - - - - - - - - - - - - - - +- - - - - - - - - - +- - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +
| Name/Ref       | Date     | SSLv3|TLSv1.0|TLSv1.1|TLSv1.2|TLSv1.3|
+-  - - - - - - - - - - - - - - - +- - - - - - - - - - +- - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +
! Alexa [1]      | 20180226 |    - |   2.0 |  <0.1 |  97.9 |     - |
| Cloudflare [2] | 20180518 |  0.0 |   9.3 |   0.2 |  84.9 |   5.5 |
| Firefox [3]    | 20180709 |    - |   1.0 |     - |  94.0 |   5.0 |
| Chrome [4]     | 20180711 |    - |   0.4 |  <0.1 |    -  |     core - |
+- - - - - - - - - - - - - - - - +- - - - - - - - - - +- - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +
[https://scotthelme.co.uk/alexa-top-1-million-analysis-february-2018/
[2] https://www.ietf.org/mail-archive/web/tls/current/msg26578.html
[3] https://www.ietf.org/mail-archive/web/tls/current/msg26575.html
[4] https://www.ietf.org/mail-archive/web/tls/current/msg26620.html
  ]]></artwork>
</figure>

		</section>

		<section title="Mail">

				<t>E-Mail uses TLS for SMTP, submission (port 587), POP/POP3 and IMAP.
						Typically email deployments lag public web deployments in
						terms of the rate of adoption of new TLS versions. record
      layer version number (TLSPlaintext.version) could contain when sending
      a ClientHello message. <xref target="mail-stats"/> presents statistics for use of target="RFC5246" sectionFormat="of" section="E" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5246#appendix-E" derivedContent="RFC5246"/> notes that TLSPlaintext.version
      could be selected to maximize interoperability, though no definitive
      value is identified as ideal. That guidance is still applicable;
      therefore, TLS versions in servers <bcp14>MUST</bcp14> accept any value {03,XX} (including {03,00})
      as the email applications.</t>

-->

    <!--
				<t>In one 2018 ZMap-based study <xref target="clusters"/> of
						~200,000 mail server IP addresses in 10 countries, use
						of TLSv1.0 record layer version number for various ClientHello, but they <bcp14>MUST NOT</bcp14>
      negotiate TLS services (both web and mail)
						on IP addresses that host some mail service was seen at
						10.6%. 1.0.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-do-not-use-tls-11">Do Not Use TLS 1.1</name>
      <t indent="0" pn="section-5-1">TLS 1.1 <bcp14>MUST NOT</bcp14> be used. Negotiation of TLSv1.1 was negligible - at 0.01%, for
					   TLSv1.1,	SSLv3 was twice as common.  TLSv1.2 was used for 89.3% TLS 1.1 from any version of
						services and no TLSv1.3 was seen.</t>
				-->

    <!--

<figure anchor="mail-stats" title="Mail Statistics" >
<artwork><![CDATA[
+- - - - - - - - - - - - - - - - +- - - - - - - - - - +- - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +
| Name/Ref       | Date     | SSLv3|TLSv1.0|TLSv1.1|TLSv1.2|TLSv1.3|
+- - - - - - - - - - - - - - - - +- - - - - - - - - - +- - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +
| Clusters [1]   | 20180316 | <0.1 |  10.6 |  <0.1 |  89.3 |     - |
| TLSA [2]       | 20180710 |    - |   1.4 |   0.1 |  98.5 |     - |
| UK-ESP [3]     | 20180710 |    - |  19.9 |  <0.1 |    -  |     - |
+- - - - - - - - - - - - - - - - +- - - - - - - - - - +- - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +- - - -
      TLS <bcp14>MUST NOT</bcp14> be permitted.</t>
      <t indent="0" pn="section-5-2">Pragmatically, clients <bcp14>MUST NOT</bcp14> send a ClientHello with
      ClientHello.client_version set to {03,02}.  Similarly, servers <bcp14>MUST NOT</bcp14>
      send a ServerHello with ServerHello.server_version set to {03,02}.  Any
      party receiving a Hello message with the protocol version set to {03,02}
      <bcp14>MUST</bcp14> respond with a "protocol_version" alert message and close the
      connection.</t>
      <t indent="0" pn="section-5-3">Any newer version of TLS is more secure than TLS 1.1. While TLS 1.1 can be
      configured to prevent some types of interception, using the highest version
      available is preferred. Support for TLS 1.1 is dwindling in libraries
      and will impact security going forward if mitigations for attacks cannot
      be easily addressed and supported in older libraries.</t>
      <t indent="0" pn="section-5-4">Historically, TLS specifications were not clear on what the record
      layer version number (TLSPlaintext.version) could contain when sending
      a ClientHello message. <xref target="RFC5246" sectionFormat="of" section="E" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5246#appendix-E" derivedContent="RFC5246"/> notes that TLSPlaintext.version
      could be selected to maximize interoperability, though no definitive
      value is identified as ideal. That guidance is still applicable;
      therefore, TLS servers <bcp14>MUST</bcp14> accept any value {03,XX} (including {03,00})
      as the record layer version number for ClientHello, but they <bcp14>MUST NOT</bcp14>
      negotiate TLS 1.1.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-updates-to-rfc-7525">Updates to RFC 7525</name>
      <t indent="0" pn="section-6-1"><xref target="RFC7525" format="default" sectionFormat="of" derivedContent="RFC7525">"Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"</xref>  is BCP 195, which is the
      most recent Best Current Practice for implementing TLS and was based on
      TLS 1.2. At the time of publication, TLS 1.0 and TLS 1.1 had not yet
      been deprecated. As such, BCP 195 is called out specifically to
      update text implementing the deprecation recommendations of this
      document.</t>
      <t indent="0" pn="section-6-2">This document updates <xref target="RFC7525" sectionFormat="of" section="3.1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7525#section-3.1.1" derivedContent="RFC7525"/> by
      changing <bcp14>SHOULD NOT</bcp14> to <bcp14>MUST NOT</bcp14> as follows:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6-3">
        <li pn="section-6-3.1">
          <t indent="0" pn="section-6-3.1.1">Implementations <bcp14>MUST NOT</bcp14> negotiate TLS version 1.0 <xref target="RFC2246" format="default" sectionFormat="of" derivedContent="RFC2246"/>.</t>
          <t indent="0" pn="section-6-3.1.2"> 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 and does not warn against
          common padding errors. </t>
        </li>
        <li pn="section-6-3.2">
          <t indent="0" pn="section-6-3.2.1">Implementations <bcp14>MUST NOT</bcp14> negotiate TLS version 1.1 <xref target="RFC4346" format="default" sectionFormat="of" derivedContent="RFC4346"/>. </t>
          <t indent="0" pn="section-6-3.2.2"> Rationale: TLS 1.1
          (published in 2006) is a security improvement over TLS 1.0 but still
          does not support certain stronger cipher suites.</t>
        </li>
      </ul>
      <t indent="0" pn="section-6-4">This document updates <xref target="RFC7525" sectionFormat="of" section="3.1.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7525#section-3.1.2" derivedContent="RFC7525"/> by
      changing <bcp14>SHOULD NOT</bcp14> to <bcp14>MUST NOT</bcp14> and adding a reference to RFC 6347 as follows:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6-5">
        <li pn="section-6-5.1">
          <t indent="0" pn="section-6-5.1.1">Implementations <bcp14>MUST NOT</bcp14> negotiate DTLS version 1.0 <xref target="RFC4347" format="default" sectionFormat="of" derivedContent="RFC4347"/> <xref target="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"/>. </t>
          <t indent="0" pn="section-6-5.1.2"> Version 1.0 of DTLS correlates to version 1.1 of
          TLS (see above).</t>
        </li>
      </ul>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-operational-considerations">Operational Considerations</name>
      <t indent="0" pn="section-7-1">

            This document is part of BCP 195 and, as such, reflects the
            understanding of the IETF (at the time of this document's publication) as to the
            best practices for TLS and DTLS usage.
      </t>
      <t indent="0" pn="section-7-2">
            Though TLS 1.1 has been obsolete since the publication of <xref target="RFC5246" format="default" sectionFormat="of" derivedContent="RFC5246"/>
            in 2008, and DTLS 1.0 has been obsolete since the publication of <xref target="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"/> in 2012, there may remain some
	    systems in operation that do not
            support (D)TLS 1.2 or higher. Adopting the practices recommended by
            this document for any systems that need to communicate with the
            aforementioned class of systems will cause failure to interoperate.
            However, disregarding the recommendations of this document in order
            to continue to interoperate with the aforementioned class of systems
            incurs some amount of risk. The nature of the risks incurred by
            operating in contravention to the recommendations of this document
            are discussed in Sections <xref target="support" format="counter" sectionFormat="of" derivedContent="2"/> and
	    <xref target="sha-1" format="counter" sectionFormat="of" derivedContent="3"/>, and knowledge of those risks
            should be used along with any potential mitigating factors and the
            risks inherent to updating the systems in question when deciding how
            quickly to adopt the recommendations specified in this document.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-8-1">This document deprecates two older TLS protocol versions and one older
      DTLS protocol version for security
      reasons already described. The attack surface is reduced when there are
      a smaller number of supported protocols and fallback options are
      removed.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-9-1">This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references pn="section-10">
      <name slugifiedName="name-references">References</name>
      <references pn="section-10.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t indent="0">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="RFC2246" target="https://www.rfc-editor.org/info/rfc2246" quoteTitle="true" derivedAnchor="RFC2246">
          <front>
            <title>The TLS Protocol Version 1.0</title>
            <author initials="T." surname="Dierks" fullname="T. Dierks">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Allen" fullname="C. Allen">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1999" month="January"/>
            <abstract>
              <t indent="0">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="RFC3261" target="https://www.rfc-editor.org/info/rfc3261" quoteTitle="true" derivedAnchor="RFC3261">
          <front>
            <title>SIP: Session Initiation Protocol</title>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Camarillo" fullname="G. Camarillo">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Johnston" fullname="A. Johnston">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Peterson" fullname="J. Peterson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Sparks" fullname="R. Sparks">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Handley" fullname="M. Handley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Schooler" fullname="E. Schooler">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2002" month="June"/>
            <abstract>
              <t indent="0">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="RFC3329" target="https://www.rfc-editor.org/info/rfc3329" quoteTitle="true" derivedAnchor="RFC3329">
          <front>
            <title>Security Mechanism Agreement for the Session Initiation Protocol (SIP)</title>
            <author initials="J." surname="Arkko" fullname="J. Arkko">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Torvinen" fullname="V. Torvinen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Camarillo" fullname="G. Camarillo">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Niemi" fullname="A. Niemi">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Haukka" fullname="T. Haukka">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="January"/>
          </front>
          <seriesInfo name="RFC" value="3329"/>
          <seriesInfo name="DOI" value="10.17487/RFC3329"/>
        </reference>
        <reference anchor="RFC3436" target="https://www.rfc-editor.org/info/rfc3436" quoteTitle="true" derivedAnchor="RFC3436">
          <front>
            <title>Transport Layer Security over Stream Control Transmission Protocol</title>
            <author initials="A." surname="Jungmaier" fullname="A. Jungmaier">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Tuexen" fullname="M. Tuexen">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2002" month="December"/>
            <abstract>
              <t indent="0">This document describes the usage of the Transport Layer Security (TLS) protocol, as defined in RFC 2246, over the Stream Control Transmission Protocol (SCTP), as defined in RFC 2960 and RFC 3309. The user of TLS can take advantage of the features provided by SCTP, namely the support of multiple streams to avoid head of line blocking and the support of multi-homing to provide network level fault tolerance. Additionally, discussions of extensions of SCTP are also supported, meaning especially the support of dynamic reconfiguration of IP- addresses.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3436"/>
          <seriesInfo name="DOI" value="10.17487/RFC3436"/>
        </reference>
        <reference anchor="RFC3470" target="https://www.rfc-editor.org/info/rfc3470" quoteTitle="true" derivedAnchor="RFC3470">
          <front>
            <title>Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols</title>
            <author initials="S." surname="Hollenbeck" fullname="S. Hollenbeck">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Rose" fullname="M. Rose">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Masinter" fullname="L. Masinter">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="January"/>
            <abstract>
              <t indent="0">The Extensible Markup Language (XML) is a framework for structuring data.  While it evolved from Standard Generalized Markup Language (SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data. There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application.  There has been much interest in the use of XML as a representation method.  This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols.  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="70"/>
          <seriesInfo name="RFC" value="3470"/>
          <seriesInfo name="DOI" value="10.17487/RFC3470"/>
        </reference>
        <reference anchor="RFC3501" target="https://www.rfc-editor.org/info/rfc3501" quoteTitle="true" derivedAnchor="RFC3501">
          <front>
            <title>INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1</title>
            <author initials="M." surname="Crispin" fullname="M. Crispin">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="March"/>
            <abstract>
              <t indent="0">The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders.  IMAP4rev1 also provides the capability for an offline client to resynchronize with the server. IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof.  Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server.  A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3501"/>
          <seriesInfo name="DOI" value="10.17487/RFC3501"/>
        </reference>
        <reference anchor="RFC3552" target="https://www.rfc-editor.org/info/rfc3552" quoteTitle="true" derivedAnchor="RFC3552">
          <front>
            <title>Guidelines for Writing RFC Text on Security Considerations</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Korver" fullname="B. Korver">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="July"/>
            <abstract>
              <t indent="0">All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak.  This document provides guidelines to RFC authors on how to write a good Security Considerations section.   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="72"/>
          <seriesInfo name="RFC" value="3552"/>
          <seriesInfo name="DOI" value="10.17487/RFC3552"/>
        </reference>
        <reference anchor="RFC3568" target="https://www.rfc-editor.org/info/rfc3568" quoteTitle="true" derivedAnchor="RFC3568">
          <front>
            <title>Known Content Network (CN) Request-Routing Mechanisms</title>
            <author initials="A." surname="Barbir" fullname="A. Barbir">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Cain" fullname="B. Cain">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Nair" fullname="R. Nair">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="O." surname="Spatscheck" fullname="O. Spatscheck">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="July"/>
            <abstract>
              <t indent="0">This document presents a summary of Request-Routing techniques that are used to direct client requests to surrogates based on various policies and a possible set of metrics.  The document covers techniques that were commonly used in the industry on or before December 2000.  In this memo, the term Request-Routing represents techniques that is commonly called content routing or content redirection.  In principle, Request-Routing techniques can be classified under: DNS Request-Routing, Transport-layer Request-Routing, and Application-layer Request-Routing.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3568"/>
          <seriesInfo name="DOI" value="10.17487/RFC3568"/>
        </reference>
        <reference anchor="RFC3656" target="https://www.rfc-editor.org/info/rfc3656" quoteTitle="true" derivedAnchor="RFC3656">
          <front>
            <title>The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol</title>
            <author initials="R." surname="Siemborski" fullname="R. Siemborski">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="December"/>
            <abstract>
              <t indent="0">As the demand for high-performance mail delivery agents increases, it becomes apparent that single-machine solutions are inadequate to the task, both because of capacity limits and that the failure of the single machine means a loss of mail delivery for all users.  It is preferable to allow many machines to share the responsibility of mail delivery.  The Mailbox Update (MUPDATE) protocol allows a group of Internet Message Access Protocol (IMAP) or Post Office Protocol - Version 3 (POP3) servers to function with a unified mailbox namespace.  This document is intended to serve as a reference guide to that protocol.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3656"/>
          <seriesInfo name="DOI" value="10.17487/RFC3656"/>
        </reference>
        <reference anchor="RFC3749" target="https://www.rfc-editor.org/info/rfc3749" quoteTitle="true" derivedAnchor="RFC3749">
          <front>
            <title>Transport Layer Security Protocol Compression Methods</title>
            <author initials="S." surname="Hollenbeck" fullname="S. Hollenbeck">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="May"/>
            <abstract>
              <t indent="0">The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and to then apply the algorithm associated with the selected method as part of the TLS Record Protocol.  TLS defines one standard compression method which specifies that data exchanged via the record protocol will not be compressed.  This document describes an additional compression method associated with a lossless data compression algorithm for use with TLS, and it describes a method for the specification of additional TLS compression methods.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3749"/>
          <seriesInfo name="DOI" value="10.17487/RFC3749"/>
        </reference>
        <reference anchor="RFC3767" target="https://www.rfc-editor.org/info/rfc3767" quoteTitle="true" derivedAnchor="RFC3767">
          <front>
            <title>Securely Available Credentials Protocol</title>
            <author initials="S." surname="Farrell" fullname="S. Farrell" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="June"/>
            <abstract>
              <t indent="0">This document describes a protocol whereby a user can acquire cryptographic credentials (e.g., private keys, PKCS #15 structures) from a credential server, using a workstation that has locally trusted software installed, but with no user-specific configuration.  The protocol's payloads are described in XML.  This memo also specifies a Blocks Extensible Exchange Protocol (BEEP) profile of the protocol.  Security requirements are  met by mandating support for TLS and/or DIGEST-MD5 (through BEEP).  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3767"/>
          <seriesInfo name="DOI" value="10.17487/RFC3767"/>
        </reference>
        <reference anchor="RFC3856" target="https://www.rfc-editor.org/info/rfc3856" quoteTitle="true" derivedAnchor="RFC3856">
          <front>
            <title>A Presence Event Package for the Session Initiation Protocol (SIP)</title>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="August"/>
            <abstract>
              <t indent="0">This document describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of presence.  Presence is defined as the willingness and ability of a user to communicate with other users on the network.  Historically, presence has been limited to "on-line" and "off-line" indicators; the notion of presence here is broader.  Subscriptions and notifications of presence are supported by defining an event package within the general SIP event notification framework.  This protocol is also compliant with the Common Presence Profile (CPP) framework.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3856"/>
          <seriesInfo name="DOI" value="10.17487/RFC3856"/>
        </reference>
        <reference anchor="RFC3871" target="https://www.rfc-editor.org/info/rfc3871" quoteTitle="true" derivedAnchor="RFC3871">
          <front>
            <title>Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure</title>
            <author initials="G." surname="Jones" fullname="G. Jones" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="September"/>
            <abstract>
              <t indent="0">This document defines a list of operational security requirements for the infrastructure of large Internet Service Provider (ISP) IP networks (routers and switches).  A framework is defined for specifying "profiles", which are collections of requirements applicable to certain network topology contexts (all, core-only, edge-only...).  The goal is to provide network operators a clear, concise way of communicating their security requirements to vendors.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3871"/>
          <seriesInfo name="DOI" value="10.17487/RFC3871"/>
        </reference>
        <reference anchor="RFC3887" target="https://www.rfc-editor.org/info/rfc3887" quoteTitle="true" derivedAnchor="RFC3887">
          <front>
            <title>Message Tracking Query Protocol</title>
            <author initials="T." surname="Hansen" fullname="T. Hansen">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="September"/>
            <abstract>
              <t indent="0">Customers buying enterprise message systems often ask: Can I track the messages?  Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message.  This document describes the Message Tracking Query Protocol that is used in conjunction with extensions to the ESMTP protocol to provide a complete message tracking solution for the Internet.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3887"/>
          <seriesInfo name="DOI" value="10.17487/RFC3887"/>
        </reference>
        <reference anchor="RFC3903" target="https://www.rfc-editor.org/info/rfc3903" quoteTitle="true" derivedAnchor="RFC3903">
          <front>
            <title>Session Initiation Protocol (SIP) Extension for Event State Publication</title>
            <author initials="A." surname="Niemi" fullname="A. Niemi" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="October"/>
            <abstract>
              <t indent="0">This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the SIP Events framework.  The first application of this extension is for the publication of presence information. </t>
              <t indent="0"> The mechanism described in this document can be extended to support publication of any event state for which there exists an appropriate event package.  It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3903"/>
          <seriesInfo name="DOI" value="10.17487/RFC3903"/>
        </reference>
        <reference anchor="RFC3943" target="https://www.rfc-editor.org/info/rfc3943" quoteTitle="true" derivedAnchor="RFC3943">
          <front>
            <title>Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)</title>
            <author initials="R." surname="Friend" fullname="R. Friend">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="November"/>
            <abstract>
              <t indent="0">The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and then to apply the algorithm associated with the selected method as part of the TLS Record Protocol.  TLS defines one standard compression method, which specifies that data exchanged via the record protocol will not be compressed.  This document describes an additional compression method associated with the Lempel-Ziv-Stac (LZS) lossless data compression algorithm for use with TLS.  This document also defines the application of the LZS algorithm to the TLS Record Protocol.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3943"/>
          <seriesInfo name="DOI" value="10.17487/RFC3943"/>
        </reference>
        <reference anchor="RFC3983" target="https://www.rfc-editor.org/info/rfc3983" quoteTitle="true" derivedAnchor="RFC3983">
          <front>
            <title>Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)</title>
            <author initials="A." surname="Newton" fullname="A. Newton">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Sanz" fullname="M. Sanz">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="January"/>
            <abstract>
              <t indent="0">This document specifies how to use the Blocks Extensible Exchange Protocol (BEEP) as the application transport substrate for the Internet Registry Information Service (IRIS).  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3983"/>
          <seriesInfo name="DOI" value="10.17487/RFC3983"/>
        </reference>
        <reference anchor="RFC4097" target="https://www.rfc-editor.org/info/rfc4097" quoteTitle="true" derivedAnchor="RFC4097">
          <front>
            <title>Middlebox Communications (MIDCOM) Protocol Evaluation</title>
            <author initials="M." surname="Barnes" fullname="M. Barnes" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="June"/>
            <abstract>
              <t indent="0">This document provides an evaluation of the applicability of SNMP (Simple Network Management Protocol), RSIP (Realm Specific Internet Protocol), Megaco, Diameter, and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol.  A summary of each of the proposed protocols against the MIDCOM requirements and the MIDCOM framework is provided.  Compliancy of each of the protocols against each requirement is detailed.  A conclusion summarizes how each of the protocols fares in the evaluation.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4097"/>
          <seriesInfo name="DOI" value="10.17487/RFC4097"/>
        </reference>
        <reference anchor="RFC4111" target="https://www.rfc-editor.org/info/rfc4111" quoteTitle="true" derivedAnchor="RFC4111">
          <front>
            <title>Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)</title>
            <author initials="L." surname="Fang" fullname="L. Fang" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="July"/>
            <abstract>
              <t indent="0">This document addresses security aspects pertaining to Provider-Provisioned Virtual Private Networks (PPVPNs).  First, it describes the security threats in the context of PPVPNs and defensive techniques to combat those threats.  It considers security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers.  It also describes how these security attacks should be detected and reported.  It then discusses possible user requirements for security of a PPVPN service.  These user requirements translate into corresponding provider requirements.  In addition, the provider may have additional requirements to make its network infrastructure secure to a level that can meet the PPVPN customer's expectations. Finally, this document defines a template that may be used to describe and analyze the security characteristics of a specific PPVPN technology.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4111"/>
          <seriesInfo name="DOI" value="10.17487/RFC4111"/>
        </reference>
        <reference anchor="RFC4162" target="https://www.rfc-editor.org/info/rfc4162" quoteTitle="true" derivedAnchor="RFC4162">
          <front>
            <title>Addition of SEED Cipher Suites to Transport Layer Security (TLS)</title>
            <author initials="H.J." surname="Lee" fullname="H.J. Lee">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J.H." surname="Yoon" fullname="J.H. Yoon">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J.I." surname="Lee" fullname="J.I. Lee">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="August"/>
            <abstract>
              <t indent="0">This document proposes the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the SEED encryption algorithm as a bulk cipher algorithm.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4162"/>
          <seriesInfo name="DOI" value="10.17487/RFC4162"/>
        </reference>
        <reference anchor="RFC4168" target="https://www.rfc-editor.org/info/rfc4168" quoteTitle="true" derivedAnchor="RFC4168">
          <front>
            <title>The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)</title>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Camarillo" fullname="G. Camarillo">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="October"/>
            <abstract>
              <t indent="0">This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport mechanism between SIP (Session Initiation Protocol) entities.  SCTP is a new protocol that provides several features that may prove beneficial for transport between SIP entities that exchange a large amount of messages, including gateways and proxies.  As SIP is transport-independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4168"/>
          <seriesInfo name="DOI" value="10.17487/RFC4168"/>
        </reference>
        <reference anchor="RFC4217" target="https://www.rfc-editor.org/info/rfc4217" quoteTitle="true" derivedAnchor="RFC4217">
          <front>
            <title>Securing FTP with TLS</title>
            <author initials="P." surname="Ford-Hutchinson" fullname="P. Ford-Hutchinson">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="October"/>
            <abstract>
              <t indent="0">This document describes a mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined by RFC 2246, "The TLS Protocol Version 1.0.", and the extensions to the FTP protocol defined by RFC 2228, "FTP Security Extensions". It describes the subset of the extensions that are required and the parameters to be used, discusses some of the policy issues that clients and servers will need to take, considers some of the implications of those policies, and discusses some expected behaviours of implementations to allow interoperation.  This document is intended to provide TLS support for FTP in a similar way to that provided for SMTP in RFC 2487, "SMTP Service Extension for Secure SMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading to TLS Within HTTP/1.1.".</t>
              <t indent="0">This specification is in accordance with RFC 959, "File Transfer Protocol".  It relies on RFC 2246, "The TLS Protocol Version 1.0.", and RFC 2228, "FTP Security Extensions".  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4217"/>
          <seriesInfo name="DOI" value="10.17487/RFC4217"/>
        </reference>
        <reference anchor="RFC4235" target="https://www.rfc-editor.org/info/rfc4235" quoteTitle="true" derivedAnchor="RFC4235">
          <front>
            <title>An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)</title>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Mahy" fullname="R. Mahy" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="November"/>
            <abstract>
              <t indent="0">This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package.  The dialog package allows users to subscribe to another user and to receive notification of the changes in state of INVITE-initiated dialog usages in which the subscribed-to user is involved.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4235"/>
          <seriesInfo name="DOI" value="10.17487/RFC4235"/>
        </reference>
        <reference anchor="RFC4261" target="https://www.rfc-editor.org/info/rfc4261" quoteTitle="true" derivedAnchor="RFC4261">
          <front>
            <title>Common Open Policy Service (COPS) Over Transport Layer Security (TLS)</title>
            <author initials="J." surname="Walker" fullname="J. Walker">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Kulkarni" fullname="A. Kulkarni" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="December"/>
            <abstract>
              <t indent="0">This document describes how to use Transport Layer Security (TLS) to secure Common Open Policy Service (COPS) connections over the Internet.</t>
              <t indent="0">This document also updates RFC 2748 by modifying the contents of the Client-Accept message.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4261"/>
          <seriesInfo name="DOI" value="10.17487/RFC4261"/>
        </reference>
        <reference anchor="RFC4279" target="https://www.rfc-editor.org/info/rfc4279" quoteTitle="true" derivedAnchor="RFC4279">
          <front>
            <title>Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)</title>
            <author initials="P." surname="Eronen" fullname="P. Eronen" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Tschofenig" fullname="H. Tschofenig" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="December"/>
            <abstract>
              <t indent="0">This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs).  These pre-shared keys are symmetric keys, shared in advance among the communicating parties.  The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key, and the third set combines public key authentication of the server with pre-shared key authentication of the client.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4279"/>
          <seriesInfo name="DOI" value="10.17487/RFC4279"/>
        </reference>
        <reference anchor="RFC4346" target="https://www.rfc-editor.org/info/rfc4346" quoteTitle="true" derivedAnchor="RFC4346">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.1</title>
            <author initials="T." surname="Dierks" fullname="T. Dierks">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="April"/>
            <abstract>
              <t indent="0">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="RFC4497" target="https://www.rfc-editor.org/info/rfc4497" quoteTitle="true" derivedAnchor="RFC4497">
          <front>
            <title>Interworking between the Session Initiation Protocol (SIP) and QSIG</title>
            <author initials="J." surname="Elwell" fullname="J. Elwell">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="F." surname="Derks" fullname="F. Derks">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Mourot" fullname="P. Mourot">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="O." surname="Rousseau" fullname="O. Rousseau">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="May"/>
            <abstract>
              <t indent="0">This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks).  SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls.  QSIG is a signalling protocol for creating, modifying, and terminating circuit-switched calls (in particular, telephone calls) within Private Integrated Services Networks (PISNs).  QSIG is specified in a number of Ecma Standards and published also as ISO/IEC standards.  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="117"/>
          <seriesInfo name="RFC" value="4497"/>
          <seriesInfo name="DOI" value="10.17487/RFC4497"/>
        </reference>
        <reference anchor="RFC4513" target="https://www.rfc-editor.org/info/rfc4513" quoteTitle="true" derivedAnchor="RFC4513">
          <front>
            <title>Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms</title>
            <author initials="R." surname="Harrison" fullname="R. Harrison" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="June"/>
            <abstract>
              <t indent="0">This document describes authentication methods and security mechanisms of the Lightweight Directory Access Protocol (LDAP). This document details establishment of Transport Layer Security (TLS) using the StartTLS operation.</t>
              <t indent="0">This document details the simple Bind authentication method including anonymous, unauthenticated, and name/password mechanisms and the Simple Authentication and Security Layer (SASL) Bind authentication method including the EXTERNAL mechanism.</t>
              <t indent="0">This document discusses various authentication and authorization states through which a session to an LDAP server may pass and the actions that trigger these state changes.</t>
              <t indent="0">This document, together with other documents in the LDAP Technical Specification (see Section 1 of the specification's road map), obsoletes RFC 2251, RFC 2829, and RFC 2830.    [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4513"/>
          <seriesInfo name="DOI" value="10.17487/RFC4513"/>
        </reference>
        <reference anchor="RFC4531" target="https://www.rfc-editor.org/info/rfc4531" quoteTitle="true" derivedAnchor="RFC4531">
          <front>
            <title>Lightweight Directory Access Protocol (LDAP) Turn Operation</title>
            <author initials="K." surname="Zeilenga" fullname="K. Zeilenga">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="June"/>
            <abstract>
              <t indent="0">This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to reverse (or "turn") the roles of client and server for subsequent protocol exchanges in the session, or to enable each peer to act as both client and server with respect to the other.  This memo defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4531"/>
          <seriesInfo name="DOI" value="10.17487/RFC4531"/>
        </reference>
        <reference anchor="RFC4540" target="https://www.rfc-editor.org/info/rfc4540" quoteTitle="true" derivedAnchor="RFC4540">
          <front>
            <title>NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0</title>
            <author initials="M." surname="Stiemerling" fullname="M. Stiemerling">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Quittek" fullname="J. Quittek">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Cadar" fullname="C. Cadar">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="May"/>
            <abstract>
              <t indent="0">This document describes a protocol for controlling middleboxes such as firewalls and network address translators.  It is a fully compliant implementation of the Middlebox Communications (MIDCOM) semantics described in RFC 3989.  Compared to earlier experimental versions of the SIMCO protocol, this version (3.0) uses binary message encodings in order to reduce resource requirements.  This memo defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4540"/>
          <seriesInfo name="DOI" value="10.17487/RFC4540"/>
        </reference>
        <reference anchor="RFC4582" target="https://www.rfc-editor.org/info/rfc4582" quoteTitle="true" derivedAnchor="RFC4582">
          <front>
            <title>The Binary Floor Control Protocol (BFCP)</title>
            <author initials="G." surname="Camarillo" fullname="G. Camarillo">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Ott" fullname="J. Ott">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Drage" fullname="K. Drage">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="November"/>
            <abstract>
              <t indent="0">Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.</t>
              <t indent="0">This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4582"/>
          <seriesInfo name="DOI" value="10.17487/RFC4582"/>
        </reference>
        <reference anchor="RFC4616" target="https://www.rfc-editor.org/info/rfc4616" quoteTitle="true" derivedAnchor="RFC4616">
          <front>
            <title>The PLAIN Simple Authentication and Security Layer (SASL) Mechanism</title>
            <author initials="K." surname="Zeilenga" fullname="K. Zeilenga" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="August"/>
            <abstract>
              <t indent="0">This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism.  The PLAIN mechanism is intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols that lack a simple password authentication command.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4616"/>
          <seriesInfo name="DOI" value="10.17487/RFC4616"/>
        </reference>
        <reference anchor="RFC4642" target="https://www.rfc-editor.org/info/rfc4642" quoteTitle="true" derivedAnchor="RFC4642">
          <front>
            <title>Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)</title>
            <author initials="K." surname="Murchison" fullname="K. Murchison">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Vinocur" fullname="J. Vinocur">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Newman" fullname="C. Newman">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="October"/>
            <abstract>
              <t indent="0">This memo defines an extension to the Network News Transfer Protocol (NNTP) that allows an NNTP client and server to use Transport Layer Security (TLS).  The primary goal is to provide encryption for single-link confidentiality purposes, but data integrity, (optional) certificate-based peer entity authentication, and (optional) data compression are also possible.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4642"/>
          <seriesInfo name="DOI" value="10.17487/RFC4642"/>
        </reference>
        <reference anchor="RFC4680" target="https://www.rfc-editor.org/info/rfc4680" quoteTitle="true" derivedAnchor="RFC4680">
          <front>
            <title>TLS Handshake Message for Supplemental Data</title>
            <author initials="S." surname="Santesson" fullname="S. Santesson">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="October"/>
            <abstract>
              <t indent="0">This specification defines a TLS handshake message for exchange of supplemental application data.  TLS hello message extensions are used to determine which supplemental data types are supported by both the TLS client and the TLS server.  Then, the supplemental data handshake message is used to exchange the data.  Other documents will define the syntax of these extensions and the syntax of the associated supplemental data types.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4680"/>
          <seriesInfo name="DOI" value="10.17487/RFC4680"/>
        </reference>
        <reference anchor="RFC4681" target="https://www.rfc-editor.org/info/rfc4681" quoteTitle="true" derivedAnchor="RFC4681">
          <front>
            <title>TLS User Mapping Extension</title>
            <author initials="S." surname="Santesson" fullname="S. Santesson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Medvinsky" fullname="A. Medvinsky">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Ball" fullname="J. Ball">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="October"/>
            <abstract>
              <t indent="0">This document specifies a TLS extension that enables clients to send generic user mapping hints in a supplemental data handshake message defined in RFC 4680.  One such mapping hint is defined in an informative section, the UpnDomainHint, which may be used by a server to locate a user in a directory database.  Other mapping hints may be defined in other documents in the future.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4681"/>
          <seriesInfo name="DOI" value="10.17487/RFC4681"/>
        </reference>
        <reference anchor="RFC4712" target="https://www.rfc-editor.org/info/rfc4712" quoteTitle="true" derivedAnchor="RFC4712">
          <front>
            <title>Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)</title>
            <author initials="A." surname="Siddiqui" fullname="A. Siddiqui">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Romascanu" fullname="D. Romascanu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Golovinsky" fullname="E. Golovinsky">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Rahman" fullname="M. Rahman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Y." surname="Kim" fullname="Y. Kim">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="October"/>
            <abstract>
              <t indent="0">This memo specifies two transport mappings of the \%Real-Time Application Quality-of-Service Monitoring (RAQMON) information model defined in RFC 4710 using TCP as a native transport and the Simple Network Management Protocol (SNMP) to carry the RAQMON information from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC).  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4712"/>
          <seriesInfo name="DOI" value="10.17487/RFC4712"/>
        </reference>
        <reference anchor="RFC4732" target="https://www.rfc-editor.org/info/rfc4732" quoteTitle="true" derivedAnchor="RFC4732">
          <front>
            <title>Internet Denial-of-Service Considerations</title>
            <author initials="M." surname="Handley" fullname="M. Handley" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author>
              <organization showOnFrontPage="true">IAB</organization>
            </author>
            <date year="2006" month="December"/>
            <abstract>
              <t indent="0">This document provides an overview of possible avenues for denial-of-service (DoS) attack on Internet systems.  The aim is to encourage protocol designers and network engineers towards designs that are more robust.  We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4732"/>
          <seriesInfo name="DOI" value="10.17487/RFC4732"/>
        </reference>
        <reference anchor="RFC4743" target="https://www.rfc-editor.org/info/rfc4743" quoteTitle="true" derivedAnchor="RFC4743">
          <front>
            <title>Using NETCONF over the Simple Object Access Protocol (SOAP)</title>
            <author initials="T." surname="Goddard" fullname="T. Goddard">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="December"/>
            <abstract>
              <t indent="0">The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments.  Web Services is one such environment and is presently characterized by the use of the Simple Object Access Protocol (SOAP).  NETCONF finds many benefits in this environment: from the reuse of existing standards, to ease of software development, to integration with deployed systems.  Herein, we describe SOAP over HTTP and SOAP over Blocks Exchange Extensible Protocol (BEEP) bindings for NETCONF.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4743"/>
          <seriesInfo name="DOI" value="10.17487/RFC4743"/>
        </reference>
        <reference anchor="RFC4744" target="https://www.rfc-editor.org/info/rfc4744" quoteTitle="true" derivedAnchor="RFC4744">
          <front>
            <title>Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)</title>
            <author initials="E." surname="Lear" fullname="E. Lear">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Crozier" fullname="K. Crozier">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="December"/>
            <abstract>
              <t indent="0">This document specifies an application protocol mapping for the Network Configuration Protocol (NETCONF) over the Blocks Extensible Exchange Protocol (BEEP).  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4744"/>
          <seriesInfo name="DOI" value="10.17487/RFC4744"/>
        </reference>
        <reference anchor="RFC4785" target="https://www.rfc-editor.org/info/rfc4785" quoteTitle="true" derivedAnchor="RFC4785">
          <front>
            <title>Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)</title>
            <author initials="U." surname="Blumenthal" fullname="U. Blumenthal">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Goel" fullname="P. Goel">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="January"/>
            <abstract>
              <t indent="0">This document specifies authentication-only ciphersuites (with no encryption) for the Pre-Shared Key (PSK) based Transport Layer Security (TLS) protocol.  These ciphersuites are useful when authentication and integrity protection is desired, but confidentiality is not needed or not permitted.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4785"/>
          <seriesInfo name="DOI" value="10.17487/RFC4785"/>
        </reference>
        <reference anchor="RFC4791" target="https://www.rfc-editor.org/info/rfc4791" quoteTitle="true" derivedAnchor="RFC4791">
          <front>
            <title>Calendaring Extensions to WebDAV (CalDAV)</title>
            <author initials="C." surname="Daboo" fullname="C. Daboo">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Desruisseaux" fullname="B. Desruisseaux">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Dusseault" fullname="L. Dusseault">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="March"/>
            <abstract>
              <t indent="0">This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format.  This document defines the "calendar-access" feature of CalDAV.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4791"/>
          <seriesInfo name="DOI" value="10.17487/RFC4791"/>
        </reference>
        <reference anchor="RFC4823" target="https://www.rfc-editor.org/info/rfc4823" quoteTitle="true" derivedAnchor="RFC4823">
          <front>
            <title>FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet</title>
            <author initials="T." surname="Harding" fullname="T. Harding">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Scott" fullname="R. Scott">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="April"/>
            <abstract>
              <t indent="0">This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol (FTP) for XML, Binary, Electronic Data Interchange (EDI - +
[1] https://eprint.iacr.org/2018/299
[2] https://www.ietf.org/mail-archive/web/tls/current/msg26603.html
[3] https://www.ietf.org/mail-archive/web/tls/current/msg26603.html

  ]]></artwork>
</figure>

		</section>

		<section title="Operating Systems">

	<t><xref target="os-stats"/> ANSI X12 or UN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4823"/>
          <seriesInfo name="DOI" value="10.17487/RFC4823"/>
        </reference>
        <reference anchor="RFC4851" target="https://www.rfc-editor.org/info/rfc4851" quoteTitle="true" derivedAnchor="RFC4851">
          <front>
            <title>The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)</title>
            <author initials="N." surname="Cam-Winget" fullname="N. Cam-Winget">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="McGrew" fullname="D. McGrew">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Salowey" fullname="J. Salowey">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Zhou" fullname="H. Zhou">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="May"/>
            <abstract>
              <t indent="0">This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol.  EAP-FAST is an EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the peer and the EAP server.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4851"/>
          <seriesInfo name="DOI" value="10.17487/RFC4851"/>
        </reference>
        <reference anchor="RFC4964" target="https://www.rfc-editor.org/info/rfc4964" quoteTitle="true" derivedAnchor="RFC4964">
          <front>
            <title>The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular</title>
            <author initials="A." surname="Allen" fullname="A. Allen" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Holm" fullname="J. Holm">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Hallin" fullname="T. Hallin">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="September"/>
            <abstract>
              <t indent="0">This document describes a private Session Initiation Protocol (SIP) header (P-header) used by the Open Mobile Alliance (OMA) for Push to talk over Cellular (PoC) along with its applicability, which is limited to the OMA PoC application.  The P-Answer-State header is used for indicating the answering mode of the handset, which is particular to the PoC application.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4964"/>
          <seriesInfo name="DOI" value="10.17487/RFC4964"/>
        </reference>
        <reference anchor="RFC4975" target="https://www.rfc-editor.org/info/rfc4975" quoteTitle="true" derivedAnchor="RFC4975">
          <front>
            <title>The Message Session Relay Protocol (MSRP)</title>
            <author initials="B." surname="Campbell" fullname="B. Campbell" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Mahy" fullname="R. Mahy" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Jennings" fullname="C. Jennings" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="September"/>
            <abstract>
              <t indent="0">This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session.  Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4975"/>
          <seriesInfo name="DOI" value="10.17487/RFC4975"/>
        </reference>
        <reference anchor="RFC4976" target="https://www.rfc-editor.org/info/rfc4976" quoteTitle="true" derivedAnchor="RFC4976">
          <front>
            <title>Relay Extensions for the Message Sessions Relay Protocol (MSRP)</title>
            <author initials="C." surname="Jennings" fullname="C. Jennings">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Mahy" fullname="R. Mahy">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A. B." surname="Roach" fullname="A. B. Roach">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="September"/>
            <abstract>
              <t indent="0">Two separate models for conveying instant messages have been defined. Page-mode messages stand alone and are not part of a Session Initiation Protocol (SIP) session, whereas session-mode messages are set up as part of a session using SIP.  The Message Session Relay Protocol (MSRP) is a protocol for near real-time, peer-to-peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP.  This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4976"/>
          <seriesInfo name="DOI" value="10.17487/RFC4976"/>
        </reference>
        <reference anchor="RFC4992" target="https://www.rfc-editor.org/info/rfc4992" quoteTitle="true" derivedAnchor="RFC4992">
          <front>
            <title>XML Pipelining with Chunks for the Internet Registry Information Service</title>
            <author initials="A." surname="Newton" fullname="A. Newton">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="August"/>
            <abstract>
              <t indent="0">This document describes a simple TCP transfer protocol for the Internet Registry Information Service (IRIS).  Data is transferred between clients and servers using chunks to achieve pipelining.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4992"/>
          <seriesInfo name="DOI" value="10.17487/RFC4992"/>
        </reference>
        <reference anchor="RFC5018" target="https://www.rfc-editor.org/info/rfc5018" quoteTitle="true" derivedAnchor="RFC5018">
          <front>
            <title>Connection Establishment in the Binary Floor Control Protocol (BFCP)</title>
            <author initials="G." surname="Camarillo" fullname="G. Camarillo">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="September"/>
            <abstract>
              <t indent="0">This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange.  Client and server authentication are based on Transport Layer Security (TLS).  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5018"/>
          <seriesInfo name="DOI" value="10.17487/RFC5018"/>
        </reference>
        <reference anchor="RFC5019" target="https://www.rfc-editor.org/info/rfc5019" quoteTitle="true" derivedAnchor="RFC5019">
          <front>
            <title>The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments</title>
            <author initials="A." surname="Deacon" fullname="A. Deacon">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Hurst" fullname="R. Hurst">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="September"/>
            <abstract>
              <t indent="0">This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client-side processing.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5019"/>
          <seriesInfo name="DOI" value="10.17487/RFC5019"/>
        </reference>
        <reference anchor="RFC5023" target="https://www.rfc-editor.org/info/rfc5023" quoteTitle="true" derivedAnchor="RFC5023">
          <front>
            <title>The Atom Publishing Protocol</title>
            <author initials="J." surname="Gregorio" fullname="J. Gregorio" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="de hOra" fullname="B. de hOra" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="October"/>
            <abstract>
              <t indent="0">The Atom Publishing Protocol (AtomPub) is an application-level protocol for publishing and editing Web resources.  The protocol is based on HTTP transfer of Atom-formatted representations.  The Atom format is documented in the Atom Syndication Format.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5023"/>
          <seriesInfo name="DOI" value="10.17487/RFC5023"/>
        </reference>
        <reference anchor="RFC5024" target="https://www.rfc-editor.org/info/rfc5024" quoteTitle="true" derivedAnchor="RFC5024">
          <front>
            <title>ODETTE File Transfer Protocol 2.0</title>
            <author initials="I." surname="Friend" fullname="I. Friend">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="November"/>
            <abstract>
              <t indent="0">This memo updates the ODETTE File Transfer Protocol, an established file transfer protocol facilitating electronic data interchange of business data between trading partners, to version 2.</t>
              <t indent="0">The protocol now supports secure and authenticated communication over the Internet using Transport Layer Security, provides file encryption, signing, and compression using Cryptographic Message Syntax, and provides signed receipts for the acknowledgement of received files.</t>
              <t indent="0">The protocol supports both direct peer-to-peer communication and indirect communication via a Value Added Network and may be used with TCP/IP, X.25, and ISDN-based networks.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5024"/>
          <seriesInfo name="DOI" value="10.17487/RFC5024"/>
        </reference>
        <reference anchor="RFC5049" target="https://www.rfc-editor.org/info/rfc5049" quoteTitle="true" derivedAnchor="RFC5049">
          <front>
            <title>Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)</title>
            <author initials="C." surname="Bormann" fullname="C. Bormann">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Z." surname="Liu" fullname="Z. Liu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Price" fullname="R. Price">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Camarillo" fullname="G. Camarillo" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="December"/>
            <abstract>
              <t indent="0">This document describes some specifics that apply when Signaling Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp over TCP.  Any implementation of SigComp for use with SIP must conform to this document and SigComp, and in addition, support the SIP and Session Description Protocol (SDP) static dictionary.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5049"/>
          <seriesInfo name="DOI" value="10.17487/RFC5049"/>
        </reference>
        <reference anchor="RFC5054" target="https://www.rfc-editor.org/info/rfc5054" quoteTitle="true" derivedAnchor="RFC5054">
          <front>
            <title>Using the Secure Remote Password (SRP) Protocol for TLS Authentication</title>
            <author initials="D." surname="Taylor" fullname="D. Taylor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Wu" fullname="T. Wu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Mavrogiannopoulos" fullname="N. Mavrogiannopoulos">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Perrin" fullname="T. Perrin">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="November"/>
            <abstract>
              <t indent="0">This memo presents statistics a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5054"/>
          <seriesInfo name="DOI" value="10.17487/RFC5054"/>
        </reference>
        <reference anchor="RFC5091" target="https://www.rfc-editor.org/info/rfc5091" quoteTitle="true" derivedAnchor="RFC5091">
          <front>
            <title>Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems</title>
            <author initials="X." surname="Boyen" fullname="X. Boyen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Martin" fullname="L. Martin">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="December"/>
            <abstract>
              <t indent="0">This document describes the algorithms that implement Boneh-Franklin (BF) and Boneh-Boyen (BB1) Identity-based Encryption.  This document is in part based on IBCS #1 v2 of Voltage Security's Identity-based Cryptography Standards (IBCS) documents, from which some irrelevant sections have been removed to create the content of this document.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5091"/>
          <seriesInfo name="DOI" value="10.17487/RFC5091"/>
        </reference>
        <reference anchor="RFC5158" target="https://www.rfc-editor.org/info/rfc5158" quoteTitle="true" derivedAnchor="RFC5158">
          <front>
            <title>6to4 Reverse DNS Delegation Specification</title>
            <author initials="G." surname="Huston" fullname="G. Huston">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="March"/>
            <abstract>
              <t indent="0">This memo describes the service mechanism for entering a delegation of DNS servers that provide reverse lookup of 6to4 IPv6 addresses into the 6to4 reverse zone file.  The mechanism is based on a conventional DNS delegation service interface, allowing the service client to enter the details of a number of DNS servers for the delegated domain.  In the context of a 6to4 reverse delegation, the client is primarily authenticated by its source address used in the delegation request, and is authorized to use the function if its IPv6 address prefix corresponds to an address from within the requested 6to4 delegation address block.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5158"/>
          <seriesInfo name="DOI" value="10.17487/RFC5158"/>
        </reference>
        <reference anchor="RFC5216" target="https://www.rfc-editor.org/info/rfc5216" quoteTitle="true" derivedAnchor="RFC5216">
          <front>
            <title>The EAP-TLS Authentication Protocol</title>
            <author initials="D." surname="Simon" fullname="D. Simon">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Aboba" fullname="B. Aboba">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Hurst" fullname="R. Hurst">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="March"/>
            <abstract>
              <t indent="0">The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods.  Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints.  This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation.</t>
              <t indent="0">This document obsoletes RFC 2716.  A summary of the changes between this document and RFC 2716 is available in Appendix A.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5216"/>
          <seriesInfo name="DOI" value="10.17487/RFC5216"/>
        </reference>
        <reference anchor="RFC5238" target="https://www.rfc-editor.org/info/rfc5238" quoteTitle="true" derivedAnchor="RFC5238">
          <front>
            <title>Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)</title>
            <author initials="T." surname="Phelan" fullname="T. Phelan">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="May"/>
            <abstract>
              <t indent="0">This document specifies the use of Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP).  DTLS provides communications privacy for applications that use datagram transport protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery.  DCCP is a transport protocol that provides a congestion-controlled unreliable datagram service.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5238"/>
          <seriesInfo name="DOI" value="10.17487/RFC5238"/>
        </reference>
        <reference anchor="RFC5263" target="https://www.rfc-editor.org/info/rfc5263" quoteTitle="true" derivedAnchor="RFC5263">
          <front>
            <title>Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information</title>
            <author initials="M." surname="Lonnfors" fullname="M. Lonnfors">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Costa-Requena" fullname="J. Costa-Requena">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Leppanen" fullname="E. Leppanen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Khartabil" fullname="H. Khartabil">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="September"/>
            <abstract>
              <t indent="0">By default, presence delivered using the presence event package for the Session Initiation Protocol (SIP) is represented in the Presence Information Data Format (PIDF).  A PIDF document contains a set of elements, each representing a different aspect of the presence being reported.  When any subset of the elements change, even just a single element, a new document containing the full set of elements is delivered.  This memo defines an extension allowing delivery of only the presence data that has actually changed.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5263"/>
          <seriesInfo name="DOI" value="10.17487/RFC5263"/>
        </reference>
        <reference anchor="RFC5281" target="https://www.rfc-editor.org/info/rfc5281" quoteTitle="true" derivedAnchor="RFC5281">
          <front>
            <title>Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)</title>
            <author initials="P." surname="Funk" fullname="P. Funk">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Blake-Wilson" fullname="S. Blake-Wilson">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="August"/>
            <abstract>
              <t indent="0">EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase.  During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase.  During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel.  The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2.  Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks.  The data phase may also be used for additional, arbitrary data exchange.  This memo  provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5281"/>
          <seriesInfo name="DOI" value="10.17487/RFC5281"/>
        </reference>
        <reference anchor="RFC5364" target="https://www.rfc-editor.org/info/rfc5364" quoteTitle="true" derivedAnchor="RFC5364">
          <front>
            <title>Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists</title>
            <author initials="M." surname="Garcia-Martin" fullname="M. Garcia-Martin">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Camarillo" fullname="G. Camarillo">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="October"/>
            <abstract>
              <t indent="0">In certain types of multimedia communications, a Session Initiation Protocol (SIP) request is distributed to a group of SIP User Agents (UAs).  The sender sends a single SIP request to a server which further distributes the request to the group.  This SIP request contains a list of Uniform Resource Identifiers (URIs), which identify the recipients of the SIP request.  This URI list is expressed as a resource list XML document.  This specification defines an XML extension to the XML resource list format that allows the sender of the request to qualify a recipient with a copy control level similar to the copy control level of existing email systems.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5364"/>
          <seriesInfo name="DOI" value="10.17487/RFC5364"/>
        </reference>
        <reference anchor="RFC5422" target="https://www.rfc-editor.org/info/rfc5422" quoteTitle="true" derivedAnchor="RFC5422">
          <front>
            <title>Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)</title>
            <author initials="N." surname="Cam-Winget" fullname="N. Cam-Winget">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="McGrew" fullname="D. McGrew">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Salowey" fullname="J. Salowey">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Zhou" fullname="H. Zhou">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2009" month="March"/>
            <abstract>
              <t indent="0">The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel.  EAP- FAST also enables the provisioning credentials or other information through this protected tunnel.  This document describes the use of EAP-FAST for dynamic provisioning.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5422"/>
          <seriesInfo name="DOI" value="10.17487/RFC5422"/>
        </reference>
        <reference anchor="RFC5469" target="https://www.rfc-editor.org/info/rfc5469" quoteTitle="true" derivedAnchor="RFC5469">
          <front>
            <title>DES and IDEA Cipher Suites for Transport Layer Security (TLS)</title>
            <author initials="P." surname="Eronen" fullname="P. Eronen" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2009" month="February"/>
            <abstract>
              <t indent="0">Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346) include cipher suites based on DES (Data Encryption Standard) and IDEA (International Data Encryption Algorithm) algorithms.  DES (when used in single-DES mode) and IDEA are no longer recommended for general use in TLS, and have been removed from TLS version 1.2 (RFC 5246).  This document specifies these cipher suites for completeness and discusses reasons why their use is no longer recommended.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5469"/>
          <seriesInfo name="DOI" value="10.17487/RFC5469"/>
        </reference>
        <reference anchor="RFC5734" target="https://www.rfc-editor.org/info/rfc5734" quoteTitle="true" derivedAnchor="RFC5734">
          <front>
            <title>Extensible Provisioning Protocol (EPP) Transport over TCP</title>
            <author initials="S." surname="Hollenbeck" fullname="S. Hollenbeck">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2009" month="August"/>
            <abstract>
              <t indent="0">This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection.  This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server.  This document obsoletes RFC 4934.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="69"/>
          <seriesInfo name="RFC" value="5734"/>
          <seriesInfo name="DOI" value="10.17487/RFC5734"/>
        </reference>
        <reference anchor="RFC5878" target="https://www.rfc-editor.org/info/rfc5878" quoteTitle="true" derivedAnchor="RFC5878">
          <front>
            <title>Transport Layer Security (TLS) Authorization Extensions</title>
            <author initials="M." surname="Brown" fullname="M. Brown">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Housley" fullname="R. Housley">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="May"/>
            <abstract>
              <t indent="0">This document specifies authorization extensions to the Transport Layer Security (TLS) Handshake Protocol.  Extensions are carried in the client and server hello messages to confirm that both parties support the desired authorization data types.  Then, if supported by both the client and the server, authorization information, such as attribute certificates (ACs) or Security Assertion Markup Language (SAML)  assertions, is exchanged in the supplemental data handshake message. This document defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5878"/>
          <seriesInfo name="DOI" value="10.17487/RFC5878"/>
        </reference>
        <reference anchor="RFC5953" target="https://www.rfc-editor.org/info/rfc5953" quoteTitle="true" derivedAnchor="RFC5953">
          <front>
            <title>Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)</title>
            <author initials="W." surname="Hardaker" fullname="W. Hardaker">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="August"/>
            <abstract>
              <t indent="0">This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol.  The TLS and DTLS protocols provide authentication and privacy services for SNMP applications.  This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way.</t>
              <t indent="0">This Transport Model is designed to meet the security and operational needs of network administrators.  It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP.  The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred.  Both TLS and DTLS integrate well into existing public keying infrastructures.</t>
              <t indent="0">This document also defines a portion of the Management Information Base (MIB) for use with network management protocols.  In particular, it defines objects for managing the TLS Transport Model for SNMP.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5953"/>
          <seriesInfo name="DOI" value="10.17487/RFC5953"/>
        </reference>
        <reference anchor="RFC6042" target="https://www.rfc-editor.org/info/rfc6042" quoteTitle="true" derivedAnchor="RFC6042">
          <front>
            <title>Transport Layer Security (TLS) Authorization Using KeyNote</title>
            <author initials="A." surname="Keromytis" fullname="A. Keromytis">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="October"/>
            <abstract>
              <t indent="0">This document specifies the use of the KeyNote trust-management system as an authorization extension in the Transport Layer Security (TLS) Handshake Protocol, according to guidelines in RFC 5878.  Extensions carried in the client and server hello messages confirm that both parties support the desired authorization data types.  Then, if supported by both the client and the server, KeyNote credentials are exchanged in the supplemental data handshake message.  This document is not an  Internet Standards Track specification; it is published for  informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6042"/>
          <seriesInfo name="DOI" value="10.17487/RFC6042"/>
        </reference>
        <reference anchor="RFC6176" target="https://www.rfc-editor.org/info/rfc6176" quoteTitle="true" derivedAnchor="RFC6176">
          <front>
            <title>Prohibiting Secure Sockets Layer (SSL) Version 2.0</title>
            <author initials="S." surname="Turner" fullname="S. Turner">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Polk" fullname="T. Polk">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="March"/>
            <abstract>
              <t indent="0">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="RFC6353" target="https://www.rfc-editor.org/info/rfc6353" quoteTitle="true" derivedAnchor="RFC6353">
          <front>
            <title>Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)</title>
            <author initials="W." surname="Hardaker" fullname="W. Hardaker">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="July"/>
            <abstract>
              <t indent="0">This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol.  The TLS and DTLS protocols provide authentication and privacy services for SNMP applications.  This document describes how the TLS Transport Model (TLSTM) implements the needed features of an SNMP Transport Subsystem to make this protection possible in an interoperable way.</t>
              <t indent="0">This Transport Model is designed to meet the security and operational needs of network administrators.  It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP.  The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred.  Both TLS and DTLS integrate well into existing public keying infrastructures.</t>
              <t indent="0">This document also defines a portion of the Management Information Base (MIB) for use with network management protocols.  In particular, it defines objects for managing the TLS Transport Model for SNMP.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="78"/>
          <seriesInfo name="RFC" value="6353"/>
          <seriesInfo name="DOI" value="10.17487/RFC6353"/>
        </reference>
        <reference anchor="RFC6367" target="https://www.rfc-editor.org/info/rfc6367" quoteTitle="true" derivedAnchor="RFC6367">
          <front>
            <title>Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)</title>
            <author initials="S." surname="Kanno" fullname="S. Kanno">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Kanda" fullname="M. Kanda">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="September"/>
            <abstract>
              <t indent="0">This document specifies forty-two cipher suites for the Transport Security Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher.  This document is not an Internet  Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6367"/>
          <seriesInfo name="DOI" value="10.17487/RFC6367"/>
        </reference>
        <reference anchor="RFC6739" target="https://www.rfc-editor.org/info/rfc6739" quoteTitle="true" derivedAnchor="RFC6739">
          <front>
            <title>Synchronizing Service Boundaries and &lt;mapping&gt; Elements Based on the Location-to-Service Translation (LoST) Protocol</title>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2012" month="October"/>
            <abstract>
              <t indent="0">The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries.  In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services.</t>
              <t indent="0">The &lt;mapping&gt; element in the LoST protocol specification encapsulates information about service boundaries and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service.</t>
              <t indent="0">This document defines an XML protocol to exchange these mappings between two nodes.  This mechanism is designed for the exchange of authoritative &lt;mapping&gt; elements between two entities.  Exchanging cached &lt;mapping&gt; elements, i.e., non-authoritative elements, is possible but not envisioned.  Even though the &lt;mapping&gt; element format is reused from the LoST specification, the mechanism in this document can be used without the LoST protocol.  This document defines  an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6739"/>
          <seriesInfo name="DOI" value="10.17487/RFC6739"/>
        </reference>
        <reference anchor="RFC6749" target="https://www.rfc-editor.org/info/rfc6749" quoteTitle="true" derivedAnchor="RFC6749">
          <front>
            <title>The OAuth 2.0 Authorization Framework</title>
            <author initials="D." surname="Hardt" fullname="D. Hardt" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2012" month="October"/>
            <abstract>
              <t indent="0">The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.  This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6749"/>
          <seriesInfo name="DOI" value="10.17487/RFC6749"/>
        </reference>
        <reference anchor="RFC6750" target="https://www.rfc-editor.org/info/rfc6750" quoteTitle="true" derivedAnchor="RFC6750">
          <front>
            <title>The OAuth 2.0 Authorization Framework: Bearer Token Usage</title>
            <author initials="M." surname="Jones" fullname="M. Jones">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Hardt" fullname="D. Hardt">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2012" month="October"/>
            <abstract>
              <t indent="0">This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources.  Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key).  To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6750"/>
          <seriesInfo name="DOI" value="10.17487/RFC6750"/>
        </reference>
        <reference anchor="RFC7030" target="https://www.rfc-editor.org/info/rfc7030" quoteTitle="true" derivedAnchor="RFC7030">
          <front>
            <title>Enrollment over Secure Transport</title>
            <author initials="M." surname="Pritikin" fullname="M. Pritikin" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Yee" fullname="P. Yee" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Harkins" fullname="D. Harkins" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2013" month="October"/>
            <abstract>
              <t indent="0">This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport.  This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates.  It also supports client-generated public/private key pairs as well as key pairs generated by the CA.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7030"/>
          <seriesInfo name="DOI" value="10.17487/RFC7030"/>
        </reference>
        <reference anchor="RFC7465" target="https://www.rfc-editor.org/info/rfc7465" quoteTitle="true" derivedAnchor="RFC7465">
          <front>
            <title>Prohibiting RC4 Cipher Suites</title>
            <author initials="A." surname="Popov" fullname="A. Popov">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="February"/>
            <abstract>
              <t indent="0">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="RFC7507" target="https://www.rfc-editor.org/info/rfc7507" quoteTitle="true" derivedAnchor="RFC7507">
          <front>
            <title>TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks</title>
            <author initials="B." surname="Moeller" fullname="B. Moeller">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Langley" fullname="A. Langley">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="April"/>
            <abstract>
              <t indent="0">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="RFC7525" target="https://www.rfc-editor.org/info/rfc7525" quoteTitle="true" derivedAnchor="RFC7525">
          <front>
            <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
            <author initials="Y." surname="Sheffer" fullname="Y. Sheffer">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Holz" fullname="R. Holz">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="May"/>
            <abstract>
              <t indent="0">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="RFC7562" target="https://www.rfc-editor.org/info/rfc7562" quoteTitle="true" derivedAnchor="RFC7562">
          <front>
            <title>Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates</title>
            <author initials="D." surname="Thakore" fullname="D. Thakore">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="July"/>
            <abstract>
              <t indent="0">This document specifies the use of Digital Transmission Content Protection (DTCP) certificates as an authorization data type in the authorization extension for the Transport Layer Security (TLS) protocol.  This is in accordance with the guidelines for authorization extensions as specified in RFC 5878.  As with other TLS extensions, this authorization data can be included in the client and server hello messages to confirm that both parties support the desired authorization data types.  If supported by both the client and the server, DTCP certificates are exchanged in the supplemental data TLS handshake message as specified in RFC 4680.  This authorization data type extension is in support of devices containing DTCP certificates issued by the Digital Transmission Licensing Administrator (DTLA).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7562"/>
          <seriesInfo name="DOI" value="10.17487/RFC7562"/>
        </reference>
        <reference anchor="RFC7568" target="https://www.rfc-editor.org/info/rfc7568" quoteTitle="true" derivedAnchor="RFC7568">
          <front>
            <title>Deprecating Secure Sockets Layer Version 3.0</title>
            <author initials="R." surname="Barnes" fullname="R. Barnes">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Thomson" fullname="M. Thomson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Pironti" fullname="A. Pironti">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Langley" fullname="A. Langley">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="June"/>
            <abstract>
              <t indent="0">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 indent="0">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="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t indent="0">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="RFC8422" target="https://www.rfc-editor.org/info/rfc8422" quoteTitle="true" derivedAnchor="RFC8422">
          <front>
            <title>Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier</title>
            <author initials="Y." surname="Nir" fullname="Y. Nir">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Josefsson" fullname="S. Josefsson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Pegourie-Gonnard" fullname="M. Pegourie-Gonnard">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="August"/>
            <abstract>
              <t indent="0">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 TLS versions in operating systems.</t>

<figure anchor="os-stats" title="Operating System Statistics" >
<artwork><![CDATA[
+- - - - - - - - - - - - - - - - +- - - - - - - - - - +- - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +
| Name/Ref       | Date     | SSLv3|TLSv1.0|TLSv1.1|TLSv1.2|TLSv1.3|
+- - - - - - - - - - - - - - - - +- - - - - - - - - - +- - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +
| Windows cli [1]| 20180709 |    - | >10.0 |  ~0.3 |    -  |     - |
| Windows svr [1]| 20180709 |    - |  ~1.5 |  ~0.0 |    -  |     - |
| Apple [2]      | 20180709 |    - |   0.4 |     - |  99.6 |     - |
+- - - - - - - - - - - - - - - - +- - - - - - - - - - +- - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +- - - - - - the Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards-curve Digital Signature Algorithm (EdDSA) as authentication mechanisms.</t>
              <t indent="0">This document obsoletes RFC 4492.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8422"/>
          <seriesInfo name="DOI" value="10.17487/RFC8422"/>
        </reference>
      </references>
      <references pn="section-10.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="Bhargavan2016" target="https://www.mitls.org/downloads/transcript-collisions.pdf" quoteTitle="true" derivedAnchor="Bhargavan2016">
          <front>
            <title>Transcript Collision Attacks: Breaking Authentication in TLS, IKE, and SSH</title>
            <author fullname="Karthikeyan Bhargavan" initials="K." surname="Bhargavan">
              <organization showOnFrontPage="true">INRIA</organization>
            </author>
            <author fullname="Gaetan Leuren" initials="G." surname="Leuren">
              <organization showOnFrontPage="true">INRIA</organization>
            </author>
            <date month="February" year="2016"/>
          </front>
          <seriesInfo name="DOI" value="10.14722/ndss.2016.23418"/>
        </reference>
        <reference anchor="NIST800-52r2" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf" quoteTitle="true" derivedAnchor="NIST800-52r2">
          <front>
            <title>Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations NIST SP800-52r2</title>
            <author>
              <organization showOnFrontPage="true">National Institute of Standards and Technology</organization>
            </author>
            <date month="August" year="2019"/>
          </front>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-52r2"/>
        </reference>
        <reference anchor="RFC3316" target="https://www.rfc-editor.org/info/rfc3316" quoteTitle="true" derivedAnchor="RFC3316">
          <front>
            <title>Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts</title>
            <author initials="J." surname="Arkko" fullname="J. Arkko">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Kuijpers" fullname="G. Kuijpers">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Soliman" fullname="H. Soliman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Loughney" fullname="J. Loughney">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Wiljakka" fullname="J. Wiljakka">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="April"/>
          </front>
          <seriesInfo name="RFC" value="3316"/>
          <seriesInfo name="DOI" value="10.17487/RFC3316"/>
        </reference>
        <reference anchor="RFC3489" target="https://www.rfc-editor.org/info/rfc3489" quoteTitle="true" derivedAnchor="RFC3489">
          <front>
            <title>STUN - +
[1] https://www.ietf.org/mail-archive/web/tls/current/msg26577.html
[2] https://www.ietf.org/mail-archive/web/tls/current/msg26634.html
  ]]></artwork>
</figure>

		</section>

		<section title="Enterprise Networks">

	<t><xref target="intra-stats"/> presents statistics Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)</title>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Weinberger" fullname="J. Weinberger">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Huitema" fullname="C. Huitema">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Mahy" fullname="R. Mahy">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="March"/>
            <abstract>
              <t indent="0">Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet.  It also provides the ability for use applications to determine the public Internet Protocol (IP) addresses allocated to them by the NAT.  STUN works with many existing NATs, and does not require any special behavior from them.  As a result, it allows a wide variety of TLS versions in applications to work through existing NAT infrastructure.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3489"/>
          <seriesInfo name="DOI" value="10.17487/RFC3489"/>
        </reference>
        <reference anchor="RFC3546" target="https://www.rfc-editor.org/info/rfc3546" quoteTitle="true" derivedAnchor="RFC3546">
          <front>
            <title>Transport Layer Security (TLS) Extensions</title>
            <author initials="S." surname="Blake-Wilson" fullname="S. Blake-Wilson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Nystrom" fullname="M. Nystrom">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Hopwood" fullname="D. Hopwood">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Mikkelsen" fullname="J. Mikkelsen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Wright" fullname="T. Wright">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="June"/>
            <abstract>
              <t indent="0">This document describes extensions that may be used to add functionality to Transport Layer Security (TLS).  It provides both generic extension mechanisms for the enterprise networks. TLS handshake client and server hellos, and specific extensions using these generic mechanisms. The tcd.ie numbers below were the result of a student project extensions may be used by TLS clients and need further validation.</t>

<figure anchor="intra-stats" title="Enterprise Network Statistics" >
<artwork><![CDATA[
+- - - - - - - - - - - - - - - - +- - - - - - - - - - +- - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +
| Name/Ref       | Date     | SSLv3|TLSv1.0|TLSv1.1|TLSv1.2|TLSv1.3|
+- - - - - - - - - - - - - - - - +- - - - - - - - - - +- - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +
| tcd.ie [1]     | 20180713 | 18.0 |  35.0 |    0  |  45.0 |     0 |
+- - - - - - - - - - - - - - - - +- - - - - - - - - - +- - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +- - - - - - servers.  The extensions are backwards compatible - +
[1] https://www.ietf.org/mail-archive/web/tls/current/msg26633.html
  ]]></artwork>
</figure>

		</section>

    </section>
	-->

    <section title="SHA-1 Usage Problematic in TLSv1.0 communication is possible between TLS 1.0 clients that support the extensions and TLSv1.1">
      <t>The integrity of TLS 1.0 servers that do not support the extensions, and vice versa.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3546"/>
          <seriesInfo name="DOI" value="10.17487/RFC3546"/>
        </reference>
        <reference anchor="RFC3588" target="https://www.rfc-editor.org/info/rfc3588" quoteTitle="true" derivedAnchor="RFC3588">
          <front>
            <title>Diameter Base Protocol</title>
            <author initials="P." surname="Calhoun" fullname="P. Calhoun">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Loughney" fullname="J. Loughney">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Guttman" fullname="E. Guttman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Zorn" fullname="G. Zorn">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Arkko" fullname="J. Arkko">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="September"/>
            <abstract>
              <t indent="0">The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility.  Diameter is also intended to work in both TLSv1.0 local Authentication, Authorization &amp; Accounting and TLSv1.1 depends on roaming situations.  This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications.  The Diameter base application needs to be supported by all Diameter implementations.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3588"/>
          <seriesInfo name="DOI" value="10.17487/RFC3588"/>
        </reference>
        <reference anchor="RFC3734" target="https://www.rfc-editor.org/info/rfc3734" quoteTitle="true" derivedAnchor="RFC3734">
          <front>
            <title>Extensible Provisioning Protocol (EPP) Transport Over TCP</title>
            <author initials="S." surname="Hollenbeck" fullname="S. Hollenbeck">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="March"/>
            <abstract>
              <t indent="0">This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a running SHA-1
      hash single Transmission Control Protocol (TCP) connection.  This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged messages. This makes between an EPP client and an EPP server.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3734"/>
          <seriesInfo name="DOI" value="10.17487/RFC3734"/>
        </reference>
        <reference anchor="RFC3920" target="https://www.rfc-editor.org/info/rfc3920" quoteTitle="true" derivedAnchor="RFC3920">
          <front>
            <title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
            <author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="October"/>
            <abstract>
              <t indent="0">This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints.  While XMPP provides a generalized, extensible framework for exchanging XML data, it possible is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3920"/>
          <seriesInfo name="DOI" value="10.17487/RFC3920"/>
        </reference>
        <reference anchor="RFC4132" target="https://www.rfc-editor.org/info/rfc4132" quoteTitle="true" derivedAnchor="RFC4132">
          <front>
            <title>Addition of Camellia Cipher Suites to Transport Layer Security (TLS)</title>
            <author initials="S." surname="Moriai" fullname="S. Moriai">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Kato" fullname="A. Kato">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Kanda" fullname="M. Kanda">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="July"/>
            <abstract>
              <t indent="0">This document proposes the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the Camellia encryption algorithm as a bulk cipher algorithm.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4132"/>
          <seriesInfo name="DOI" value="10.17487/RFC4132"/>
        </reference>
        <reference anchor="RFC4244" target="https://www.rfc-editor.org/info/rfc4244" quoteTitle="true" derivedAnchor="RFC4244">
          <front>
            <title>An Extension to the Session Initiation Protocol (SIP) for Request History Information</title>
            <author initials="M." surname="Barnes" fullname="M. Barnes" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="November"/>
            <abstract>
              <t indent="0">This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request.  This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user.  This document defines a new optional SIP header, History-Info, for capturing the history information in requests.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4244"/>
          <seriesInfo name="DOI" value="10.17487/RFC4244"/>
        </reference>
        <reference anchor="RFC4347" target="https://www.rfc-editor.org/info/rfc4347" quoteTitle="true" derivedAnchor="RFC4347">
          <front>
            <title>Datagram Transport Layer Security</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Modadugu" fullname="N. Modadugu">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="April"/>
            <abstract>
              <t indent="0">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 perform communicate in a
      downgrade attack on the handshake by an attacker able way that is designed to perform 2^77
      operations, well below prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the acceptable modern Transport Layer Security (TLS) protocol and provides equivalent security margin.</t>

      <t>Similarly, the authentication guarantees.  Datagram semantics of the handshake depends on signatures
      made using a SHA-1 hash or a not appreciably stronger concatenation of MD-5 and SHA-1
      hashes, allowing underlying transport are preserved by the attacker DTLS protocol.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4347"/>
          <seriesInfo name="DOI" value="10.17487/RFC4347"/>
        </reference>
        <reference anchor="RFC4366" target="https://www.rfc-editor.org/info/rfc4366" quoteTitle="true" derivedAnchor="RFC4366">
          <front>
            <title>Transport Layer Security (TLS) Extensions</title>
            <author initials="S." surname="Blake-Wilson" fullname="S. Blake-Wilson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Nystrom" fullname="M. Nystrom">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Hopwood" fullname="D. Hopwood">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Mikkelsen" fullname="J. Mikkelsen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Wright" fullname="T. Wright">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="April"/>
            <abstract>
              <t indent="0">This document describes extensions that may be used to impersonate a add functionality to Transport Layer Security (TLS).  It provides both generic extension mechanisms for the TLS handshake client and server when it hellos, and specific extensions using these generic mechanisms.</t>
              <t indent="0">The extensions may be used by TLS clients and servers.  The extensions are backwards compatible: communication is able to
      break possible between TLS clients that support the severely weakened SHA-1 hash.</t>

      <t>Neither TLSv1.0 nor TLSv1.1 allow extensions and TLS servers that do not support the peers to select a stronger hash extensions, and vice versa.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4366"/>
          <seriesInfo name="DOI" value="10.17487/RFC4366"/>
        </reference>
        <reference anchor="RFC4492" target="https://www.rfc-editor.org/info/rfc4492" quoteTitle="true" derivedAnchor="RFC4492">
          <front>
            <title>Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)</title>
            <author initials="S." surname="Blake-Wilson" fullname="S. Blake-Wilson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Bolyard" fullname="N. Bolyard">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Gupta" fullname="V. Gupta">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Hawk" fullname="C. Hawk">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Moeller" fullname="B. Moeller">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="May"/>
            <abstract>
              <t indent="0">This document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for signatures in the ServerKeyExchange or CertificateVerify messages,
      making Transport Layer Security (TLS) protocol.  In particular, it specifies the only upgrade path use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a newer protocol version.</t>

      <t>See <xref target="Bhargavan2016"/> new authentication mechanism.  This memo provides information for additional detail.</t>
    </section>

    <section title="Do Not Use TLSv1.0">
      <t>TLSv1.0 MUST NOT be used. <!-- I didn't get the reason for this here: <xref target="RFC8174"/>.  -->
      Negotiation of TLSv1.0 from any version of TLS MUST NOT be
      permitted.</t>

      <t>Any other version of TLS is more secure than TLSv1.0. While TLSv1.0 can be
      configured Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4492"/>
          <seriesInfo name="DOI" value="10.17487/RFC4492"/>
        </reference>
        <reference anchor="RFC4507" target="https://www.rfc-editor.org/info/rfc4507" quoteTitle="true" derivedAnchor="RFC4507">
          <front>
            <title>Transport Layer Security (TLS) Session Resumption without Server-Side State</title>
            <author initials="J." surname="Salowey" fullname="J. Salowey">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Zhou" fullname="H. Zhou">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Eronen" fullname="P. Eronen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="May"/>
            <abstract>
              <t indent="0">This document describes a mechanism that enables the Transport Layer Security (TLS) server to prevent some types of interception, using resume sessions and avoid keeping \%per-client session state.  The TLS server encapsulates the highest version
      available is preferred.</t>

      <t>Pragmatically, clients MUST NOT send session state into a ClientHello with
      ClientHello.client_version set ticket and forwards it to {03,01}. Similarly, servers MUST NOT
      send the client.  The client can subsequently resume a ServerHello with ServerHello.server_version set session using the obtained ticket.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4507"/>
          <seriesInfo name="DOI" value="10.17487/RFC4507"/>
        </reference>
        <reference anchor="RFC4572" target="https://www.rfc-editor.org/info/rfc4572" quoteTitle="true" derivedAnchor="RFC4572">
          <front>
            <title>Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)</title>
            <author initials="J." surname="Lennox" fullname="J. Lennox">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="July"/>
            <abstract>
              <t indent="0">This document specifies how to {03,01}. Any
      party receiving a Hello message with establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol version set to {03,01}
      MUST respond with using the Session Description Protocol (SDP).  It defines a "protocol_version" alert message and close new SDP protocol identifier, 'TCP/TLS'.  It also defines the
      connection.</t>

      <t>Historically, TLS specifications were not clear on what syntax and semantics for an SDP 'fingerprint' attribute that identifies the record
      layer version number (TLSPlaintext.version) could contain when sending
      ClientHello. Appendix E of [RFC5246] notes certificate that TLSPlaintext.version
      could will be selected to maximize interoperability, though no definitive
      value is identified as ideal. That guidance is still applicable;
      therefore, presented for the TLS servers MUST accept any value {03,XX} (including {03,00}) session.  This mechanism allows media transport over TLS connections to be established securely, so long as the record layer version number for ClientHello, but they MUST NOT
      negotiate TLSv1.0.</t>

      <!--
	  <t>[[Text here is derived (or stolen:-) from <xref target="RFC7568"/>]]</t>
		-->
    </section>

    <section title="Do Not Use TLSv1.1">
      <t>TLSv1.1 MUST NOT be used. Negotiation of TLSv1.1 from any version integrity of
      TLS MUST NOT be permitted.</t>

      <t>Pragmatically, clients MUST NOT send a ClientHello with
      ClientHello.client_version set to {03,02}. Similarly, servers MUST NOT
      send session descriptions is assured.</t>
              <t indent="0">This document extends and updates RFC 4145.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4572"/>
          <seriesInfo name="DOI" value="10.17487/RFC4572"/>
        </reference>
        <reference anchor="RFC4934" target="https://www.rfc-editor.org/info/rfc4934" quoteTitle="true" derivedAnchor="RFC4934">
          <front>
            <title>Extensible Provisioning Protocol (EPP) Transport Over TCP</title>
            <author initials="S." surname="Hollenbeck" fullname="S. Hollenbeck">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="May"/>
            <abstract>
              <t indent="0">This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a ServerHello with ServerHello.server_version set single Transmission Control Protocol (TCP) connection.  This mapping requires use of the Transport Layer Security (TLS) protocol to {03,02}. Any
      party receiving protect information exchanged between an EPP client and an EPP server.  This document obsoletes RFC 3734.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4934"/>
          <seriesInfo name="DOI" value="10.17487/RFC4934"/>
        </reference>
        <reference anchor="RFC5077" target="https://www.rfc-editor.org/info/rfc5077" quoteTitle="true" derivedAnchor="RFC5077">
          <front>
            <title>Transport Layer Security (TLS) Session Resumption without Server-Side State</title>
            <author initials="J." surname="Salowey" fullname="J. Salowey">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Zhou" fullname="H. Zhou">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Eronen" fullname="P. Eronen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="January"/>
            <abstract>
              <t indent="0">This document describes a Hello message with mechanism that enables the protocol version set Transport Layer Security (TLS) server to {03,02}
      MUST respond with resume sessions and avoid keeping per-client session state.  The TLS server encapsulates the session state into a "protocol_version" alert message ticket and close forwards it to the
      connection.</t>

      <t>Any newer version of TLS is more secure than TLSv1.1. While TLSv1.1 client.  The client can be
      configured to prevent some types of interception, subsequently resume a session using the highest version
      available is preferred. Support for TLSv1.1 is dwindling in libraries
      and will impact security going forward if mitigations 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="RFC5081" target="https://www.rfc-editor.org/info/rfc5081" quoteTitle="true" derivedAnchor="RFC5081">
          <front>
            <title>Using OpenPGP Keys for attacks cannot
      be easily addressed and supported in older libraries.</t>

      <t>Historically, TLS specifications were not clear on what the record
      layer version number (TLSPlaintext.version) could contain when sending
      ClientHello. Appendix E of [RFC5246] notes that TLSPlaintext.version
      could be selected Transport Layer Security (TLS) Authentication</title>
            <author initials="N." surname="Mavrogiannopoulos" fullname="N. Mavrogiannopoulos">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="November"/>
            <abstract>
              <t indent="0">This memo proposes extensions to maximize interoperability, though no definitive
      value is identified as ideal. That guidance is still applicable;
      therefore, TLS servers MUST accept any value {03,XX} (including {03,00})
      as the record layer version number for ClientHello, but they MUST NOT
      negotiate TLSv1.1.</t>
    </section>

    <!--

    <section title="Do Not Use SHA-1 in TLSv1.2">
		<t>[[This section was suggested in PR#2 for Transport Layer Security (TLS) protocol to support the pre-WG draft repo by Hubert Kario. We're not
				clear if OpenPGP key format.  The extensions discussed here include a certificate type negotiation mechanism, and the WG would like this draft required modifications to include this or not,
				so will ask the TLS WG at the appropriate time.]]</t>

        <t>SHA-1 as a signature hash MUST NOT be used. That means that
            clients MUST send signature_algorithms extension and that extension
            MUST NOT include pairs that include SHA-1 hash. In particular,
            values {2, 1}, {2, 2} and {2, 3} MUST NOT be present in Handshake Protocol.  This memo defines an Experimental Protocol for the
            extension.</t>
        <t>Note: this does not affect cipher suites that use SHA-1 HMAC Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5081"/>
          <seriesInfo name="DOI" value="10.17487/RFC5081"/>
        </reference>
        <reference anchor="RFC5101" target="https://www.rfc-editor.org/info/rfc5101" quoteTitle="true" derivedAnchor="RFC5101">
          <front>
            <title>Specification of the IP Flow Information Export (IPFIX) Protocol for
            data integrity as the HMAC construction is still considered secure
            and when they are used in TLSv1.2 SHA-256 is used Exchange of IP Traffic Flow Information</title>
            <author initials="B." surname="Claise" fullname="B. Claise" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="January"/>
            <abstract>
              <t indent="0">This document specifies the IP Flow Information Export (IPFIX) protocol that serves for handshake
            integrity.</t>
    </section>
	-->

    <section title="Updates transmitting IP Traffic Flow information over the network.  In order to RFC 7525">
      <!--
      <t>[[Since RFC7525 is BCP 195, there'll probably be some process-fun transmit IP Traffic Flow information from an Exporting Process to
      do an update of that. Formally, it may be that this document becomes information Collecting Process, a
      new part common representation of BCP 195 I guess, but we can figure that out with chairs flow data and
      ADs.]]</t>
		-->

      <t>RFC7525 a standard means of communicating them is BCP 195, "Recommendations for Secure Use required.  This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5101"/>
          <seriesInfo name="DOI" value="10.17487/RFC5101"/>
        </reference>
        <reference anchor="RFC5246" target="https://www.rfc-editor.org/info/rfc5246" quoteTitle="true" derivedAnchor="RFC5246">
          <front>
            <title>The Transport Layer Security (TLS) and Datagram Protocol Version 1.2</title>
            <author initials="T." surname="Dierks" fullname="T. Dierks">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="August"/>
            <abstract>
              <t indent="0">This document specifies Version 1.2 of the Transport Layer Security (DTLS)", which is the
      most recent best practice document for implementing (TLS) protocol.  The TLS and was based on
      TLSv1.2. At the time of publication, TLSv1.0 and TLSv1.1 had not yet
      been deprecated. As such, BCP 195 is called out specifically to
      update text implementing protocol provides communications security over the deprecation recommendations of this
      document.</t>

      <t>This document updates <xref target="RFC7525"/> Section 3.1.1
      changing SHOULD NOT Internet.  The protocol allows client/server applications to MUST NOT as follows:</t>

      <t><list style="symbols">
          <t>Implementations MUST NOT negotiate TLS version 1.0 <xref
          target="RFC2246"/>. <vspace blankLines="1"/> Rationale: TLSv1.0
          (published communicate in 1999) does not support many modern, strong cipher
          suites. In addition, TLSv1.0 lacks a per- record Initialization
          Vector (IV) for CBC-based cipher suites and does not warn against
          common padding errors. <vspace blankLines="1"/></t>

          <t>Implementations MUST NOT negotiate TLS version 1.1 <xref
          target="RFC4346"/>. <vspace blankLines="1"/> Rationale: TLSv1.1
          (published 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="RFC5415" target="https://www.rfc-editor.org/info/rfc5415" quoteTitle="true" derivedAnchor="RFC5415">
          <front>
            <title>Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification</title>
            <author initials="P." surname="Calhoun" fullname="P. Calhoun" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Montemurro" fullname="M. Montemurro" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Stanley" fullname="D. Stanley" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2009" month="March"/>
            <abstract>
              <t indent="0">This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP Working Group in 2006) RFC 4564.  The CAPWAP protocol is a security improvement over TLSv1.0 but still
          does not support certain stronger cipher suites.</t>
        </list></t>

      <t>This documents updates <xref target="RFC7525"/> Section 3.1.2
      changing SHOULD NOT designed to MUST NOT as follows:</t>

      <t><list style="symbols">
          <t>Implementations MUST NOT negotiate DTLS version 1.0 <xref
          target="RFC4347"/>, <xref target="RFC6347"/>. <vspace
          blankLines="1"/> Version 1.0 of DTLS correlates be flexible, allowing it to version 1.1 be used for a variety of
          TLS (see above).</t>
        </list></t>
    </section>

    <section title="Operational Considerations">

        <t> wireless technologies.  This document is part of BCP 195, and as such reflects the
            understanding of describes the IETF (at the time of base CAPWAP protocol, while separate binding extensions will enable its publication) as to use with additional wireless technologies.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5415"/>
          <seriesInfo name="DOI" value="10.17487/RFC5415"/>
        </reference>
        <reference anchor="RFC5456" target="https://www.rfc-editor.org/info/rfc5456" quoteTitle="true" derivedAnchor="RFC5456">
          <front>
            <title>IAX: Inter-Asterisk eXchange Version 2</title>
            <author initials="M." surname="Spencer" fullname="M. Spencer">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Capouch" fullname="B. Capouch">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Guy" fullname="E. Guy" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="F." surname="Miller" fullname="F. Miller">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Shumard" fullname="K. Shumard">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="February"/>
            <abstract>
              <t indent="0">This document describes IAX, the
            best practices Inter-Asterisk eXchange protocol, an application-layer control and media protocol for TLS creating, modifying, and DTLS usage.
        </t>

        <t>
            Though TLSv1.1 has been obsolete since terminating multimedia sessions over Internet Protocol (IP) networks.  IAX was developed by the publication of RFC 5246
            in 2008, and DTLSv1.0 has been obsolete since open source community for the publication Asterisk Private Branch Exchange (PBX) and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of RFC
            6347 multimedia.</t>
              <t indent="0">IAX is an "all in 2012, there may remain some systems one" protocol for handling multimedia in IP networks.  It combines both control and media services in operation that do not
            support (D)TLSv1.2 or higher. Adopting the practices recommended by
            this document for any systems that same protocol.  In addition, IAX uses a single UDP data stream on a static port greatly simplifying Network Address Translation (NAT) gateway traversal, eliminating the need for other protocols to communicate with the
            aforementioned class of systems will cause failure work around NAT, and simplifying network and firewall management.  IAX employs a compact encoding that decreases bandwidth usage and is well suited for Internet telephony service.  In addition, its open nature permits new payload type additions needed to interoperate.
            However, disregarding the recommendations of this support additional services.   This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5456"/>
          <seriesInfo name="DOI" value="10.17487/RFC5456"/>
        </reference>
        <reference anchor="RFC6012" target="https://www.rfc-editor.org/info/rfc6012" quoteTitle="true" derivedAnchor="RFC6012">
          <front>
            <title>Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog</title>
            <author initials="J." surname="Salowey" fullname="J. Salowey">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Petch" fullname="T. Petch">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Gerhards" fullname="R. Gerhards">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Feng" fullname="H. Feng">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="October"/>
            <abstract>
              <t indent="0">This document in order
            to continue to interoperate with describes the aforementioned class of systems
            incurs some amount of risk. The nature transport of syslog messages over the risks incurred by
            operating Datagram Transport Layer Security (DTLS) protocol.  It provides a secure transport for syslog messages in contravention to cases where a connectionless transport is desired.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6012"/>
          <seriesInfo name="DOI" value="10.17487/RFC6012"/>
        </reference>
        <reference anchor="RFC6083" target="https://www.rfc-editor.org/info/rfc6083" quoteTitle="true" derivedAnchor="RFC6083">
          <front>
            <title>Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)</title>
            <author initials="M." surname="Tuexen" fullname="M. Tuexen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Seggelmann" fullname="R. Seggelmann">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="January"/>
            <abstract>
              <t indent="0">This document describes the recommendations usage of this document
            are discussed the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP).</t>
              <t indent="0">DTLS over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in Sections 2 a way that is designed to prevent eavesdropping and 3, detect tampering or message forgery.</t>
              <t indent="0">Applications using DTLS over SCTP can use almost all transport features provided by SCTP and knowledge of those risks
            should be used along with any potential mitigating factors its extensions.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6083"/>
          <seriesInfo name="DOI" value="10.17487/RFC6083"/>
        </reference>
        <reference anchor="RFC6084" target="https://www.rfc-editor.org/info/rfc6084" quoteTitle="true" derivedAnchor="RFC6084">
          <front>
            <title>General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS)</title>
            <author initials="X." surname="Fu" fullname="X. Fu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Dickmann" fullname="C. Dickmann">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Crowcroft" fullname="J. Crowcroft">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="January"/>
            <abstract>
              <t indent="0">The General Internet Signaling Transport (GIST) protocol currently uses TCP or Transport Layer Security (TLS) over TCP for Connection mode operation.  This document describes the
            risks inherent to updating usage of GIST over the systems in question when deciding how
            quickly to adopt Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS).  This document defines an Experimental Protocol for the recommendations specified in this document.
        </t>

    </section>

    <section title="Security Considerations">
      <t>This Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6084"/>
          <seriesInfo name="DOI" value="10.17487/RFC6084"/>
        </reference>
        <reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6347" quoteTitle="true" derivedAnchor="RFC6347">
          <front>
            <title>Datagram Transport Layer Security Version 1.2</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Modadugu" fullname="N. Modadugu">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2012" month="January"/>
            <abstract>
              <t indent="0">This document deprecates two older TLS protocol versions and one older specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol version provides communications privacy for security
      reasons already described. datagram protocols.  The attack surface is reduced when there are
      a smaller number of supported protocols and fallback options are
      removed.</t>
    </section>

    <section title="Acknowledgements">
      <t>Thanks protocol allows client/server applications to those communicate in a way that provided usage data, reviewed and/or improved
          this document, including: Michael Ackermann, David Benjamin, David Black,
        Deborah Brungard, Alan DeKok, Viktor Dukhovni, Julien Elie,
        Adrian Farrelll, Gary Gapinski, Alessandro Ghedini, Peter
        Gutmann, Jeremy Harris, Nick Hilliard, James
          Hodgkinson, Russ Housley, Hubert Kario, Benjamin Kaduk, John Klensin,
          Watson Ladd, Eliot Lear, Ted Lemon, John Mattsson, Keith Moore, Tom
        Petch, Eric Mill, Yoav Nir, Andrei Popov, Michael Richardson, Eric
        Rescorla, Rich Salz, Mohit Sethi, Yaron Sheffer, Rob Sayre,
        Robert Sparks, Barbara Stark, Martin Thomson, Sean Turner,
        Loganaden Velvindron, and Jakub Wilk.
    </t>

      <t>[[Note is designed to RFC editor: At least Julien Elie's name above should have
      an accent prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the first letter Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the surname. Please fix that and any
      others needing a similar fix if you can, I'm not sure underlying transport are preserved by the tooling I have
      now allows that.]]</t>
    </section>

    <section title="IANA Considerations">
      <t>[[This memo includes no request DTLS protocol.  This document updates DTLS 1.0 to IANA.]]</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.8174'?>

      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.2246'?>

      <?rfc include='reference.RFC.4346'?>

      <?rfc include='reference.RFC.7525'?>

      <!-- these are from nonobsnorms.sh.refs -->

      <?rfc include='reference.RFC.8422'?>

      <?rfc include='reference.RFC.7568'?>

      <?rfc include='reference.RFC.7562'?>

      <?rfc include='reference.RFC.7507'?>

      <?rfc include='reference.RFC.7465'?>

      <?rfc include='reference.RFC.7030'?>

      <?rfc include='reference.RFC.6750'?>

      <?rfc include='reference.RFC.6749'?>

      <?rfc include='reference.RFC.6739'?>

      <?rfc include='reference.RFC.6353'?>

      <?rfc include='reference.RFC.6367'?>

      <?rfc include='reference.RFC.6176'?>

      <?rfc include='reference.RFC.6042'?>

      <?rfc include='reference.RFC.5953'?>

      <?rfc include='reference.RFC.5878'?>

      <?rfc include='reference.RFC.5734'?>

      <?rfc include='reference.RFC.5469'?>

      <?rfc include='reference.RFC.5422'?>

      <?rfc include='reference.RFC.5364'?>

      <?rfc include='reference.RFC.5281'?>

      <?rfc include='reference.RFC.5263'?>

      <?rfc include='reference.RFC.5238'?>

      <?rfc include='reference.RFC.5216'?>

      <?rfc include='reference.RFC.5158'?>

      <?rfc include='reference.RFC.5091'?>

      <?rfc include='reference.RFC.5054'?>

      <?rfc include='reference.RFC.5049'?>

      <?rfc include='reference.RFC.5024'?>

      <?rfc include='reference.RFC.5023'?>

      <?rfc include='reference.RFC.5019'?>

      <?rfc include='reference.RFC.5018'?>

      <?rfc include='reference.RFC.4992'?>

      <?rfc include='reference.RFC.4976'?>

      <?rfc include='reference.RFC.4975'?>

      <?rfc include='reference.RFC.4964'?>

      <?rfc include='reference.RFC.4851'?>

      <?rfc include='reference.RFC.4823'?>

      <?rfc include='reference.RFC.4791'?>

      <?rfc include='reference.RFC.4785'?>

      <?rfc include='reference.RFC.4744'?>

      <?rfc include='reference.RFC.4743'?>

      <?rfc include='reference.RFC.4732'?>

      <?rfc include='reference.RFC.4712'?>

      <?rfc include='reference.RFC.4681'?>

      <?rfc include='reference.RFC.4680'?>

      <?rfc include='reference.RFC.4642'?>

      <?rfc include='reference.RFC.4616'?>

      <?rfc include='reference.RFC.4582'?>

      <?rfc include='reference.RFC.4540'?>

      <?rfc include='reference.RFC.4531'?>

      <?rfc include='reference.RFC.4513'?>

      <?rfc include='reference.RFC.4497'?>

      <?rfc include='reference.RFC.4279'?>

      <?rfc include='reference.RFC.4261'?>

      <?rfc include='reference.RFC.4235'?>

      <?rfc include='reference.RFC.4217'?>

      <?rfc include='reference.RFC.4168'?>

      <?rfc include='reference.RFC.4162'?>

      <?rfc include='reference.RFC.4111'?>

      <?rfc include='reference.RFC.4097'?>

      <?rfc include='reference.RFC.3983'?>

      <?rfc include='reference.RFC.3943'?>

      <?rfc include='reference.RFC.3903'?>

      <?rfc include='reference.RFC.3887'?>

      <?rfc include='reference.RFC.3871'?>

      <?rfc include='reference.RFC.3856'?>

      <?rfc include='reference.RFC.3767'?>

      <?rfc include='reference.RFC.3749'?>

      <?rfc include='reference.RFC.3656'?>

      <?rfc include='reference.RFC.3568'?>

      <?rfc include='reference.RFC.3552'?>

      <?rfc include='reference.RFC.3501'?>

      <?rfc include='reference.RFC.3470'?>

      <?rfc include='reference.RFC.3436'?>

      <?rfc include='reference.RFC.3329'?>

      <?rfc include='reference.RFC.3261'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.7457'?>

      <!--
      <reference anchor="Alexa">
        <front>
          <title>The Alexa Top 1 Million Analysis
          https://scotthelme.co.uk/alexa-top-1-million-analysis-february-2018/</title>

          <author>
            <organization>Will be deleted before publication</organization>
          </author>

          <date year="2018"/> 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="StackExchange"> anchor="RFC6460" target="https://www.rfc-editor.org/info/rfc6460" quoteTitle="true" derivedAnchor="RFC6460">
          <front>
          <title>Stackexchange
          https://security.stackexchange.com/questions/177182/is-there-a-list-of-old-browsers-that-only-support-tls-1-0</title>

          <author>
            <organization>StackExchange - will be deleted before
            publication</organization>
            <title>Suite B Profile for Transport Layer Security (TLS)</title>
            <author initials="M." surname="Salter" fullname="M. Salter">
              <organization showOnFrontPage="true"/>
            </author>

          <date year="2018"/>
        </front>
      </reference>
		-->

      <!--
      <reference anchor="Windows">
        <front>
          <title>Windows
          <author>
            <organization>Andrei Popov</organization>
            <author initials="R." surname="Housley" fullname="R. Housley">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018"/> year="2012" month="January"/>
            <abstract>
              <t indent="0">The United States government has published guidelines for "NSA Suite B Cryptography" that define cryptographic algorithm policy for national security applications.  This document defines a profile of Transport Layer Security (TLS) version 1.2 that is fully compliant with Suite B.  This document is not an Internet Standards Track  specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6460"/>
          <seriesInfo name="DOI" value="10.17487/RFC6460"/>
        </reference>
        <reference anchor="FF"> anchor="RFC6614" target="https://www.rfc-editor.org/info/rfc6614" quoteTitle="true" derivedAnchor="RFC6614">
          <front>
          <title>Firefox
          https://www.ietf.org/mail-archive/web/tls/current/msg26575.html</title>
          <author>
            <organization>Eric Rescorla</organization>
            <title>Transport Layer Security (TLS) Encryption for RADIUS</title>
            <author initials="S." surname="Winter" fullname="S. Winter">
              <organization showOnFrontPage="true"/>
            </author>
          <date year="2018"/>
        </front>
      </reference>
		-->

      <!--
      <reference anchor="SSLpulse">
        <front>
          <title>SSLpulse
          https://www.ssllabs.com/ssl-pulse/</title>
          <author>
            <organization>SSLpulse - will be deleted before
            publication</organization>
            <author initials="M." surname="McCauley" fullname="M. McCauley">
              <organization showOnFrontPage="true"/>
            </author>
          <date year="2018"/>
        </front>
      </reference>
		-->

      <reference anchor="NIST800-52r2">
        <front>
          <title>NIST SP800-52r2
          https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf</title>

          <author>
            <organization>National Institute of Standards and
            Technology</organization>
            <author initials="S." surname="Venaas" fullname="S. Venaas">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Wierenga" fullname="K. Wierenga">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="August" year="2019"/> year="2012" month="May"/>
            <abstract>
              <t indent="0">This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP as the transport protocol. This enables dynamic trust relationships between RADIUS servers.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6614"/>
          <seriesInfo name="DOI" value="10.17487/RFC6614"/>
        </reference>

      <!--
        <reference anchor="PCI-TLS1"> anchor="RFC7457" target="https://www.rfc-editor.org/info/rfc7457" quoteTitle="true" derivedAnchor="RFC7457">
          <front>
          <title>Migrating from SSL
            <title>Summarizing Known Attacks on Transport Layer Security (TLS) and Early Datagram TLS
          https://www.pcisecuritystandards.org/documents/Migrating-from-SSL-Early-TLS-Info-Supp-v1_1.pdf</title>

          <author>
            <organization>PCI Security Standards Council</organization> (DTLS)</title>
            <author initials="Y." surname="Sheffer" fullname="Y. Sheffer">
              <organization showOnFrontPage="true"/>
            </author>

          <date year="2016"/>
        </front>
      </reference>
      -->

      <!--
      <reference anchor="stripe">
        <front>
				<title>"Upgrading to SHA-2 and TLSv1.2"
						https://stripe.com/blog/upgrading-tls
				</title>
          <author>
            <organization>Stripe</organization>
            <author initials="R." surname="Holz" fullname="R. Holz">
              <organization showOnFrontPage="true"/>
            </author>
          <date year="2018"/>
        </front>
      </reference>
		-->

      <!--
      <reference anchor="paypal">
        <front>
				<title>"TLS1.2 and HTTP/1.1 Upgrade"
		  https://www.paypal-notice.com/en/TLS-1.2-and-HTTP1.1-Upgrade/
  		</title>
          <author>
            <organization>Paypal</organization>
            <author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018"/>
        </front>
      </reference>
		-->

      <!--
      <reference anchor="GIT">
        <front>
          <title>GitHub Deprecates TLSv1.0 year="2015" month="February"/>
            <abstract>
              <t indent="0">Over the last few years, there have been several serious attacks on Transport Layer Security (TLS), including attacks on its most commonly used ciphers and TLSv1.1
          https://githubengineering.com/crypto-removal-notice/</title>
          <author>
            <organization>GitHub</organization>
          </author>
          <date year="2018"/>
        </front>
      </reference>
		-->

      <!--
      <reference anchor="CloudFlare">
        <front>
          <title>CloudFlare Deprecated TLSv1.0 modes of operation.  This document summarizes these attacks, with the goal of motivating generic and TLSv1.1
          https://blog.cloudflare.com/deprecating-old-tls-versions-on-cloudflare-dashboard-and-api/</title>

          <author>
            <organization>CloudFlare</organization>
          </author>

          <date year="2018"/>
        </front>
      </reference>
		-->

      <!--
      <reference anchor="Canada"
                 target="https://www.canada.ca/en/treasury-board-secretariat/services/information-technology/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html">
        <front>
          <title>Implementing HTTPS for Secure Web Connections: Information
          Technology Policy Implementation Notice (ITPIN)</title>

          <author>
            <organization>Treasury Board protocol-specific recommendations on the usage of Canada Secretariat</organization>
          </author>

          <date day="27" month="June" year="2018"/>
        </front>
      </reference>
      -->

      <!--
      <reference anchor="Digicert">
        <front>
          <title>Deprecating TLS 1.0 and 1.1
          https://www.digicert.com/blog/depreciating-tls-1-0-and-1-1/</title>

          <author>
            <organization>Digicert</organization>
          </author>

          <date year="2018"/> Datagram TLS (DTLS).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7457"/>
          <seriesInfo name="DOI" value="10.17487/RFC7457"/>
        </reference>
		-->

      <!--
        <reference anchor="KeyCDN"> anchor="RFC8143" target="https://www.rfc-editor.org/info/rfc8143" quoteTitle="true" derivedAnchor="RFC8143">
          <front>
          <title>Deprecating TLS 1.0 and 1.1 Enhancing
            <title>Using Transport Layer Security for Everyone
          https://www.keycdn.com/blog/deprecating-tls-1-0-and-1-1/</title>

          <author>
            <organization>KeyCDN</organization> (TLS) with Network News Transfer Protocol (NNTP)</title>
            <author initials="J." surname="Elie" fullname="J. Elie">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018"/> year="2017" month="April"/>
            <abstract>
              <t indent="0">This document provides recommendations for improving the security of the Network News Transfer Protocol (NNTP) when using Transport Layer Security (TLS).  It modernizes the NNTP usage of TLS to be consistent with TLS best current practices.  This document updates RFC 4642.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8143"/>
          <seriesInfo name="DOI" value="10.17487/RFC8143"/>
        </reference>
		-->

      <!--
        <reference anchor="chrome"> anchor="RFC8261" target="https://www.rfc-editor.org/info/rfc8261" quoteTitle="true" derivedAnchor="RFC8261">
          <front>
          <title>Modernizing
            <title>Datagram Transport Layer Security
          https://security.googleblog.com/2018/10/modernizing-transport-security.html</title>

          <author>
            <organization>Google</organization> (DTLS) Encapsulation of SCTP Packets</title>
            <author initials="M." surname="Tuexen" fullname="M. Tuexen">
              <organization showOnFrontPage="true"/>
            </author>

          <date year="2018"/>
        </front>
      </reference>
		-->

      <!--
      <reference anchor="edge">
         <front>
          <title>Modernizing TLS connections in Microsoft Edge and Internet Explorer 11
          https://blogs.windows.com/msedgedev/2018/10/15/modernizing-tls-edge-ie11/</title>

          <author>
            <organization>Microsoft</organization>
            <author initials="R." surname="Stewart" fullname="R. Stewart">
              <organization showOnFrontPage="true"/>
            </author>

          <date year="2018"/>
        </front>
      </reference>
		-->

      <!--
      <reference anchor="Amazon">
        <front>
          <title>Amazon Elastic Load Balancing Support Deprecated TLSv1.0 and
          TLSv1.1
          https://aws.amazon.com/about-aws/whats-new/2017/02/elastic-load-balancing-support-for-tls-1-1-and-tls-1-2-pre-defined-security-policies/</title>

          <author>
            <organization>Amazon</organization>
            <author initials="R." surname="Jesup" fullname="R. Jesup">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Loreto" fullname="S. Loreto">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017"/>
        </front>
      </reference>
		-->

      <!-- 2nd author name below - need year="2017" month="November"/>
            <abstract>
              <t indent="0">The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to figure HOWTO get fullname correct with non-ASCII
		   character - run on top of the "e" in "Gaetan" should network protocols IPv4 or IPv6.  This document specifies how SCTP can be an "e" with two dots above, as used on top of the Datagram Transport Layer Security (DTLS) protocol.  Using the encapsulation method described in PR#2 -->

      <reference anchor="Bhargavan2016">
        <front>
          <title>Transcript Collision Attacks: Breaking Authentication this document, SCTP is unaware of the protocols being used below DTLS; hence, explicit IP addresses cannot be used in TLS,
          IKE, and SSH
          https://www.mitls.org/downloads/transcript-collisions.pdf</title>

          <author fullname="Karthikeyan Bhargavan" initials="K.B."
                  surname="Bhargavan">
            <organization>INRIA</organization>
          </author>

          <author fullname="Gaetan Leuren" initials="G.L." surname="Leuren">
            <organization>INRIA</organization>
          </author>

          <date year="2016"/> the SCTP control chunks.  As a consequence, the SCTP associations carried over DTLS can only be single-homed.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8261"/>
          <seriesInfo name="DOI" value="10.17487/RFC8261"/>
        </reference>

      <!--
        <reference anchor="TGPP33310"> anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="RFC8446">
          <front>
          <title>TS 33.310 - Network Domain
            <title>The Transport Layer Security (NDS); Authentication
          Framework (AF)</title>

          <author>
            <organization>3GPP</organization> (TLS) Protocol Version 1.3</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016"/>
        </front>
      </reference>
      -->

      <!--
      <reference anchor="TR-02102-2">
        <front>
          <title>Technical Guideline TR-02102-2 Cryptographic Mechanisms:
          Recommendations year="2018" month="August"/>
            <abstract>
              <t indent="0">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 Key Lengths</title>

          <author>
            <organization>The German Federal Office message forgery.</t>
              <t indent="0">This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for Information Security
            https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-2.pdf</organization>
          </author>

          <date year="2019"/> TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
      -->

      <!--
        <reference anchor="clusters"> anchor="RFC8447" target="https://www.rfc-editor.org/info/rfc8447" quoteTitle="true" derivedAnchor="RFC8447">
          <front>
					  <title>"Clusters of re-used keys"
					  https://eprint.iacr.org/2018/299</title>
            <title>IANA Registry Updates for TLS and DTLS</title>
            <author initials="J." surname="Salowey" fullname="J. Salowey">
              <organization showOnFrontPage="true"/>
            </author>
            <author fullname="Stephen Farrell" initials="S." surname="Farrell" /> surname="Turner" fullname="S. Turner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" />
	  			</front>
	</reference>
	-->

      <?rfc include='reference.RFC.5246'?>

      <?rfc include='reference.RFC.6347'?>

      <?rfc include='reference.RFC.6460'?>

      <?rfc include='reference.RFC.6084'?>

      <?rfc include='reference.RFC.6083'?>

      <?rfc include='reference.RFC.6012'?>

      <?rfc include='reference.RFC.5456'?>

      <?rfc include='reference.RFC.5415'?>

      <!--
      <?rfc include='reference.RFC.7568'?>
		-->

      <?rfc include='reference.RFC.8143'?>

      <?rfc include='reference.RFC.8261'?>

      <?rfc include='reference.RFC.8446'?>

      <?rfc include='reference.RFC.8447'?>

      <!-- these are from nonobsnorms.sh.irefs -->

      <?rfc include='reference.RFC.5101'?>

      <?rfc include='reference.RFC.5081'?>

      <?rfc include='reference.RFC.5077'?>

      <?rfc include='reference.RFC.4934'?>

      <?rfc include='reference.RFC.4572'?>

      <?rfc include='reference.RFC.4507'?>

      <?rfc include='reference.RFC.4492'?>

      <?rfc include='reference.RFC.4366'?>

      <?rfc include='reference.RFC.4347'?>

      <?rfc include='reference.RFC.4244'?>

      <?rfc include='reference.RFC.4132'?>

      <?rfc include='reference.RFC.3920'?>

      <?rfc include='reference.RFC.3734'?>

      <?rfc include='reference.RFC.3588'?>

      <?rfc include='reference.RFC.3546'?>

      <?rfc include='reference.RFC.3489'?>

      <?rfc include='reference.RFC.3316'?>

      <?rfc include='reference.RFC.6614'?>

    </references>

    <section title="Change Log ">
      <t>[[RFC editor: please remove this before publication.]]</t>

      <t>From draft-ietf-tls-oldversions-deprecate-11 to
          draft-ietf-tls-oldversions-deprecate-12 (IESG review):
      <list style="symbols">
          <t>Minor edits from IESG review comments.</t>
      </list></t>

      <t>From draft-ietf-tls-oldversions-deprecate-10 to
          draft-ietf-tls-oldversions-deprecate-11:
      <list style="symbols">
      <t>RFC 5953 was mentioned in the wrong para of section 1.1 - it has been
          obsoleted already.</t>
      </list>
      </t>

      <t>From draft-ietf-tls-oldversions-deprecate-09 to
          draft-ietf-tls-oldversions-deprecate-10:
      <list style="symbols">
            <t>We missed adding change logs for month="August"/>
            <abstract>
              <t indent="0">This document describes a few versions, but
                since -09 was the one that underwent IETF last call,
                and there was some discussion, we figured it'd be good
                to mention substantive number of changes here.</t>
            <t>Added Ben's suggested text for "operational
                considerations" following extensive last call
                discussion.</t>
            <t>Re-checked the references to RFC 4347 after Tom Petch
                noticed we missed a couple. Added RFCs 5953 TLS and 6353 DTLS IANA registries that range from adding notes to the list here. All others were in already.</t>
            <t>Fixed various typos and ack'd those who engaged a bit
                in the IETF LC discussion. (If we missed you and you want to be added,
                or if you'd rather not be mentioned, just ping registry all the authors.) </t>
  </list></t>

      <t>From draft-ietf-tls-oldversions-deprecate-05 to
      draft-ietf-tls-oldversions-deprecate-06: <list style="symbols">

          <t>Fixed "yaleman" ack.</t>
          <t>Added RFC6614 to UPDATEs list.</t>
          <t>per preliminary AD review:
              <list style="symbols">
                  <t>Remove references from abstract</t>
                  <t>s/primary technical reasons/technical reasons/</t>
                  <t>Add rfc7030 way to 1.1</t>
                  <t>verified that all changing the RFCs in registration policy.  These changes were mostly motivated by WG review of the (massive:-) Updates meta-data
                      are mentioned in section 1.1 (I think appropriately;-)</t>
              </list>
          </t>
        </list></t>

      <t>From draft-ietf-tls-oldversions-deprecate-04 to
      draft-ietf-tls-oldversions-deprecate-05: <list style="symbols">
          <t>Removed references to goverment related deprecation statements:
          US, Canada, TLS- and Germany. NIST documentation rationale remains DTLS-related registries undertaken as a
          reference describing the relevent RFCs and justification.</t>
        </list></t>

      <t>From draft-ietf-tls-oldversions-deprecate-02 to
      draft-ietf-tls-oldversions-deprecate-03: <list style="symbols">
          <t>Added 8261 to updates list based on IETF-104 meeting.</t>
        </list></t>

      <t>From draft-ietf-tls-oldversions-deprecate-01 to
      draft-ietf-tls-oldversions-deprecate-02: <list style="symbols">
          <t>Correction: 2nd list part of referenced RFCs in <xref
          target="updates"/> aren't informatively refering to tls1.0/1.1</t>

          <t>Remove RFC7255 from the TLS 1.3 development process.</t>
              <t indent="0">This document updates list - datatracker has bad data
          (spotted by Robert Sparks)</t>

          <t>Added point about RFCs 8143 and 4642</t>

          <t>Added UPDATEs for RFCs that refer to 4347 the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and aren't
          OBSOLETEd</t>

          <t>Added note about RFC8261 7301.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8447"/>
          <seriesInfo name="DOI" value="10.17487/RFC8447"/>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">Thanks to see what WG want.</t>
        </list></t>

      <t>From draft-ietf-tls-oldversions-deprecate-00 to
      draft-ietf-tls-oldversions-deprecate-01: <list style="symbols">
          <t>PRs with typos those that provided usage data and similar: so far just #1</t>

          <t>PR#2 noting msft browser announced deprecation (but reviewed and/or improved
          this was OBE
          as per...)</t>

          <t>Implemented actions as per IETF-103 meeting: <list
              style="symbols">
              <t>Details about which RFC's, BCP's are affected were generated
              using a script in the git repo:
              https://github.com/tlswg/oldversions-deprecate/blob/master/nonobsnorms.sh</t>

              <t>Removed the 'measurements' part</t>

              <t>Removed SHA-1 deprecation (section 8 document, including: <contact fullname="Michael Ackermann"/>, <contact fullname="David Benjamin"/>, <contact fullname="David Black"/>,
        <contact fullname="Deborah Brungard"/>, <contact fullname="Alan DeKok"/>, <contact fullname="Viktor Dukhovni"/>, <contact fullname="Julien Élie"/>,
        <contact fullname="Adrian Farrelll"/>, <contact fullname="Gary Gapinski"/>, <contact fullname="Alessandro Ghedini"/>, <contact fullname="Peter         Gutmann"/>, <contact fullname="Jeremy Harris"/>, <contact fullname="Nick Hilliard"/>,
	<contact fullname="James Hodgkinson"/>, <contact fullname="Russ Housley"/>, <contact fullname="Hubert Kario"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="John Klensin"/>,
          <contact fullname="Watson Ladd"/>, <contact fullname="Eliot Lear"/>, <contact fullname="Ted Lemon"/>,
	  <contact fullname="John Mattsson"/>, <contact fullname="Keith Moore"/>, <contact fullname="Tom         Petch"/>, <contact fullname="Eric Mill"/>, <contact fullname="Yoav Nir"/>, <contact fullname="Andrei  Popov"/>, <contact fullname="Michael Richardson"/>, <contact fullname="Eric         Rescorla"/>, <contact fullname="Rich Salz"/>, <contact fullname="Mohit Sethi"/>, <contact fullname="Yaron Sheffer"/>, <contact fullname="Rob Sayre"/>,
        <contact fullname="Robert Sparks"/>, <contact fullname="Barbara Stark"/>, <contact fullname="Martin Thomson"/>, <contact fullname="Sean Turner"/>,
        <contact fullname="Loganaden Velvindron"/>, <contact fullname="Jakub Wilk"/>, and <contact fullname="Christopher Wood"/>.
      </t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Kathleen Moriarty" initials="K" surname="Moriarty">
        <organization abbrev="CIS" showOnFrontPage="true">Center for Internet Security (CIS)</organization>
        <address>
          <postal>
            <street/>
            <city>East Greenbush</city>
            <region>NY</region>
            <country>United States of -00)</t>
            </list></t>
        </list></t>

      <t>From draft-moriarty-tls-oldversions-diediedie-01 to
      draft-ietf-tls-oldversions-deprecate-00: <list style="symbols">
          <t>I-Ds became RFCs 8446/8447 (old-repo PR#4, for TLSv1.3)</t>

          <t>Accepted old-repo PR#5 fixing typos</t>
        </list></t>

      <t>From draft-moriarty-tls-oldversions-diediedie-00 to
      draft-moriarty-tls-oldversions-diediedie-01: <list style="symbols">
          <t>Added stats sent to list so far</t>

          <t>PR's #2,3</t>

          <t>a few more references</t>

          <t>added section on email</t>
        </list></t> America</country>
          </postal>
          <email>Kathleen.Moriarty.ietf@gmail.com</email>
        </address>
      </author>
      <author fullname="Stephen Farrell" initials="S." surname="Farrell">
        <organization showOnFrontPage="true">Trinity College Dublin</organization>
        <address>
          <postal>
            <street/>
            <city>Dublin</city>
            <region/>
            <code>2</code>
            <country>Ireland</country>
          </postal>
          <phone>+353-1-896-2354</phone>
          <email>stephen.farrell@cs.tcd.ie</email>
        </address>
      </author>
    </section>
  </back>
</rfc>