rfc8996xml2.original.xml   rfc8996.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!-- this is version 5 of this xml2rfc template --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="bcp" conse
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ nsus="true" docName="draft-ietf-tls-oldversions-deprecate-12" indexInclude="true
<!ENTITY rfc2119 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF " ipr="trust200902" number="8996" obsoletes="5469, 7507" prepTime="2021-03-22T15
C.2119.xml"> :03:43" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="tr
<!ENTITY rfc2223 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF ue" tocDepth="3" tocInclude="true" updates="3261, 3329, 3436, 3470, 3501, 3552,
C.2223.xml"> 3568, 3656, 3749, 3767, 3856, 3871, 3887, 3903, 3943, 3983, 4097, 4111,​ 4162, 4
<!ENTITY rfc2578 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF 168, 4217, 4235, 4261, 4279, 4497, 4513, 4531, 4540, 4582, 4616, 4642, 4680, 468
C.2578.xml"> 1, 4712, 4732, 4743,​ 4744, 4785, 4791, 4823, 4851, 4964, 4975, 4976, 4992, 5018
<!ENTITY rfc2579 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF , 5019, 5023, 5024, 5049, 5054, 5091, 5158, 5216,​ 5238, 5263, 5281, 5364, 5415,
C.2579.xml"> 5422, 5456, 5734, 5878, 5953, 6012, 6042, 6083, 6084, 6176, 6347, 6353, 6367,​
<!ENTITY rfc2580 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF 6460, 6614, 6739, 6749, 6750, 7030, 7465, 7525, 7562, 7568, 8261, 8422" xml:lang
C.2580.xml"> ="en">
<!ENTITY rfc2629 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF <link href="https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprec
C.2629.xml"> ate-12" rel="prev"/>
<!ENTITY rfc3261 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF <link href="https://dx.doi.org/10.17487/rfc8996" rel="alternate"/>
C.3261.xml"> <link href="urn:issn:2070-1721" rel="alternate"/>
<!ENTITY rfc3316 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.3316.xml">
<!ENTITY rfc3329 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.3329.xml">
<!ENTITY rfc3410 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.3410.xml">
<!ENTITY rfc3436 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.3436.xml">
<!ENTITY rfc3470 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.3470.xml">
<!ENTITY rfc3489 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.3489.xml">
<!ENTITY rfc3501 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.3501.xml">
<!ENTITY rfc3546 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.3546.xml">
<!ENTITY rfc3552 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.3552.xml">
<!ENTITY rfc3568 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.3568.xml">
<!ENTITY rfc3588 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.3588.xml">
<!ENTITY rfc3656 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.3656.xml">
<!ENTITY rfc3734 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.3734.xml">
<!ENTITY rfc3749 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.3749.xml">
<!ENTITY rfc3767 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.3767.xml">
<!ENTITY rfc3856 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.3856.xml">
<!ENTITY rfc3887 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.3887.xml">
<!ENTITY rfc3903 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.3903.xml">
<!ENTITY rfc3920 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.3920.xml">
<!ENTITY rfc3943 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.3943.xml">
<!ENTITY rfc3983 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.3983.xml">
<!ENTITY rfc4097 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4097.xml">
<!ENTITY rfc4111 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4111.xml">
<!ENTITY rfc4132 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4132.xml">
<!ENTITY rfc4162 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4162.xml">
<!ENTITY rfc4168 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4168.xml">
<!ENTITY rfc4181 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4181.xml">
<!ENTITY rfc4217 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4217.xml">
<!ENTITY rfc4235 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4235.xml">
<!ENTITY rfc4244 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4244.xml">
<!ENTITY rfc4261 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4261.xml">
<!ENTITY rfc4279 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4279.xml">
<!ENTITY rfc4366 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4366.xml">
<!ENTITY rfc4492 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4492.xml">
<!ENTITY rfc4497 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4497.xml">
<!ENTITY rfc4507 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4507.xml">
<!ENTITY rfc4513 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4513.xml">
<!ENTITY rfc4531 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4531.xml">
<!ENTITY rfc4540 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4540.xml">
<!ENTITY rfc4572 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4572.xml">
<!ENTITY rfc4582 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4582.xml">
<!ENTITY rfc4616 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4616.xml">
<!ENTITY rfc4642 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4642.xml">
<!ENTITY rfc4680 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4680.xml">
<!ENTITY rfc4681 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4681.xml">
<!ENTITY rfc4712 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4712.xml">
<!ENTITY rfc4732 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4732.xml">
<!ENTITY rfc4743 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4743.xml">
<!ENTITY rfc4744 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4744.xml">
<!ENTITY rfc4785 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4785.xml">
<!ENTITY rfc4791 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4791.xml">
<!ENTITY rfc4823 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4823.xml">
<!ENTITY rfc4851 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4851.xml">
<!ENTITY rfc4934 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4934.xml">
<!ENTITY rfc4964 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4964.xml">
<!ENTITY rfc4975 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4975.xml">
<!ENTITY rfc4976 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4976.xml">
<!ENTITY rfc4992 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.4992.xml">
<!ENTITY rfc5018 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.5018.xml">
<!ENTITY rfc5019 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.5019.xml">
<!ENTITY rfc5023 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.5023.xml">
<!ENTITY rfc5024 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.5024.xml">
<!ENTITY rfc5049 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.5049.xml">
<!ENTITY rfc5054 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.5054.xml">
<!ENTITY rfc5077 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.5077.xml">
<!ENTITY rfc5081 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.5081.xml">
<!ENTITY rfc5091 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.5091.xml">
<!ENTITY rfc5101 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.5101.xml">
<!ENTITY rfc5158 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.5158.xml">
<!ENTITY rfc5216 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.5216.xml">
<!ENTITY rfc5238 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.5238.xml">
<!ENTITY rfc5281 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.5281.xml">
<!ENTITY rfc5364 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.5364.xml">
<!ENTITY rfc5422 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.5422.xml">
<!ENTITY rfc5469 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.5469.xml">
<!ENTITY rfc5734 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.5734.xml">
<!ENTITY rfc5878 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.5878.xml">
<!ENTITY rfc5953 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.5953.xml">
<!ENTITY rfc6042 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.6042.xml">
<!ENTITY rfc6176 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.6176.xml">
<!ENTITY rfc6353 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.6353.xml">
<!ENTITY rfc6367 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.6367.xml">
<!ENTITY rfc6614 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.6614.xml">
<!ENTITY rfc6739 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.6739.xml">
<!ENTITY rfc6749 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.6749.xml">
<!ENTITY rfc6750 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.6750.xml">
<!ENTITY rfc7030 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.7030.xml">
<!ENTITY rfc7465 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.7465.xml">
<!ENTITY rfc7507 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.7507.xml">
<!ENTITY rfc7562 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.7562.xml">
<!ENTITY rfc7568 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.7568.xml">
<!ENTITY rfc8422 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.8422.xml">
<!ENTITY rfc8143 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.8261.xml">
<!ENTITY rfc6347 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.6347.xml">
<!ENTITY rfc6460 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.6460.xml">
<!ENTITY rfc6084 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.6084.xml">
<!ENTITY rfc6083 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.6083.xml">
<!ENTITY rfc6012 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.6012.xml">
<!ENTITY rfc5456 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.5456.xml">
<!ENTITY rfc5415 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RF
C.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"?>
<rfc category="bcp" docName="draft-ietf-tls-oldversions-deprecate-12"
ipr="trust200902"
updates="8422 8261 7568 7562 7525 7465 7030 6750 6749 6739 6460 6614 6367 6
353 6347 6176 6084 6083 6042 6012 5953 5878 5734 5456 5422 5415 5364 5281 5263 5
238 5216 5158 5091 5054 5049 5024 5023 5019 5018 4992 4976 4975 4964 4851 4823 4
791 4785 4744 4743 4732 4712 4681 4680 4642 4616 4582 4540 4531 4513 4497 4279 4
261 4235 4217 4168 4162 4111 4097 3983 3943 3903 3887 3871 3856 3767 3749 3656 3
568 3552 3501 3470 3436 3329 3261"
obsoletes="5469 7507">
<front> <front>
<title abbrev="Deprecating TLSv1.0 and TLSv1.1">Deprecating TLSv1.0 and <title abbrev="Deprecating TLS 1.0 and TLS 1.1">Deprecating TLS 1.0 and TLS
TLSv1.1</title> 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"> <author fullname="Kathleen Moriarty" initials="K" surname="Moriarty">
<organization>Dell EMC</organization> <organization abbrev="CIS" showOnFrontPage="true">Center for Internet Secu
rity (CIS)</organization>
<address> <address>
<postal> <postal>
<street>176 South Street</street> <street/>
<city>East Greenbush</city>
<city>Hopkinton</city> <region>NY</region>
<country>United States of America</country>
<country>United States</country>
</postal> </postal>
<email>Kathleen.Moriarty.ietf@gmail.com</email> <email>Kathleen.Moriarty.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Stephen Farrell" initials="S." surname="Farrell"> <author fullname="Stephen Farrell" initials="S." surname="Farrell">
<organization>Trinity College Dublin</organization> <organization showOnFrontPage="true">Trinity College Dublin</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city>Dublin</city> <city>Dublin</city>
<region/> <region/>
<code>2</code> <code>2</code>
<country>Ireland</country> <country>Ireland</country>
</postal> </postal>
<phone>+353-1-896-2354</phone> <phone>+353-1-896-2354</phone>
<email>stephen.farrell@cs.tcd.ie</email> <email>stephen.farrell@cs.tcd.ie</email>
</address> </address>
</author> </author>
<date month="03" year="2021"/>
<date year="2021"/>
<area>Security Area</area> <area>Security Area</area>
<workgroup>Internet Engineering Task Force</workgroup> <workgroup>Internet Engineering Task Force</workgroup>
<keyword>TLS</keyword> <keyword>TLS</keyword>
<keyword>deprecate</keyword> <keyword>deprecate</keyword>
<keyword>TLSv1.0</keyword> <keyword>TLSv1.0</keyword>
<keyword>TLSv1.1</keyword> <keyword>TLSv1.1</keyword>
<abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">
<abstract> This document formally deprecates Transport Layer
<t>
This document, if approved, formally deprecates Transport Layer
Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346).
Accordingly, those documents (will be moved|have been moved) Accordingly, those documents have been moved
to Historic status. These versions lack support for current to Historic status. These versions lack support for current
and recommended cryptographic algorithms and mechanisms, and and recommended cryptographic algorithms and mechanisms, and
various government and industry profiles of applications using various government and industry profiles of applications using
TLS now mandate avoiding these old TLS versions. TLSv1.2 TLS now mandate avoiding these old TLS versions. TLS version 1.2
became the recommended version for IETF protocols in 2008, became the recommended version for IETF protocols in 2008
(subsequently being obsoleted by TLSv1.3 in 2018), providing (subsequently being obsoleted by TLS version 1.3 in 2018), providing
sufficient time to transition away from older versions. sufficient time to transition away from older versions.
Removing support for older versions from implementations reduces the Removing support for older versions from implementations reduces the
attack surface, reduces opportunity for misconfiguration, and attack surface, reduces opportunity for misconfiguration, and
streamlines library and product maintenance. streamlines library and product maintenance.
</t> </t>
<t indent="0" pn="section-abstract-2">This document also deprecates Datagr
<t>This document also deprecates Datagram TLS (DTLS) version 1.0 am TLS (DTLS) version 1.0
(RFC 4347), but not DTLS version 1.2, and there is no DTLS (RFC 4347) but not DTLS version 1.2, and there is no DTLS
version 1.1.</t> version 1.1.</t>
<t indent="0" pn="section-abstract-3">This document updates many RFCs that
<t>This document updates many RFCs that normatively refer to TLSv1.0 or normatively refer to TLS version 1.0 or
TLSv1.1 as described herein. This document also updates the best TLS version 1.1, as described herein. This document also updates the best
practices for TLS usage in RFC 7525 and hence is part of BCP 195.</t> practices for TLS usage in RFC 7525; hence, it is part of BCP 195.</t>
</abstract> </abstract>
<boilerplate>
<section 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 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 obtained at
<eref target="https://www.rfc-editor.org/info/rfc8996" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" 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
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this 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 Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="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="sectio
n-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-rf
cs-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-te
rminology">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" form
at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-support-for-deprecation">Support f
or Deprecation</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="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" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="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" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="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" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-updates-to-rfc-7525">Updates to RF
C 7525</xref></t>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-operational-considerations">Operat
ional Considerations</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="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" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
rmat="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="sectio
n-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 deri
vedContent="" format="title" sectionFormat="of" target="name-normative-reference
s">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 deri
vedContent="" format="title" sectionFormat="of" target="name-informative-referen
ces">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="" form
at="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgeme
nts</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
<!-- <name slugifiedName="name-introduction">Introduction</name>
<t>[[Text in double-square brackets is intended <t indent="0" pn="section-1-1">Transport Layer Security (TLS) versions 1.0
to be fixed as the draft evolves. You've seen that we need to <xref target="RFC2246" format="default" sectionFormat="of" derivedContent="RFC2
figure out the list of RFCs that this'd update in the abstract. 246"/>
There is a repo for this at: https://github.com/tlswg/oldversions-depre and 1.1 <xref target="RFC4346" format="default" sectionFormat="of" derived
cate Content="RFC4346"/> were superseded by TLS 1.2 <xref target="RFC5246" format="de
- PRs (on the xml file) are welcome there.]]</t> fault" sectionFormat="of" derivedContent="RFC5246"/> in 2008, which has now itse
--> lf been superseded by
TLS 1.3 <xref target="RFC8446" format="default" sectionFormat="of" derived
<t>Transport Layer Security (TLS) versions 1.0 <xref target="RFC2246"/> Content="RFC8446"/>. Datagram Transport Layer Security
and 1.1 <xref target="RFC4346"/> were superseded by TLSv1.2 <xref (DTLS) version 1.0 <xref target="RFC4347" format="default" sectionFormat="
target="RFC5246"/> in 2008, which has now itself been superseded by of" derivedContent="RFC4347"/> was superseded by DTLS 1.2
TLSv1.3 <xref target="RFC8446"/>. Datagram Transport Layer Security <xref target="RFC6347" format="default" sectionFormat="of" derivedContent=
(DTLS) version 1.0 <xref target="RFC4347"/> was superseded by DTLSv1.2 "RFC6347"/> in 2012. Therefore, it is timely to further
<xref target="RFC6347"/> in 2012. It is therefore timely to further deprecate TLS 1.0, TLS 1.1, and DTLS 1.0.
deprecate TLSv1.0, TLSv1.1 and DTLSv1.0. Accordingly, the aforementioned documents have been moved to Historic stat
Accordingly, us.</t>
those documents (will be moved|have been moved) to Historic status.</t> <t indent="0" pn="section-1-2">Technical reasons for deprecating these ver
sions include:</t>
<!--The expectation is that TLSv1.2 will <ul spacing="compact" bare="false" empty="false" indent="3" pn="section-1-
continue to be used for many years alongside TLSv1.3.</t> 3">
--> <li pn="section-1-3.1">They require the implementation of older cipher s
uites that are no
<!-- longer desirable for cryptographic reasons, e.g., TLS 1.0 makes
<t>TLSv1.1 and TLSv1.0 are also actively being deprecated in accordance TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA mandatory to implement.</li>
with guidance from government agencies (e.g. <xref <li pn="section-1-3.2">There is a lack of support for current recommende
target="NIST800-52r2"/>) and industry consortia d cipher suites, especially
such as the Payment Card Industry Association (PCI) <xref authenticated encryption with associated data (AEAD) ciphers,
target="PCI-TLS1"/>.</t> which were not supported prior to TLS 1.2. Note that
<t>3GPP have deprecated TLSv1.0 and DTLSv1.0 since their release-14 in
2016. <xref target="TGPP33310"/></t>
-->
<t>Technical reasons for deprecating these versions include:</t>
<t><list style="symbols">
<t>They require implementation of older cipher suites that are no
longer desirable for cryptographic reasons, e.g., TLSv1.0 makes
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA mandatory to implement</t>
<t>Lack of support for current recommended cipher suites, especially
AEAD ciphers which are not supported prior to TLSv1.2. Note:
registry entries for no-longer-desirable ciphersuites remain in the registry entries for no-longer-desirable ciphersuites remain in the
registries, but many TLS registries are being updated through <xref registries, but many TLS registries were updated by <xref target="RFC8
target="RFC8447"/> which indicates that such entries are not 447" format="default" sectionFormat="of" derivedContent="RFC8447"/>, which indic
recommended by the IETF.</t> ates that such entries are not
recommended by the IETF.</li>
<t>Integrity of the handshake depends on SHA-1 hash.</t> <li pn="section-1-3.3">The integrity of the handshake depends on SHA-1 h
ash.</li>
<t>Authentication of the peers depends on SHA-1 signatures.</t> <li pn="section-1-3.4">The authentication of the peers depends on SHA-1
signatures.</li>
<t>Support for four TLS protocol versions increases the likelihood of <li pn="section-1-3.5">Support for four TLS protocol versions increases
misconfiguration.</t> the likelihood of
misconfiguration.</li>
<t>At least one widely-used library has plans to drop TLSv1.1 and <li pn="section-1-3.6">At least one widely used library has plans to dro
TLSv1.0 support in upcoming releases; products using such libraries p TLS 1.1 and
would need to use older versions of the libraries to support TLSv1.0 TLS 1.0 support in upcoming releases; products using such libraries
and TLSv1.1, which is clearly undesirable.</t> would need to use older versions of the libraries to support TLS 1.0
</list></t> and TLS 1.1, which is clearly undesirable.</li>
</ul>
<t>Deprecation of these versions is intended to assist developers as <t indent="0" pn="section-1-4">Deprecation of these versions is intended t
o assist developers as
additional justification to no longer support older (D)TLS versions and to additional justification to no longer support older (D)TLS versions and to
migrate to a minimum of (D)TLSv1.2. Deprecation also assists product teams migrate to a minimum of (D)TLS 1.2. Deprecation also assists product teams
with phasing out support for the older versions, to reduce the attack with phasing out support for the older versions, to reduce the attack
surface and the scope of maintenance for protocols in their surface and the scope of maintenance for protocols in their
offerings.</t> offerings.</t>
<section anchor="updates" numbered="true" toc="include" removeInRFC="false
<!-- duplication - already said in the bullet list above " pn="section-1.1">
<t>Some TLS libraries are considering dropping support for TLSv1.0 and <name slugifiedName="name-rfcs-updated">RFCs Updated</name>
TLSv1.1 in upcoming releases. If products do not follow suit because the <t indent="0" pn="section-1.1-1">This document updates the following RFC
protocol has not been deprecated, multiple libraries may be needed for a s that normatively reference
very small number of deployments. While fixes have been developed to TLS 1.0, TLS 1.1, or DTLS 1.0. The update is to obsolete usage of
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 document updates the following RFCs that normatively reference
TLSv1.0 or TLSv1.1 or DTLS1.0. The update is to obsolete usage of
these older versions. Fallback to these versions is prohibited these older versions. Fallback to these versions is prohibited
through this update. Specific references to mandatory minimum protocol through this update. Specific references to mandatory minimum protocol
versions of TLSv1.0 or TLSv1.1 are replaced by TLSv1.2, and references versions of TLS 1.0 or TLS 1.1 are replaced by TLS 1.2, and references
to minimum protocol version DTLSv1.0 are replaced by DTLSv1.2. to minimum protocol version DTLS 1.0 are replaced by DTLS 1.2.
Statements that "TLSv1.0 is the most widely deployed version and will Statements that "TLS 1.0 is the most widely deployed version and will
provide the broadest interoperability" are removed without provide the broadest interoperability" are removed without
replacement.</t> replacement.</t>
<t indent="0" pn="section-1.1-2">
<t> <xref target="RFC3261" format="default" sectionFormat="of" derivedCont
ent="RFC3261"/>
<xref target="RFC8422"/> <xref target="RFC3329" format="default" sectionFormat="of" derivedCont
<xref target="RFC8261"/> ent="RFC3329"/>
<xref target="RFC7568"/> <xref target="RFC3436" format="default" sectionFormat="of" derivedCont
<xref target="RFC7562"/> ent="RFC3436"/>
<xref target="RFC7525"/> <xref target="RFC3470" format="default" sectionFormat="of" derivedCont
<xref target="RFC7465"/> ent="RFC3470"/>
<xref target="RFC7030"/> <xref target="RFC3501" format="default" sectionFormat="of" derivedCont
<xref target="RFC6750"/> ent="RFC3501"/>
<xref target="RFC6749"/> <xref target="RFC3552" format="default" sectionFormat="of" derivedCont
<xref target="RFC6739"/> ent="RFC3552"/>
<xref target="RFC6084"/> <xref target="RFC3568" format="default" sectionFormat="of" derivedCont
<xref target="RFC6083"/> ent="RFC3568"/>
<xref target="RFC6367"/> <xref target="RFC3656" format="default" sectionFormat="of" derivedCont
<xref target="RFC6353"/> ent="RFC3656"/>
<xref target="RFC6176"/> <xref target="RFC3749" format="default" sectionFormat="of" derivedCont
<xref target="RFC6042"/> ent="RFC3749"/>
<xref target="RFC6012"/> <xref target="RFC3767" format="default" sectionFormat="of" derivedCont
<xref target="RFC5878"/> ent="RFC3767"/>
<xref target="RFC5734"/> <xref target="RFC3856" format="default" sectionFormat="of" derivedCont
<xref target="RFC5456"/> ent="RFC3856"/>
<xref target="RFC5422"/> <xref target="RFC3871" format="default" sectionFormat="of" derivedCont
<xref target="RFC5415"/> ent="RFC3871"/>
<xref target="RFC5364"/> <xref target="RFC3887" format="default" sectionFormat="of" derivedCont
<xref target="RFC5281"/> ent="RFC3887"/>
<xref target="RFC5263"/> <xref target="RFC3903" format="default" sectionFormat="of" derivedCont
<xref target="RFC5238"/> ent="RFC3903"/>
<xref target="RFC5216"/> <xref target="RFC3943" format="default" sectionFormat="of" derivedCont
<xref target="RFC5158"/> ent="RFC3943"/>
<xref target="RFC5091"/> <xref target="RFC3983" format="default" sectionFormat="of" derivedCont
<xref target="RFC5054"/> ent="RFC3983"/>
<xref target="RFC5049"/> <xref target="RFC4097" format="default" sectionFormat="of" derivedCont
<xref target="RFC5024"/> ent="RFC4097"/>
<xref target="RFC5023"/> <xref target="RFC4111" format="default" sectionFormat="of" derivedCont
<xref target="RFC5019"/> ent="RFC4111"/>
<xref target="RFC5018"/> <xref target="RFC4162" format="default" sectionFormat="of" derivedCont
<xref target="RFC4992"/> ent="RFC4162"/>
<xref target="RFC4976"/> <xref target="RFC4168" format="default" sectionFormat="of" derivedCont
<xref target="RFC4975"/> ent="RFC4168"/>
<xref target="RFC4964"/> <xref target="RFC4217" format="default" sectionFormat="of" derivedCont
<xref target="RFC4851"/> ent="RFC4217"/>
<xref target="RFC4823"/> <xref target="RFC4235" format="default" sectionFormat="of" derivedCont
<xref target="RFC4791"/> ent="RFC4235"/>
<xref target="RFC4785"/> <xref target="RFC4261" format="default" sectionFormat="of" derivedCont
<xref target="RFC4732"/> ent="RFC4261"/>
<xref target="RFC4712"/> <xref target="RFC4279" format="default" sectionFormat="of" derivedCont
<xref target="RFC4681"/> ent="RFC4279"/>
<xref target="RFC4680"/> <xref target="RFC4497" format="default" sectionFormat="of" derivedCont
<xref target="RFC4642"/> ent="RFC4497"/>
<xref target="RFC4616"/> <xref target="RFC4513" format="default" sectionFormat="of" derivedCont
<xref target="RFC4582"/> ent="RFC4513"/>
<xref target="RFC4540"/> <xref target="RFC4531" format="default" sectionFormat="of" derivedCont
<xref target="RFC4531"/> ent="RFC4531"/>
<xref target="RFC4513"/> <xref target="RFC4540" format="default" sectionFormat="of" derivedCont
<xref target="RFC4497"/> ent="RFC4540"/>
<xref target="RFC4279"/> <xref target="RFC4582" format="default" sectionFormat="of" derivedCont
<xref target="RFC4261"/> ent="RFC4582"/>
<xref target="RFC4235"/> <xref target="RFC4616" format="default" sectionFormat="of" derivedCont
<xref target="RFC4217"/> ent="RFC4616"/>
<xref target="RFC4168"/> <xref target="RFC4642" format="default" sectionFormat="of" derivedCont
<xref target="RFC4162"/> ent="RFC4642"/>
<xref target="RFC4111"/> <xref target="RFC4680" format="default" sectionFormat="of" derivedCont
<xref target="RFC4097"/> ent="RFC4680"/>
<xref target="RFC3983"/> <xref target="RFC4681" format="default" sectionFormat="of" derivedCont
<xref target="RFC3943"/> ent="RFC4681"/>
<xref target="RFC3903"/> <xref target="RFC4712" format="default" sectionFormat="of" derivedCont
<xref target="RFC3887"/> ent="RFC4712"/>
<xref target="RFC3871"/> <xref target="RFC4732" format="default" sectionFormat="of" derivedCont
<xref target="RFC3856"/> ent="RFC4732"/>
<xref target="RFC3767"/> <xref target="RFC4785" format="default" sectionFormat="of" derivedCont
<xref target="RFC3749"/> ent="RFC4785"/>
<xref target="RFC3656"/> <xref target="RFC4791" format="default" sectionFormat="of" derivedCont
<xref target="RFC3568"/> ent="RFC4791"/>
<xref target="RFC3552"/> <xref target="RFC4823" format="default" sectionFormat="of" derivedCont
<xref target="RFC3501"/> ent="RFC4823"/>
<xref target="RFC3470"/> <xref target="RFC4851" format="default" sectionFormat="of" derivedCont
<xref target="RFC3436"/> ent="RFC4851"/>
<xref target="RFC3329"/> <xref target="RFC4964" format="default" sectionFormat="of" derivedCont
<xref target="RFC3261"/> ent="RFC4964"/>
<xref target="RFC4975" format="default" sectionFormat="of" derivedCont
</t> ent="RFC4975"/>
<xref target="RFC4976" format="default" sectionFormat="of" derivedCont
<t>The status of <xref target="RFC7562"/>, <xref target="RFC6042"/>, ent="RFC4976"/>
<xref target="RFC5456"/>, <xref target="RFC5024"/>, <xref target="RFC4992" format="default" sectionFormat="of" derivedCont
<xref target="RFC4540"/>, and <xref target="RFC3656"/> will be ent="RFC4992"/>
updated with permission of the Independent Stream Editor. <xref target="RFC5018" format="default" sectionFormat="of" derivedCont
</t> ent="RFC5018"/>
<xref target="RFC5019" format="default" sectionFormat="of" derivedCont
<t>In addition these RFCs normatively refer to TLSv1.0 or TLSv1.1 and ent="RFC5019"/>
<xref target="RFC5023" format="default" sectionFormat="of" derivedCont
ent="RFC5023"/>
<xref target="RFC5024" format="default" sectionFormat="of" derivedCont
ent="RFC5024"/>
<xref target="RFC5049" format="default" sectionFormat="of" derivedCont
ent="RFC5049"/>
<xref target="RFC5054" format="default" sectionFormat="of" derivedCont
ent="RFC5054"/>
<xref target="RFC5091" format="default" sectionFormat="of" derivedCont
ent="RFC5091"/>
<xref target="RFC5158" format="default" sectionFormat="of" derivedCont
ent="RFC5158"/>
<xref target="RFC5216" format="default" sectionFormat="of" derivedCont
ent="RFC5216"/>
<xref target="RFC5238" format="default" sectionFormat="of" derivedCont
ent="RFC5238"/>
<xref target="RFC5263" format="default" sectionFormat="of" derivedCont
ent="RFC5263"/>
<xref target="RFC5281" format="default" sectionFormat="of" derivedCont
ent="RFC5281"/>
<xref target="RFC5364" format="default" sectionFormat="of" derivedCont
ent="RFC5364"/>
<xref target="RFC5415" format="default" sectionFormat="of" derivedCont
ent="RFC5415"/>
<xref target="RFC5422" format="default" sectionFormat="of" derivedCont
ent="RFC5422"/>
<xref target="RFC5456" format="default" sectionFormat="of" derivedCont
ent="RFC5456"/>
<xref target="RFC5734" format="default" sectionFormat="of" derivedCont
ent="RFC5734"/>
<xref target="RFC5878" format="default" sectionFormat="of" derivedCont
ent="RFC5878"/>
<xref target="RFC6012" format="default" sectionFormat="of" derivedCont
ent="RFC6012"/>
<xref target="RFC6042" format="default" sectionFormat="of" derivedCont
ent="RFC6042"/>
<xref target="RFC6083" format="default" sectionFormat="of" derivedCont
ent="RFC6083"/>
<xref target="RFC6084" format="default" sectionFormat="of" derivedCont
ent="RFC6084"/>
<xref target="RFC6176" format="default" sectionFormat="of" derivedCont
ent="RFC6176"/>
<xref target="RFC6353" format="default" sectionFormat="of" derivedCont
ent="RFC6353"/>
<xref target="RFC6367" format="default" sectionFormat="of" derivedCont
ent="RFC6367"/>
<xref target="RFC6739" format="default" sectionFormat="of" derivedCont
ent="RFC6739"/>
<xref target="RFC6749" format="default" sectionFormat="of" derivedCont
ent="RFC6749"/>
<xref target="RFC6750" format="default" sectionFormat="of" derivedCont
ent="RFC6750"/>
<xref target="RFC7030" format="default" sectionFormat="of" derivedCont
ent="RFC7030"/>
<xref target="RFC7465" format="default" sectionFormat="of" derivedCont
ent="RFC7465"/>
<xref target="RFC7525" format="default" sectionFormat="of" derivedCont
ent="RFC7525"/>
<xref target="RFC7562" format="default" sectionFormat="of" derivedCont
ent="RFC7562"/>
<xref target="RFC7568" format="default" sectionFormat="of" derivedCont
ent="RFC7568"/>
<xref target="RFC8261" format="default" sectionFormat="of" derivedCont
ent="RFC8261"/>
<xref target="RFC8422" format="default" sectionFormat="of" derivedCont
ent="RFC8422"/>
</t>
<t indent="0" pn="section-1.1-3">The status of <xref target="RFC7562" fo
rmat="default" sectionFormat="of" derivedContent="RFC7562"/>, <xref target="RFC6
042" format="default" sectionFormat="of" derivedContent="RFC6042"/>,
<xref target="RFC5456" format="default" sectionFormat="of" derive
dContent="RFC5456"/>, <xref target="RFC5024" format="default" sectionFormat="of"
derivedContent="RFC5024"/>,
<xref target="RFC4540" format="default" sectionFormat="of" derive
dContent="RFC4540"/>, and <xref target="RFC3656" format="default" sectionFormat=
"of" derivedContent="RFC3656"/> will be
updated with permission of the Independent Submissions Editor.
</t>
<t indent="0" pn="section-1.1-4">In addition, these RFCs normatively ref
er to TLS 1.0 or TLS 1.1 and
have already been obsoleted; they are still listed here and marked as 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 updated by this document in order to reiterate that any usage of the
obsolete protocol should still use modern TLS: obsolete protocol should use modern TLS:
<xref target="RFC5953"/> <xref target="RFC3316" format="default" sectionFormat="of" derive
<xref target="RFC5101"/> <xref target="RFC5081"/> dContent="RFC3316"/>,
<xref target="RFC5077"/> <xref target="RFC4934"/> <xref <xref target="RFC3489" format="default" sectionFormat="of" derive
target="RFC4572"/> <xref target="RFC4507"/> <xref target="RFC4492"/> dContent="RFC3489"/>,
<xref target="RFC4366"/> <xref target="RFC4347"/> <xref <xref target="RFC3546" format="default" sectionFormat="of" derive
target="RFC4244"/> <xref target="RFC4132"/> <xref target="RFC3920"/> dContent="RFC3546"/>,
<xref target="RFC3734"/> <xref target="RFC3588"/> <xref <xref target="RFC3588" format="default" sectionFormat="of" derive
target="RFC3546"/> <xref target="RFC3489"/> <xref dContent="RFC3588"/>,
target="RFC3316"/></t> <xref target="RFC3734" format="default" sectionFormat="of" deriv
edContent="RFC3734"/>,
<t>Note that <xref target="RFC4642"/> has already been <xref target="RFC3920" format="default" sectionFormat="of" derive
updated by <xref target="RFC8143"/>, which makes an overlapping, but dContent="RFC3920"/>,
<xref target="RFC4132" format="default" sectionFormat="of" derive
dContent="RFC4132"/>,
<xref target="RFC4244" format="default" sectionFormat="of" derive
dContent="RFC4244"/>,
<xref target="RFC4347" format="default" sectionFormat="of" derive
dContent="RFC4347"/>,
<xref target="RFC4366" format="default" sectionFormat="of" derive
dContent="RFC4366"/>,
<xref target="RFC4492" format="default" sectionFormat="of" derive
dContent="RFC4492"/>,
<xref target="RFC4507" format="default" sectionFormat="of" derive
dContent="RFC4507"/>,
<xref target="RFC4572" format="default" sectionFormat="of" derive
dContent="RFC4572"/>,
<xref target="RFC4582" format="default" sectionFormat="of" derive
dContent="RFC4582"/>,
<xref target="RFC4934" format="default" sectionFormat="of" derive
dContent="RFC4934"/>,
<xref target="RFC5077" format="default" sectionFormat="of" derive
dContent="RFC5077"/>,
<xref target="RFC5081" format="default" sectionFormat="of" derive
dContent="RFC5081"/>,
<xref target="RFC5101" format="default" sectionFormat="of" derive
dContent="RFC5101"/>, and
<xref target="RFC5953" format="default" sectionFormat="of" derive
dContent="RFC5953"/>.</t>
<t indent="0" pn="section-1.1-5">Note that <xref target="RFC4642" format
="default" sectionFormat="of" derivedContent="RFC4642"/> has already been
updated by <xref target="RFC8143" format="default" sectionFormat="of" de
rivedContent="RFC8143"/>, which makes an overlapping, but
not quite identical, update as this document.</t> not quite identical, update as this document.</t>
<t indent="0" pn="section-1.1-6"><xref target="RFC6614" format="default"
<t><xref target="RFC6614"/> has a requirement for TLSv1.1 or later, alth sectionFormat="of" derivedContent="RFC6614"/> has a requirement for TLS 1.1 or
ough later, although it
only makes an informative reference to <xref target="RFC4346"/>. only makes an informative reference to <xref target="RFC4346" format
This requirement is updated to be for TLSv1.2 or later.</t> ="default" sectionFormat="of" derivedContent="RFC4346"/>.
This requirement is updated to be for TLS 1.2 or later.</t>
<t><xref target="RFC6460"/>, <xref target="RFC4744"/>, and <xref target=" <t indent="0" pn="section-1.1-7"><xref target="RFC6460" format="default"
RFC4743"/> sectionFormat="of" derivedContent="RFC6460"/>, <xref target="RFC4744" format="d
efault" 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 are already Historic; they are still listed here and marked as
updated by this document in order to reiterate that any usage of the updated by this document in order to reiterate that any usage of the
obsolete protocol should still use modern TLS.</t> obsolete protocol should use modern TLS.</t>
<t indent="0" pn="section-1.1-8">This document updates DTLS <xref target
<t>This document updates DTLS <xref target="RFC6347"/>. <xref ="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"/>. <xre
target="RFC6347"/> had allowed for negotiating the use of DTLSv1.0, f target="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"/
> had allowed for negotiating the use of DTLS 1.0,
which is now forbidden.</t> which is now forbidden.</t>
<t indent="0" pn="section-1.1-9">The DES and International Data Encrypti
<t>The DES and IDEA cipher suites specified in <xref on Algorithm (IDEA) cipher suites
target="RFC5469"/> were specifically removed from TLSv1.2 by specified in <xref target="RFC5469" format="default" sectionFormat="of" d
<xref target="RFC5246"/>; since the only versions of TLS for which erivedContent="RFC5469"/> were specifically removed from TLS 1.2 by
their usage is defined are now Historic, RFC 5469 (will be|has been) <xref target="RFC5246" format="default" sectionFormat="of" derivedConten
t="RFC5246"/>; since the only versions of TLS for which
their usage is defined are now Historic, <xref target="RFC5469" format="
default" sectionFormat="of" derivedContent="RFC5469"/> has been
moved to Historic as well.</t> moved to Historic as well.</t>
<t indent="0" pn="section-1.1-10">The version-fallback Signaling Cipher
<t>The version-fallback Signaling Cipher Suite Value specified in Suite Value specified in
<xref target="RFC7507"/> was defined to detect when a given client <xref target="RFC7507" format="default" sectionFormat="of" derivedConten
t="RFC7507"/> was defined to detect when a given client
and server negotiate a lower version of (D)TLS than their highest and server negotiate a lower version of (D)TLS than their highest
shared version. TLSv1.3 (<xref target="RFC8446"/>) incorporates a shared version. TLS 1.3 (<xref target="RFC8446" format="default" sectio nFormat="of" derivedContent="RFC8446"/>) incorporates a
different mechanism that achieves this purpose, via sentinel values in different mechanism that achieves this purpose, via sentinel values in
the ServerHello.Random field. With (D)TLS versions prior to 1.2 fully the ServerHello.Random field. With (D)TLS versions prior to 1.2 fully
deprecated, the only way for (D)TLS implementations to negotiate a deprecated, the only way for (D)TLS implementations to negotiate a
lower version than their highest shared version would be to negotiate lower version than their highest shared version would be to negotiate
(D)TLSv1.2 while supporting (D)TLSv1.3; supporting (D)TLSv1.3 implies (D)TLS 1.2 while supporting (D)TLS 1.3; supporting (D)TLS 1.3 implies
support for the ServerHello.Random mechanism. Accordingly, the support for the ServerHello.Random mechanism. Accordingly, the
functionality from <xref target="RFC7507"/> has been superseded, and functionality from <xref target="RFC7507" format="default" sectionFormat ="of" derivedContent="RFC7507"/> has been superseded, and
this document marks it as Obsolete.</t> this document marks it as Obsolete.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-1.2
<section title="Terminology"> ">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <name slugifiedName="name-terminology">Terminology</name>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <t indent="0" pn="section-1.2-1">
"OPTIONAL" in this document are to be interpreted as described in BCP The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
when, they appear in all capitals, as shown here.</t> D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
OT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
</section> </section>
<section numbered="true" toc="include" anchor="support" removeInRFC="false"
<section title="Support for Deprecation"> pn="section-2">
<!-- Removing per WGLC Feedback from Martin Thomson <name slugifiedName="name-support-for-deprecation">Support for Deprecation
<t>Industry has actively followed guidance provided by NIST and the PCI </name>
Council to deprecate TLSv1.0 and TLSv1.1 by June 30, 2018. TLSv1.2 <t indent="0" pn="section-2-1">Specific details on attacks against TLS 1.0
should remain a minimum baseline for TLS support at this time.</t> and TLS 1.1, as well as
--> their mitigations, are provided in <xref target="NIST800-52r2" format="def
ault" sectionFormat="of" derivedContent="NIST800-52r2"/>,
<t>Specific details on attacks against TLSv1.0 and TLSv1.1, as well as <xref target="RFC7457" format="default" sectionFormat="of" derivedContent=
their mitigations, are provided in <xref target="NIST800-52r2"/>, "RFC7457"/>, and other
RFC 7457 <xref target="RFC7457"/> and other
RFCs referenced therein. Although mitigations for the current known RFCs referenced therein. Although mitigations for the current known
vulnerabilities have been developed, any future issues discovered in old vulnerabilities have been developed, any future issues discovered in old
protocol versions might not be mitigated in older library versions when protocol versions might not be mitigated in older library versions when
newer library versions do not support those old protocols.</t> newer library versions do not support those old protocols.</t>
<t indent="0" pn="section-2-2">For example, NIST has provided the followin
<!-- g rationale, copied with
Note that the use of "TLS 1.1" etc in the NIST quote below is permission from Section 1.1, "History of TLS", of <xref target="NIST800-52
deliberately not as used elsewhere in this document where we try r2" format="default" sectionFormat="of" derivedContent="NIST800-52r2"/>:
be consistent with e.g. "TLSv1.1" - that's just because this </t>
is a quote from NIST. <blockquote pn="section-2-3">
--> <t indent="0" pn="section-2-3.1">TLS 1.1, specified in RFC 4346 [24], wa
s developed to
<t>NIST for example has provided the following rationale, copied with
permission from <xref target="NIST800-52r2"/>,
section 1.2 "History of TLS" (with references changed for RFC
formatting).
<list>
<t>TLS 1.1, specified in <xref target="RFC4346"/>, was developed to
address weaknesses discovered in TLS 1.0, primarily in the areas of address weaknesses discovered in TLS 1.0, primarily in the areas of
initialization vector selection and padding error processing. initialization vector selection and padding error processing.
Initialization vectors were made explicit to prevent a certain class Initialization vectors were made explicit to prevent a certain class
of attacks on the Cipher Block Chaining (CBC) mode of operation used of attacks on the Cipher Block Chaining (CBC) mode of operation used
by TLS. The handling of padding errors was altered to treat a by TLS. The handling of padding errors was altered to treat a
padding error as a bad message authentication code, rather than a padding error as a bad message authentication code rather than a
decryption failure. In addition, the TLS 1.1 RFC acknowledges decryption failure. In addition, the TLS 1.1 RFC acknowledges
attacks on CBC mode that rely on the time to compute the message attacks on CBC mode that rely on the time to compute the message
authentication code (MAC). The TLS 1.1 specification states that to authentication code (MAC). The TLS 1.1 specification states that to
defend against such attacks, an implementation must process records defend against such attacks, an implementation must process records
in the same manner regardless of whether padding errors exist. in the same manner regardless of whether padding errors exist.
Further implementation considerations for CBC modes (which were not Further implementation considerations for CBC modes (which were not
included in <xref target="RFC4346">RFC4346</xref>) are discussed in included in RFC 4346 [24]) are discussed in
Section 3.3.2.</t> Section 3.3.2.</t>
<t indent="0" pn="section-2-3.2">TLS 1.2, specified in RFC 5246 [25], ma
<!--subcompact="yes" above isn't nice here - add lines --> de
<t/>
<t>TLSv1.2, specified in <xref target="RFC5246">RFC5246</xref>, made
several cryptographic enhancements, particularly in the area of hash several cryptographic enhancements, particularly in the area of hash
functions, with the ability to use or specify the SHA-2 family functions, with the ability to use or specify the SHA-2 family of
algorithms for hash, MAC, and Pseudorandom Function (PRF) algorithms for hash, MAC, and Pseudorandom Function (PRF)
computations. TLSv1.2 also adds authenticated encryption with computations. TLS 1.2 also adds authenticated encryption with
associated data (AEAD) cipher suites.</t> associated data (AEAD) cipher suites.</t>
<t indent="0" pn="section-2-3.3">TLS 1.3, specified in RFC 8446 [57],
<t/>
<t>TLSv1.3, specified in <xref target="RFC8446">TLSv1.3</xref>,
represents a significant change to TLS that aims to address threats represents a significant change to TLS that aims to address threats
that have arisen over the years. Among the changes are a new that have arisen over the years. Among the changes are a new handshak
handshake protocol, a new key derivation process that uses the e protocol, a new key derivation process that uses the HMAC-based Extract-and-Ex
HMAC-based Extract-and-Expand Key Derivation Function (HKDF), and pand Key Derivation Function (HKDF) [37], and the removal of cipher suites that
the removal of cipher suites that use static RSA or DH key use RSA key transport or static Diffie-Hellman ( DH) [sic] key exchanges, the CB
exchanges, the CBC mode of operation, or SHA-1. The list of C mode of operation, or SHA-1. Many extensions defined for use with TLS 1.2 and
extensions that can be used with TLSv1.3 has been reduced previous versions cannot be used with TLS 1.3.</t>
considerably.</t> </blockquote>
</list></t>
<!--
<t>The German Federal Office for Information Security, recommends
against use of 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 versions of TLS not be used. <xref target="Canada"/></t>
<t>Various companies and web sites have announced plans to deprecate
these old versions of TLS.</t>
-->
</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, 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 of including the deprecation of
TLSv1.1 into their plans for deprecating TLSv1.0 for the PCI council
deadline. Support for TLSv1.1 has been removed by the July 2018 PCI deadli
ne
from 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 the publ
ic web vary, but have
been in general very low and declined fu
rther with the impending
PCI deadline 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 is still growing (+0.4%), and
has
reached 92% according to sslpulse as of June 19, 2018.
<xref target="SSLpulse"/> Deprecating TLS 1.0 and
TLS 1.1 will thus not have a major impact on browser or web server
implementations.
</t>
-->
<!--
<t><xref target="Alexa">The Top 1 Million Analysis</xref> from
February 2018 shows that for the sites surveyed, the vast majority
support TLSv1.2 (97.9 percent), with a mere 2.0 percent using TLSv1.0
and an even smaller percentage using TLSv1.1.
-->
<!--
<t><xref target="web-stats"/> presents statistics for use of TLS versions
in 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 p
ublic web deployments in
terms of the rate of adoption of
new TLS versions.
<xref target="mail-stats"/> presents statistics for use of TLS versions i
n the email applications.</t>
<!--
<t>In one 2018 ZMap-based study <xref target="clu
sters"/> of
~200,000 mail server IP addresses
in 10 countries, use
of TLSv1.0 for various TLS servic
es (both web and mail)
on IP addresses that host some ma
il service was seen at
10.6%. Use of TLSv1.1 was negligi
ble - at 0.01%, for
TLSv1.1, SSLv3 was twice as common
. TLSv1.2 was used for 89.3% 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 | - | - |
+- - - - - - - - - - - - - - - - +- - - - - - - - - - +- - - - - - +- - - - - -
- +- - - - - - - +- - - - - - - +- - - - - - - +
[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"/> presents statistics for 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 | - |
+- - - - - - - - - - - - - - - - +- - - - - - - - - - +- - - - - - +- - - - - -
- +- - - - - - - +- - - - - - - +- - - - - - - +
[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 for use of TLS versio
ns in the enterprise networks.
The tcd.ie numbers below were the result of a student pro
ject 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 |
+- - - - - - - - - - - - - - - - +- - - - - - - - - - +- - - - - - +- - - - - -
- +- - - - - - - +- - - - - - - +- - - - - - - +
[1] https://www.ietf.org/mail-archive/web/tls/current/msg26633.html
]]></artwork>
</figure>
</section>
</section> </section>
--> <section numbered="true" toc="include" anchor="sha-1" removeInRFC="false" pn
="section-3">
<section title="SHA-1 Usage Problematic in TLSv1.0 and TLSv1.1"> <name slugifiedName="name-sha-1-usage-problematic-in-">SHA-1 Usage Problem
<t>The integrity of both TLSv1.0 and TLSv1.1 depends on a running SHA-1 atic in TLS 1.0 and TLS 1.1</name>
<t indent="0" pn="section-3-1">The integrity of both TLS 1.0 and TLS 1.1 d
epends on a running SHA-1
hash of the exchanged messages. This makes it possible to perform a hash of the exchanged messages. This makes it possible to perform a
downgrade attack on the handshake by an attacker able to perform 2^77 downgrade attack on the handshake by an attacker able to perform 2<sup>77< /sup>
operations, well below the acceptable modern security margin.</t> operations, well below the acceptable modern security margin.</t>
<t indent="0" pn="section-3-2">Similarly, the authentication of the handsh
<t>Similarly, the authentication of the handshake depends on signatures ake depends on signatures
made using a SHA-1 hash or a not appreciably stronger concatenation of MD- made using a SHA-1 hash or a concatenation of MD5 and SHA-1
5 and SHA-1 hashes that is not appreciably stronger than a SHA-1 hash, allowing the at
hashes, allowing the attacker to impersonate a server when it is able to tacker to impersonate a server when it is able to
break the severely weakened SHA-1 hash.</t> break the severely weakened SHA-1 hash.</t>
<t indent="0" pn="section-3-3">Neither TLS 1.0 nor TLS 1.1 allows the peer
<t>Neither TLSv1.0 nor TLSv1.1 allow the peers to select a stronger hash s to select a stronger hash
for signatures in the ServerKeyExchange or CertificateVerify messages, for signatures in the ServerKeyExchange or CertificateVerify messages,
making the only upgrade path the use of a newer protocol version.</t> 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="de
<t>See <xref target="Bhargavan2016"/> for additional detail.</t> fault" sectionFormat="of" derivedContent="Bhargavan2016"/> for additional detail
s.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4">
<section title="Do Not Use TLSv1.0"> <name slugifiedName="name-do-not-use-tls-10">Do Not Use TLS 1.0</name>
<t>TLSv1.0 MUST NOT be used. <!-- I didn't get the reason for this here: < <t indent="0" pn="section-4-1">TLS 1.0 <bcp14>MUST NOT</bcp14> be used.
xref target="RFC8174"/>. --> Negotiation of TLS 1.0 from any version of TLS <bcp14>MUST NOT</bcp14> be
Negotiation of TLSv1.0 from any version of TLS MUST NOT be
permitted.</t> permitted.</t>
<t indent="0" pn="section-4-2">Any other version of TLS is more secure tha
<t>Any other version of TLS is more secure than TLSv1.0. While TLSv1.0 can n TLS 1.0. While TLS 1.0 can be
be
configured to prevent some types of interception, using the highest versio n configured to prevent some types of interception, using the highest versio n
available is preferred.</t> available is preferred.</t>
<t indent="0" pn="section-4-3">Pragmatically, clients <bcp14>MUST NOT</bcp
<t>Pragmatically, clients MUST NOT send a ClientHello with 14> send a ClientHello with
ClientHello.client_version set to {03,01}. Similarly, servers MUST NOT ClientHello.client_version set to {03,01}.  Similarly, servers <bcp14>MUST
send a ServerHello with ServerHello.server_version set to {03,01}. Any NOT</bcp14>
send a ServerHello with ServerHello.server_version set to {03,01}.  Any
party receiving a Hello message with the protocol version set to {03,01} party receiving a Hello message with the protocol version set to {03,01}
MUST respond with a "protocol_version" alert message and close the <bcp14>MUST</bcp14> respond with a "protocol_version" alert message and cl ose the
connection.</t> connection.</t>
<t indent="0" pn="section-4-4">Historically, TLS specifications were not c
<t>Historically, TLS specifications were not clear on what the record lear on what the record
layer version number (TLSPlaintext.version) could contain when sending layer version number (TLSPlaintext.version) could contain when sending
ClientHello. Appendix E of [RFC5246] notes that TLSPlaintext.version 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 could be selected to maximize interoperability, though no definitive
value is identified as ideal. That guidance is still applicable; value is identified as ideal. That guidance is still applicable;
therefore, TLS servers MUST accept any value {03,XX} (including {03,00}) therefore, TLS servers <bcp14>MUST</bcp14> accept any value {03,XX} (inclu
as the record layer version number for ClientHello, but they MUST NOT ding {03,00})
negotiate TLSv1.0.</t> as the record layer version number for ClientHello, but they <bcp14>MUST N
OT</bcp14>
<!-- negotiate TLS 1.0.</t>
<t>[[Text here is derived (or stolen:-) from <xref target="RFC7568"/>]]
</t>
-->
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5">
<section title="Do Not Use TLSv1.1"> <name slugifiedName="name-do-not-use-tls-11">Do Not Use TLS 1.1</name>
<t>TLSv1.1 MUST NOT be used. Negotiation of TLSv1.1 from any version of <t indent="0" pn="section-5-1">TLS 1.1 <bcp14>MUST NOT</bcp14> be used. Ne
TLS MUST NOT be permitted.</t> gotiation of TLS 1.1 from any version of
TLS <bcp14>MUST NOT</bcp14> be permitted.</t>
<t>Pragmatically, clients MUST NOT send a ClientHello with <t indent="0" pn="section-5-2">Pragmatically, clients <bcp14>MUST NOT</bcp
ClientHello.client_version set to {03,02}. Similarly, servers MUST NOT 14> send a ClientHello with
send a ServerHello with ServerHello.server_version set to {03,02}. Any 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} party receiving a Hello message with the protocol version set to {03,02}
MUST respond with a "protocol_version" alert message and close the <bcp14>MUST</bcp14> respond with a "protocol_version" alert message and cl ose the
connection.</t> connection.</t>
<t indent="0" pn="section-5-3">Any newer version of TLS is more secure tha
<t>Any newer version of TLS is more secure than TLSv1.1. While TLSv1.1 can n TLS 1.1. While TLS 1.1 can be
be
configured to prevent some types of interception, using the highest versio n configured to prevent some types of interception, using the highest versio n
available is preferred. Support for TLSv1.1 is dwindling in libraries available is preferred. Support for TLS 1.1 is dwindling in libraries
and will impact security going forward if mitigations for attacks cannot and will impact security going forward if mitigations for attacks cannot
be easily addressed and supported in older libraries.</t> be easily addressed and supported in older libraries.</t>
<t indent="0" pn="section-5-4">Historically, TLS specifications were not c
<t>Historically, TLS specifications were not clear on what the record lear on what the record
layer version number (TLSPlaintext.version) could contain when sending layer version number (TLSPlaintext.version) could contain when sending
ClientHello. Appendix E of [RFC5246] notes that TLSPlaintext.version 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 could be selected to maximize interoperability, though no definitive
value is identified as ideal. That guidance is still applicable; value is identified as ideal. That guidance is still applicable;
therefore, TLS servers MUST accept any value {03,XX} (including {03,00}) therefore, TLS servers <bcp14>MUST</bcp14> accept any value {03,XX} (inclu
as the record layer version number for ClientHello, but they MUST NOT ding {03,00})
negotiate TLSv1.1.</t> as the record layer version number for ClientHello, but they <bcp14>MUST N
</section> OT</bcp14>
negotiate TLS 1.1.</t>
<!--
<section title="Do Not Use SHA-1 in TLSv1.2">
<t>[[This section was suggested in PR#2 for the pre-WG draft repo
by Hubert Kario. We're not
clear if the WG would like this draft 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 the
extension.</t>
<t>Note: this does not affect cipher suites that use SHA-1 HMAC for
data integrity as the HMAC construction is still considered secure
and when they are used in TLSv1.2 SHA-256 is used for handshake
integrity.</t>
</section> </section>
--> <section numbered="true" toc="include" removeInRFC="false" pn="section-6">
<name slugifiedName="name-updates-to-rfc-7525">Updates to RFC 7525</name>
<section title="Updates to RFC 7525"> <t indent="0" pn="section-6-1"><xref target="RFC7525" format="default" sec
<!-- tionFormat="of" derivedContent="RFC7525">"Recommendations for Secure Use of Tran
<t>[[Since RFC7525 is BCP 195, there'll probably be some process-fun to sport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"</xref>
do an update of that. Formally, it may be that this document becomes a is BCP 195, which is the
new part of BCP 195 I guess, but we can figure that out with chairs and most recent Best Current Practice for implementing TLS and was based on
ADs.]]</t> TLS 1.2. At the time of publication, TLS 1.0 and TLS 1.1 had not yet
-->
<t>RFC7525 is BCP 195, "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security (DTLS)", which is the
most recent best practice document for implementing 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 been deprecated. As such, BCP 195 is called out specifically to
update text implementing the deprecation recommendations of this update text implementing the deprecation recommendations of this
document.</t> document.</t>
<t indent="0" pn="section-6-2">This document updates <xref target="RFC7525
<t>This document updates <xref target="RFC7525"/> Section 3.1.1 " sectionFormat="of" section="3.1.1" format="default" derivedLink="https://rfc-e
changing SHOULD NOT to MUST NOT as follows:</t> ditor.org/rfc/rfc7525#section-3.1.1" derivedContent="RFC7525"/> by
changing <bcp14>SHOULD NOT</bcp14> to <bcp14>MUST NOT</bcp14> as follows:<
<t><list style="symbols"> /t>
<t>Implementations MUST NOT negotiate TLS version 1.0 <xref <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6-3
target="RFC2246"/>. <vspace blankLines="1"/> Rationale: TLSv1.0 ">
<li pn="section-6-3.1">
<t indent="0" pn="section-6-3.1.1">Implementations <bcp14>MUST NOT</bc
p14> negotiate TLS version 1.0 <xref target="RFC2246" format="default" sectionFo
rmat="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 (published in 1999) does not support many modern, strong cipher
suites. In addition, TLSv1.0 lacks a per- record Initialization suites. In addition, TLS 1.0 lacks a per-record Initialization
Vector (IV) for CBC-based cipher suites and does not warn against Vector (IV) for CBC-based cipher suites and does not warn against
common padding errors. <vspace blankLines="1"/></t> common padding errors. </t>
</li>
<t>Implementations MUST NOT negotiate TLS version 1.1 <xref <li pn="section-6-3.2">
target="RFC4346"/>. <vspace blankLines="1"/> Rationale: TLSv1.1 <t indent="0" pn="section-6-3.2.1">Implementations <bcp14>MUST NOT</bc
(published in 2006) is a security improvement over TLSv1.0 but still p14> negotiate TLS version 1.1 <xref target="RFC4346" format="default" sectionFo
rmat="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> does not support certain stronger cipher suites.</t>
</list></t> </li>
</ul>
<t>This documents updates <xref target="RFC7525"/> Section 3.1.2 <t indent="0" pn="section-6-4">This document updates <xref target="RFC7525
changing SHOULD NOT to MUST NOT as follows:</t> " sectionFormat="of" section="3.1.2" format="default" derivedLink="https://rfc-e
ditor.org/rfc/rfc7525#section-3.1.2" derivedContent="RFC7525"/> by
<t><list style="symbols"> changing <bcp14>SHOULD NOT</bcp14> to <bcp14>MUST NOT</bcp14> and adding a
<t>Implementations MUST NOT negotiate DTLS version 1.0 <xref reference to RFC 6347 as follows:</t>
target="RFC4347"/>, <xref target="RFC6347"/>. <vspace <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6-5
blankLines="1"/> Version 1.0 of DTLS correlates to version 1.1 of ">
<li pn="section-6-5.1">
<t indent="0" pn="section-6-5.1.1">Implementations <bcp14>MUST NOT</bc
p14> negotiate DTLS version 1.0 <xref target="RFC4347" format="default" sectionF
ormat="of" derivedContent="RFC4347"/> <xref target="RFC6347" format="default" se
ctionFormat="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> TLS (see above).</t>
</list></t> </li>
</ul>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-7">
<name slugifiedName="name-operational-considerations">Operational Consider
ations</name>
<t indent="0" pn="section-7-1">
<section title="Operational Considerations"> This document is part of BCP 195 and, as such, reflects the
understanding of the IETF (at the time of this document's publicatio
<t> n) as to the
This document is part of BCP 195, and as such reflects the
understanding of the IETF (at the time of its publication) as to the
best practices for TLS and DTLS usage. best practices for TLS and DTLS usage.
</t> </t>
<t indent="0" pn="section-7-2">
<t> Though TLS 1.1 has been obsolete since the publication of <xref targ
Though TLSv1.1 has been obsolete since the publication of RFC 5246 et="RFC5246" format="default" sectionFormat="of" derivedContent="RFC5246"/>
in 2008, and DTLSv1.0 has been obsolete since the publication of RFC in 2008, and DTLS 1.0 has been obsolete since the publication of <xr
6347 in 2012, there may remain some systems in operation that do not ef target="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"
support (D)TLSv1.2 or higher. Adopting the practices recommended by /> 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 this document for any systems that need to communicate with the
aforementioned class of systems will cause failure to interoperate. aforementioned class of systems will cause failure to interoperate.
However, disregarding the recommendations of this document in order However, disregarding the recommendations of this document in order
to continue to interoperate with the aforementioned class of systems to continue to interoperate with the aforementioned class of systems
incurs some amount of risk. The nature of the risks incurred by incurs some amount of risk. The nature of the risks incurred by
operating in contravention to the recommendations of this document operating in contravention to the recommendations of this document
are discussed in Sections 2 and 3, and knowledge of those risks are discussed in Sections <xref target="support" format="counter" se
ctionFormat="of" derivedContent="2"/> and
<xref target="sha-1" format="counter" sectionFormat="of" derivedConte
nt="3"/>, and knowledge of those risks
should be used along with any potential mitigating factors and the should be used along with any potential mitigating factors and the
risks inherent to updating the systems in question when deciding how risks inherent to updating the systems in question when deciding how
quickly to adopt the recommendations specified in this document. quickly to adopt the recommendations specified in this document.
</t> </t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-8">
<section title="Security Considerations"> <name slugifiedName="name-security-considerations">Security Considerations
<t>This document deprecates two older TLS protocol versions and one older </name>
<t indent="0" pn="section-8-1">This document deprecates two older TLS prot
ocol versions and one older
DTLS protocol version for security DTLS protocol version for security
reasons already described. The attack surface is reduced when there are reasons already described. The attack surface is reduced when there are
a smaller number of supported protocols and fallback options are a smaller number of supported protocols and fallback options are
removed.</t> removed.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-9">
<section title="Acknowledgements"> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t>Thanks to those that provided usage data, reviewed and/or improved <t indent="0" pn="section-9-1">This document has no IANA actions.</t>
this document, including: Michael Ackermann, David Benjamin, David Bla
ck,
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 to RFC editor: At least Julien Elie's name above should have
an accent on the first letter of the surname. Please fix that and any
others needing a similar fix if you can, I'm not sure the tooling I have
now allows that.]]</t>
</section>
<section title="IANA Considerations">
<t>[[This memo includes no request to IANA.]]</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references pn="section-10">
<?rfc include='reference.RFC.8174'?> <name slugifiedName="name-references">References</name>
<references pn="section-10.1">
<?rfc include='reference.RFC.2119'?> <name slugifiedName="name-normative-references">Normative References</na
me>
<?rfc include='reference.RFC.2246'?> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
<?rfc include='reference.RFC.4346'?> <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
<?rfc include='reference.RFC.7525'?> le>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<!-- these are from nonobsnorms.sh.refs --> <organization showOnFrontPage="true"/>
</author>
<?rfc include='reference.RFC.8422'?> <date year="1997" month="March"/>
<abstract>
<?rfc include='reference.RFC.7568'?> <t indent="0">In many standards track documents several words are
used to signify the requirements in the specification. These words are often ca
<?rfc include='reference.RFC.7562'?> pitalized. This document defines these words as they should be interpreted in IE
TF documents. This document specifies an Internet Best Current Practices for th
<?rfc include='reference.RFC.7507'?> e Internet Community, and requests discussion and suggestions for improvements.<
/t>
<?rfc include='reference.RFC.7465'?> </abstract>
</front>
<?rfc include='reference.RFC.7030'?> <seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<?rfc include='reference.RFC.6750'?> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<?rfc include='reference.RFC.6749'?> <reference anchor="RFC2246" target="https://www.rfc-editor.org/info/rfc2
246" quoteTitle="true" derivedAnchor="RFC2246">
<?rfc include='reference.RFC.6739'?> <front>
<title>The TLS Protocol Version 1.0</title>
<?rfc include='reference.RFC.6353'?> <author initials="T." surname="Dierks" fullname="T. Dierks">
<organization showOnFrontPage="true"/>
<?rfc include='reference.RFC.6367'?> </author>
<author initials="C." surname="Allen" fullname="C. Allen">
<?rfc include='reference.RFC.6176'?> <organization showOnFrontPage="true"/>
</author>
<?rfc include='reference.RFC.6042'?> <date year="1999" month="January"/>
<abstract>
<?rfc include='reference.RFC.5953'?> <t indent="0">This document specifies Version 1.0 of the Transport
Layer Security (TLS) protocol. The TLS protocol provides communications privacy
<?rfc include='reference.RFC.5878'?> over the Internet. The protocol allows client/server applications to communicat
e in a way that is designed to prevent eavesdropping, tampering, or message forg
<?rfc include='reference.RFC.5734'?> ery.</t>
</abstract>
<?rfc include='reference.RFC.5469'?> </front>
<seriesInfo name="RFC" value="2246"/>
<?rfc include='reference.RFC.5422'?> <seriesInfo name="DOI" value="10.17487/RFC2246"/>
</reference>
<?rfc include='reference.RFC.5364'?> <reference anchor="RFC3261" target="https://www.rfc-editor.org/info/rfc3
261" quoteTitle="true" derivedAnchor="RFC3261">
<?rfc include='reference.RFC.5281'?> <front>
<title>SIP: Session Initiation Protocol</title>
<?rfc include='reference.RFC.5263'?> <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
<organization showOnFrontPage="true"/>
<?rfc include='reference.RFC.5238'?> </author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
<?rfc include='reference.RFC.5216'?> ">
<organization showOnFrontPage="true"/>
<?rfc include='reference.RFC.5158'?> </author>
<author initials="G." surname="Camarillo" fullname="G. Camarillo">
<?rfc include='reference.RFC.5091'?> <organization showOnFrontPage="true"/>
</author>
<?rfc include='reference.RFC.5054'?> <author initials="A." surname="Johnston" fullname="A. Johnston">
<organization showOnFrontPage="true"/>
<?rfc include='reference.RFC.5049'?> </author>
<author initials="J." surname="Peterson" fullname="J. Peterson">
<?rfc include='reference.RFC.5024'?> <organization showOnFrontPage="true"/>
</author>
<?rfc include='reference.RFC.5023'?> <author initials="R." surname="Sparks" fullname="R. Sparks">
<organization showOnFrontPage="true"/>
<?rfc include='reference.RFC.5019'?> </author>
<author initials="M." surname="Handley" fullname="M. Handley">
<?rfc include='reference.RFC.5018'?> <organization showOnFrontPage="true"/>
</author>
<?rfc include='reference.RFC.4992'?> <author initials="E." surname="Schooler" fullname="E. Schooler">
<organization showOnFrontPage="true"/>
<?rfc include='reference.RFC.4976'?> </author>
<date year="2002" month="June"/>
<?rfc include='reference.RFC.4975'?> <abstract>
<t indent="0">This document describes Session Initiation Protocol
<?rfc include='reference.RFC.4964'?> (SIP), an application-layer control (signaling) protocol for creating, modifying
, and terminating sessions with one or more participants. These sessions includ
<?rfc include='reference.RFC.4851'?> e Internet telephone calls, multimedia distribution, and multimedia conferences.
[STANDARDS-TRACK]</t>
<?rfc include='reference.RFC.4823'?> </abstract>
</front>
<?rfc include='reference.RFC.4791'?> <seriesInfo name="RFC" value="3261"/>
<seriesInfo name="DOI" value="10.17487/RFC3261"/>
<?rfc include='reference.RFC.4785'?> </reference>
<reference anchor="RFC3329" target="https://www.rfc-editor.org/info/rfc3
<?rfc include='reference.RFC.4744'?> 329" quoteTitle="true" derivedAnchor="RFC3329">
<front>
<?rfc include='reference.RFC.4743'?> <title>Security Mechanism Agreement for the Session Initiation Proto
col (SIP)</title>
<?rfc include='reference.RFC.4732'?> <author initials="J." surname="Arkko" fullname="J. Arkko">
<organization showOnFrontPage="true"/>
<?rfc include='reference.RFC.4712'?> </author>
<author initials="V." surname="Torvinen" fullname="V. Torvinen">
<?rfc include='reference.RFC.4681'?> <organization showOnFrontPage="true"/>
</author>
<?rfc include='reference.RFC.4680'?> <author initials="G." surname="Camarillo" fullname="G. Camarillo">
<organization showOnFrontPage="true"/>
<?rfc include='reference.RFC.4642'?> </author>
<author initials="A." surname="Niemi" fullname="A. Niemi">
<?rfc include='reference.RFC.4616'?> <organization showOnFrontPage="true"/>
</author>
<?rfc include='reference.RFC.4582'?> <author initials="T." surname="Haukka" fullname="T. Haukka">
<organization showOnFrontPage="true"/>
<?rfc include='reference.RFC.4540'?> </author>
<date year="2003" month="January"/>
<?rfc include='reference.RFC.4531'?> </front>
<seriesInfo name="RFC" value="3329"/>
<?rfc include='reference.RFC.4513'?> <seriesInfo name="DOI" value="10.17487/RFC3329"/>
</reference>
<?rfc include='reference.RFC.4497'?> <reference anchor="RFC3436" target="https://www.rfc-editor.org/info/rfc3
436" quoteTitle="true" derivedAnchor="RFC3436">
<?rfc include='reference.RFC.4279'?> <front>
<title>Transport Layer Security over Stream Control Transmission Pro
<?rfc include='reference.RFC.4261'?> tocol</title>
<author initials="A." surname="Jungmaier" fullname="A. Jungmaier">
<?rfc include='reference.RFC.4235'?> <organization showOnFrontPage="true"/>
</author>
<?rfc include='reference.RFC.4217'?> <author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
<?rfc include='reference.RFC.4168'?> </author>
<author initials="M." surname="Tuexen" fullname="M. Tuexen">
<?rfc include='reference.RFC.4162'?> <organization showOnFrontPage="true"/>
</author>
<?rfc include='reference.RFC.4111'?> <date year="2002" month="December"/>
<abstract>
<?rfc include='reference.RFC.4097'?> <t indent="0">This document describes the usage of the Transport L
ayer Security (TLS) protocol, as defined in RFC 2246, over the Stream Control Tr
<?rfc include='reference.RFC.3983'?> ansmission 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 mult
<?rfc include='reference.RFC.3943'?> iple streams to avoid head of line blocking and the support of multi-homing to p
rovide network level fault tolerance. Additionally, discussions of extensions of
<?rfc include='reference.RFC.3903'?> SCTP are also supported, meaning especially the support of dynamic reconfigurat
ion of IP- addresses. [STANDARDS-TRACK]</t>
<?rfc include='reference.RFC.3887'?> </abstract>
</front>
<?rfc include='reference.RFC.3871'?> <seriesInfo name="RFC" value="3436"/>
<seriesInfo name="DOI" value="10.17487/RFC3436"/>
<?rfc include='reference.RFC.3856'?> </reference>
<reference anchor="RFC3470" target="https://www.rfc-editor.org/info/rfc3
<?rfc include='reference.RFC.3767'?> 470" quoteTitle="true" derivedAnchor="RFC3470">
<front>
<?rfc include='reference.RFC.3749'?> <title>Guidelines for the Use of Extensible Markup Language (XML) wi
thin IETF Protocols</title>
<?rfc include='reference.RFC.3656'?> <author initials="S." surname="Hollenbeck" fullname="S. Hollenbeck">
<organization showOnFrontPage="true"/>
<?rfc include='reference.RFC.3568'?> </author>
<author initials="M." surname="Rose" fullname="M. Rose">
<?rfc include='reference.RFC.3552'?> <organization showOnFrontPage="true"/>
</author>
<?rfc include='reference.RFC.3501'?> <author initials="L." surname="Masinter" fullname="L. Masinter">
<organization showOnFrontPage="true"/>
<?rfc include='reference.RFC.3470'?> </author>
<date year="2003" month="January"/>
<?rfc include='reference.RFC.3436'?> <abstract>
<t indent="0">The Extensible Markup Language (XML) is a framework
<?rfc include='reference.RFC.3329'?> for structuring data. While it evolved from Standard Generalized Markup Languag
e (SGML) -- a markup language primarily focused on structuring documents -- XML
<?rfc include='reference.RFC.3261'?> has evolved to be a widely-used mechanism for representing structured data. Ther
</references> e are a wide variety of Internet protocols being developed; many have need for a
representation for structured data relevant to their application. There has be
<references title="Informative References"> en much interest in the use of XML as a representation method. This document de
<?rfc include='reference.RFC.7457'?> scribes 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 Comm
<reference anchor="Alexa"> unity, and requests discussion and suggestions for improvements.</t>
<front> </abstract>
<title>The Alexa Top 1 Million Analysis </front>
https://scotthelme.co.uk/alexa-top-1-million-analysis-february-2018/</ <seriesInfo name="BCP" value="70"/>
title> <seriesInfo name="RFC" value="3470"/>
<seriesInfo name="DOI" value="10.17487/RFC3470"/>
<author> </reference>
<organization>Will be deleted before publication</organization> <reference anchor="RFC3501" target="https://www.rfc-editor.org/info/rfc3
</author> 501" quoteTitle="true" derivedAnchor="RFC3501">
<front>
<date year="2018"/> <title>INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1</title>
</front> <author initials="M." surname="Crispin" fullname="M. Crispin">
</reference> <organization showOnFrontPage="true"/>
--> </author>
<date year="2003" month="March"/>
<!-- <abstract>
<reference anchor="StackExchange"> <t indent="0">The Internet Message Access Protocol, Version 4rev1
<front> (IMAP4rev1) allows a client to access and manipulate electronic mail messages on
<title>Stackexchange a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders)
https://security.stackexchange.com/questions/177182/is-there-a-list-of in a way that is functionally equivalent to local folders. IMAP4rev1 also provi
-old-browsers-that-only-support-tls-1-0</title> des the capability for an offline client to resynchronize with the server. IMAP4
rev1 includes operations for creating, deleting, and renaming mailboxes, checkin
<author> g for new messages, permanently removing messages, setting and clearing flags, R
<organization>StackExchange - will be deleted before FC 2822 and RFC 2045 parsing, searching, and selective fetching of message attri
publication</organization> butes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the u
</author> se of numbers. These numbers are either message sequence numbers or unique ident
ifiers. IMAP4rev1 supports a single server. A mechanism for accessing configura
<date year="2018"/> tion information to support multiple IMAP4rev1 servers is discussed in RFC 2244.
</front> IMAP4rev1 does not specify a means of posting mail; this function is handled by
</reference> a mail transfer protocol such as RFC 2821. [STANDARDS-TRACK]</t>
--> </abstract>
</front>
<!-- <seriesInfo name="RFC" value="3501"/>
<reference anchor="Windows"> <seriesInfo name="DOI" value="10.17487/RFC3501"/>
<front> </reference>
<title>Windows <reference anchor="RFC3552" target="https://www.rfc-editor.org/info/rfc3
<author> 552" quoteTitle="true" derivedAnchor="RFC3552">
<organization>Andrei Popov</organization> <front>
</author> <title>Guidelines for Writing RFC Text on Security Considerations</t
<date year="2018"/> itle>
</front> <author initials="E." surname="Rescorla" fullname="E. Rescorla">
</reference> <organization showOnFrontPage="true"/>
</author>
<reference anchor="FF"> <author initials="B." surname="Korver" fullname="B. Korver">
<front> <organization showOnFrontPage="true"/>
<title>Firefox </author>
https://www.ietf.org/mail-archive/web/tls/current/msg26575.html</title <date year="2003" month="July"/>
> <abstract>
<author> <t indent="0">All RFCs are required to have a Security Considerati
<organization>Eric Rescorla</organization> ons section. Historically, such sections have been relatively weak. This docume
</author> nt provides guidelines to RFC authors on how to write a good Security Considerat
<date year="2018"/> ions section. This document specifies an Internet Best Current Practices for t
</front> he Internet Community, and requests discussion and suggestions for improvements.
</reference> </t>
--> </abstract>
</front>
<!-- <seriesInfo name="BCP" value="72"/>
<reference anchor="SSLpulse"> <seriesInfo name="RFC" value="3552"/>
<front> <seriesInfo name="DOI" value="10.17487/RFC3552"/>
<title>SSLpulse </reference>
https://www.ssllabs.com/ssl-pulse/</title> <reference anchor="RFC3568" target="https://www.rfc-editor.org/info/rfc3
<author> 568" quoteTitle="true" derivedAnchor="RFC3568">
<organization>SSLpulse - will be deleted before <front>
publication</organization> <title>Known Content Network (CN) Request-Routing Mechanisms</title>
</author> <author initials="A." surname="Barbir" fullname="A. Barbir">
<date year="2018"/> <organization showOnFrontPage="true"/>
</front> </author>
</reference> <author initials="B." surname="Cain" fullname="B. Cain">
--> <organization showOnFrontPage="true"/>
</author>
<reference anchor="NIST800-52r2"> <author initials="R." surname="Nair" fullname="R. Nair">
<front> <organization showOnFrontPage="true"/>
<title>NIST SP800-52r2 </author>
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2 <author initials="O." surname="Spatscheck" fullname="O. Spatscheck">
.pdf</title> <organization showOnFrontPage="true"/>
</author>
<author> <date year="2003" month="July"/>
<organization>National Institute of Standards and <abstract>
Technology</organization> <t indent="0">This document presents a summary of Request-Routing
</author> techniques that are used to direct client requests to surrogates based on variou
s policies and a possible set of metrics. The document covers techniques that w
<date month="August" year="2019"/> ere commonly used in the industry on or before December 2000. In this memo, the
</front> term Request-Routing represents techniques that is commonly called content rout
</reference> ing or content redirection. In principle, Request-Routing techniques can be cla
ssified under: DNS Request-Routing, Transport-layer Request-Routing, and Applica
<!-- tion-layer Request-Routing. This memo provides information for the Internet com
<reference anchor="PCI-TLS1"> munity.</t>
<front> </abstract>
<title>Migrating from SSL and Early TLS </front>
https://www.pcisecuritystandards.org/documents/Migrating-from-SSL-Earl <seriesInfo name="RFC" value="3568"/>
y-TLS-Info-Supp-v1_1.pdf</title> <seriesInfo name="DOI" value="10.17487/RFC3568"/>
</reference>
<author> <reference anchor="RFC3656" target="https://www.rfc-editor.org/info/rfc3
<organization>PCI Security Standards Council</organization> 656" quoteTitle="true" derivedAnchor="RFC3656">
</author> <front>
<title>The Mailbox Update (MUPDATE) Distributed Mailbox Database Pro
<date year="2016"/> tocol</title>
</front> <author initials="R." surname="Siemborski" fullname="R. Siemborski">
</reference> <organization showOnFrontPage="true"/>
--> </author>
<date year="2003" month="December"/>
<!-- <abstract>
<reference anchor="stripe"> <t indent="0">As the demand for high-performance mail delivery age
<front> nts increases, it becomes apparent that single-machine solutions are inadequate
<title>"Upgrading to SHA-2 and TLSv1.2" to the task, both because of capacity limits and that the failure of the single
https://stripe.com/blog/upgrading machine means a loss of mail delivery for all users. It is preferable to allow
-tls many machines to share the responsibility of mail delivery. The Mailbox Update
</title> (MUPDATE) protocol allows a group of Internet Message Access Protocol (IMAP) or
<author> Post Office Protocol - Version 3 (POP3) servers to function with a unified mailb
<organization>Stripe</organization> ox namespace. This document is intended to serve as a reference guide to that p
</author> rotocol.</t>
<date year="2018"/> </abstract>
</front> </front>
</reference> <seriesInfo name="RFC" value="3656"/>
--> <seriesInfo name="DOI" value="10.17487/RFC3656"/>
</reference>
<!-- <reference anchor="RFC3749" target="https://www.rfc-editor.org/info/rfc3
<reference anchor="paypal"> 749" quoteTitle="true" derivedAnchor="RFC3749">
<front> <front>
<title>"TLS1.2 and HTTP/1.1 Upgrade" <title>Transport Layer Security Protocol Compression Methods</title>
https://www.paypal-notice.com/en/TLS-1.2-and-HTTP1.1-Upgrade/ <author initials="S." surname="Hollenbeck" fullname="S. Hollenbeck">
</title> <organization showOnFrontPage="true"/>
<author> </author>
<organization>Paypal</organization> <date year="2004" month="May"/>
</author> <abstract>
<date year="2018"/> <t indent="0">The Transport Layer Security (TLS) protocol (RFC 224
</front> 6) includes features to negotiate selection of a lossless data compression metho
</reference> d as part of the TLS Handshake Protocol and to then apply the algorithm associat
--> ed 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 compress
<reference anchor="GIT"> ion method associated with a lossless data compression algorithm for use with TL
<front> S, and it describes a method for the specification of additional TLS compression
<title>GitHub Deprecates TLSv1.0 and TLSv1.1 methods. [STANDARDS-TRACK]</t>
https://githubengineering.com/crypto-removal-notice/</title> </abstract>
<author> </front>
<organization>GitHub</organization> <seriesInfo name="RFC" value="3749"/>
</author> <seriesInfo name="DOI" value="10.17487/RFC3749"/>
<date year="2018"/> </reference>
</front> <reference anchor="RFC3767" target="https://www.rfc-editor.org/info/rfc3
</reference> 767" quoteTitle="true" derivedAnchor="RFC3767">
--> <front>
<title>Securely Available Credentials Protocol</title>
<!-- <author initials="S." surname="Farrell" fullname="S. Farrell" role="
<reference anchor="CloudFlare"> editor">
<front> <organization showOnFrontPage="true"/>
<title>CloudFlare Deprecated TLSv1.0 and TLSv1.1 </author>
https://blog.cloudflare.com/deprecating-old-tls-versions-on-cloudflare <date year="2004" month="June"/>
-dashboard-and-api/</title> <abstract>
<t indent="0">This document describes a protocol whereby a user ca
<author> n acquire cryptographic credentials (e.g., private keys, PKCS #15 structures) fr
<organization>CloudFlare</organization> om a credential server, using a workstation that has locally trusted software in
</author> stalled, but with no user-specific configuration. The protocol's payloads are d
escribed in XML. This memo also specifies a Blocks Extensible Exchange Protocol
<date year="2018"/> (BEEP) profile of the protocol. Security requirements are met by mandating su
</front> pport for TLS and/or DIGEST-MD5 (through BEEP). [STANDARDS-TRACK]</t>
</reference> </abstract>
--> </front>
<seriesInfo name="RFC" value="3767"/>
<!-- <seriesInfo name="DOI" value="10.17487/RFC3767"/>
<reference anchor="Canada" </reference>
target="https://www.canada.ca/en/treasury-board-secretariat/ser <reference anchor="RFC3856" target="https://www.rfc-editor.org/info/rfc3
vices/information-technology/policy-implementation-notices/implementing-https-se 856" quoteTitle="true" derivedAnchor="RFC3856">
cure-web-connections-itpin.html"> <front>
<front> <title>A Presence Event Package for the Session Initiation Protocol
<title>Implementing HTTPS for Secure Web Connections: Information (SIP)</title>
Technology Policy Implementation Notice (ITPIN)</title> <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
<organization showOnFrontPage="true"/>
<author> </author>
<organization>Treasury Board of Canada Secretariat</organization> <date year="2004" month="August"/>
</author> <abstract>
<t indent="0">This document describes the usage of the Session Ini
<date day="27" month="June" year="2018"/> tiation Protocol (SIP) for subscriptions and notifications of presence. Presenc
</front> e is defined as the willingness and ability of a user to communicate with other
</reference> users on the network. Historically, presence has been limited to "on-line" and
--> "off-line" indicators; the notion of presence here is broader. Subscriptions an
d notifications of presence are supported by defining an event package within th
<!-- e general SIP event notification framework. This protocol is also compliant wit
<reference anchor="Digicert"> h the Common Presence Profile (CPP) framework. [STANDARDS-TRACK]</t>
<front> </abstract>
<title>Deprecating TLS 1.0 and 1.1 </front>
https://www.digicert.com/blog/depreciating-tls-1-0-and-1-1/</title> <seriesInfo name="RFC" value="3856"/>
<seriesInfo name="DOI" value="10.17487/RFC3856"/>
<author> </reference>
<organization>Digicert</organization> <reference anchor="RFC3871" target="https://www.rfc-editor.org/info/rfc3
</author> 871" quoteTitle="true" derivedAnchor="RFC3871">
<front>
<date year="2018"/> <title>Operational Security Requirements for Large Internet Service
</front> Provider (ISP) IP Network Infrastructure</title>
</reference> <author initials="G." surname="Jones" fullname="G. Jones" role="edit
--> or">
<organization showOnFrontPage="true"/>
<!-- </author>
<reference anchor="KeyCDN"> <date year="2004" month="September"/>
<front> <abstract>
<title>Deprecating TLS 1.0 and 1.1 Enhancing Security for Everyone <t indent="0">This document defines a list of operational security
https://www.keycdn.com/blog/deprecating-tls-1-0-and-1-1/</title> requirements for the infrastructure of large Internet Service Provider (ISP) IP
networks (routers and switches). A framework is defined for specifying "profil
<author> es", which are collections of requirements applicable to certain network topolog
<organization>KeyCDN</organization> y contexts (all, core-only, edge-only...). The goal is to provide network opera
</author> tors a clear, concise way of communicating their security requirements to vendor
s. This memo provides information for the Internet community.</t>
<date year="2018"/> </abstract>
</front> </front>
</reference> <seriesInfo name="RFC" value="3871"/>
--> <seriesInfo name="DOI" value="10.17487/RFC3871"/>
</reference>
<!-- <reference anchor="RFC3887" target="https://www.rfc-editor.org/info/rfc3
<reference anchor="chrome"> 887" quoteTitle="true" derivedAnchor="RFC3887">
<front> <front>
<title>Modernizing Transport Security <title>Message Tracking Query Protocol</title>
https://security.googleblog.com/2018/10/modernizing-transport-security <author initials="T." surname="Hansen" fullname="T. Hansen">
.html</title> <organization showOnFrontPage="true"/>
</author>
<author> <date year="2004" month="September"/>
<organization>Google</organization> <abstract>
</author> <t indent="0">Customers buying enterprise message systems often as
k: Can I track the messages? Message tracking is the ability to find out the pa
<date year="2018"/> th that a particular message has taken through a messaging system and the curren
</front> t routing status of that message. This document describes the Message Tracking
</reference> Query Protocol that is used in conjunction with extensions to the ESMTP protocol
--> to provide a complete message tracking solution for the Internet. [STANDARDS-T
RACK]</t>
<!-- </abstract>
<reference anchor="edge"> </front>
<front> <seriesInfo name="RFC" value="3887"/>
<title>Modernizing TLS connections in Microsoft Edge and Internet Expl <seriesInfo name="DOI" value="10.17487/RFC3887"/>
orer 11 </reference>
https://blogs.windows.com/msedgedev/2018/10/15/modernizing-tls-edge-ie <reference anchor="RFC3903" target="https://www.rfc-editor.org/info/rfc3
11/</title> 903" quoteTitle="true" derivedAnchor="RFC3903">
<front>
<author> <title>Session Initiation Protocol (SIP) Extension for Event State P
<organization>Microsoft</organization> ublication</title>
</author> <author initials="A." surname="Niemi" fullname="A. Niemi" role="edit
or">
<date year="2018"/> <organization showOnFrontPage="true"/>
</front> </author>
</reference> <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
<reference anchor="Amazon"> framework. The first application of this extension is for the publication of pr
<front> esence information. </t>
<title>Amazon Elastic Load Balancing Support Deprecated TLSv1.0 and <t indent="0"> The mechanism described in this document can be ext
TLSv1.1 ended to support publication of any event state for which there exists an approp
https://aws.amazon.com/about-aws/whats-new/2017/02/elastic-load-balanc riate event package. It is not intended to be a general-purpose mechanism for t
ing-support-for-tls-1-1-and-tls-1-2-pre-defined-security-policies/</title> ransport of arbitrary data, as there are better-suited mechanisms for this purpo
se. [STANDARDS-TRACK]</t>
<author> </abstract>
<organization>Amazon</organization> </front>
</author> <seriesInfo name="RFC" value="3903"/>
<seriesInfo name="DOI" value="10.17487/RFC3903"/>
<date year="2017"/> </reference>
</front> <reference anchor="RFC3943" target="https://www.rfc-editor.org/info/rfc3
</reference> 943" quoteTitle="true" derivedAnchor="RFC3943">
--> <front>
<title>Transport Layer Security (TLS) Protocol Compression Using Lem
<!-- 2nd author name below - need to figure HOWTO get fullname correct wit pel-Ziv-Stac (LZS)</title>
h non-ASCII <author initials="R." surname="Friend" fullname="R. Friend">
character - the "e" in "Gaetan" should be an "e" with two dots <organization showOnFrontPage="true"/>
above, as in PR#2 --> </author>
<date year="2004" month="November"/>
<reference anchor="Bhargavan2016"> <abstract>
<front> <t indent="0">The Transport Layer Security (TLS) protocol (RFC 224
<title>Transcript Collision Attacks: Breaking Authentication in TLS, 6) includes features to negotiate selection of a lossless data compression metho
IKE, and SSH d as part of the TLS Handshake Protocol and then to apply the algorithm associat
https://www.mitls.org/downloads/transcript-collisions.pdf</title> ed 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
<author fullname="Karthikeyan Bhargavan" initials="K.B." protocol will not be compressed. This document describes an additional compres
surname="Bhargavan"> sion method associated with the Lempel-Ziv-Stac (LZS) lossless data compression
<organization>INRIA</organization> algorithm for use with TLS. This document also defines the application of the L
</author> ZS algorithm to the TLS Record Protocol. This memo provides information for the
Internet community.</t>
<author fullname="Gaetan Leuren" initials="G.L." surname="Leuren"> </abstract>
<organization>INRIA</organization> </front>
</author> <seriesInfo name="RFC" value="3943"/>
<seriesInfo name="DOI" value="10.17487/RFC3943"/>
<date year="2016"/> </reference>
</front> <reference anchor="RFC3983" target="https://www.rfc-editor.org/info/rfc3
</reference> 983" quoteTitle="true" derivedAnchor="RFC3983">
<front>
<!-- <title>Using the Internet Registry Information Service (IRIS) over t
<reference anchor="TGPP33310"> he Blocks Extensible Exchange Protocol (BEEP)</title>
<front> <author initials="A." surname="Newton" fullname="A. Newton">
<title>TS 33.310 - Network Domain Security (NDS); Authentication <organization showOnFrontPage="true"/>
Framework (AF)</title> </author>
<author initials="M." surname="Sanz" fullname="M. Sanz">
<author> <organization showOnFrontPage="true"/>
<organization>3GPP</organization> </author>
</author> <date year="2005" month="January"/>
<abstract>
<date year="2016"/> <t indent="0">This document specifies how to use the Blocks Extens
</front> ible Exchange Protocol (BEEP) as the application transport substrate for the Int
</reference> ernet Registry Information Service (IRIS). [STANDARDS-TRACK]</t>
--> </abstract>
</front>
<!-- <seriesInfo name="RFC" value="3983"/>
<reference anchor="TR-02102-2"> <seriesInfo name="DOI" value="10.17487/RFC3983"/>
<front> </reference>
<title>Technical Guideline TR-02102-2 Cryptographic Mechanisms: <reference anchor="RFC4097" target="https://www.rfc-editor.org/info/rfc4
Recommendations and Key Lengths</title> 097" quoteTitle="true" derivedAnchor="RFC4097">
<front>
<author> <title>Middlebox Communications (MIDCOM) Protocol Evaluation</title>
<organization>The German Federal Office for Information Security <author initials="M." surname="Barnes" fullname="M. Barnes" role="ed
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Tec itor">
hGuidelines/TG02102/BSI-TR-02102-2.pdf</organization> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2005" month="June"/>
<date year="2019"/> <abstract>
</front> <t indent="0">This document provides an evaluation of the applicab
</reference> ility of SNMP (Simple Network Management Protocol), RSIP (Realm Specific Interne
--> t Protocol), Megaco, Diameter, and COPS (Common Open Policy Service) as the MIDC
OM (Middlebox Communications) protocol. A summary of each of the proposed proto
<!-- cols against the MIDCOM requirements and the MIDCOM framework is provided. Comp
<reference anchor="clusters"> liancy of each of the protocols against each requirement is detailed. A conclus
<front> ion summarizes how each of the protocols fares in the evaluation. This memo pro
<title>"Clusters of re-used keys" vides information for the Internet community.</t>
https://eprint.iacr.org/2018/299</title </abstract>
> </front>
<author fullname="Stephen Farrell" init <seriesInfo name="RFC" value="4097"/>
ials="S." surname="Farrell" /> <seriesInfo name="DOI" value="10.17487/RFC4097"/>
<date year="2018" /> </reference>
</front> <reference anchor="RFC4111" target="https://www.rfc-editor.org/info/rfc4
</reference> 111" quoteTitle="true" derivedAnchor="RFC4111">
--> <front>
<title>Security Framework for Provider-Provisioned Virtual Private N
<?rfc include='reference.RFC.5246'?> etworks (PPVPNs)</title>
<author initials="L." surname="Fang" fullname="L. Fang" role="editor
<?rfc include='reference.RFC.6347'?> ">
<organization showOnFrontPage="true"/>
<?rfc include='reference.RFC.6460'?> </author>
<date year="2005" month="July"/>
<?rfc include='reference.RFC.6084'?> <abstract>
<t indent="0">This document addresses security aspects pertaining
<?rfc include='reference.RFC.6083'?> to Provider-Provisioned Virtual Private Networks (PPVPNs). First, it describes
the security threats in the context of PPVPNs and defensive techniques to combat
<?rfc include='reference.RFC.6012'?> those threats. It considers security issues deriving both from malicious behav
ior of anyone and from negligent or incorrect behavior of the providers. It als
<?rfc include='reference.RFC.5456'?> o describes how these security attacks should be detected and reported. It then
discusses possible user requirements for security of a PPVPN service. These us
<?rfc include='reference.RFC.5415'?> er requirements translate into corresponding provider requirements. In addition
, the provider may have additional requirements to make its network infrastructu
<!-- re secure to a level that can meet the PPVPN customer's expectations. Finally, t
<?rfc include='reference.RFC.7568'?> his document defines a template that may be used to describe and analyze the sec
--> urity characteristics of a specific PPVPN technology. This memo provides inform
ation for the Internet community.</t>
<?rfc include='reference.RFC.8143'?> </abstract>
</front>
<?rfc include='reference.RFC.8261'?> <seriesInfo name="RFC" value="4111"/>
<seriesInfo name="DOI" value="10.17487/RFC4111"/>
<?rfc include='reference.RFC.8446'?> </reference>
<reference anchor="RFC4162" target="https://www.rfc-editor.org/info/rfc4
<?rfc include='reference.RFC.8447'?> 162" quoteTitle="true" derivedAnchor="RFC4162">
<front>
<!-- these are from nonobsnorms.sh.irefs --> <title>Addition of SEED Cipher Suites to Transport Layer Security (T
LS)</title>
<?rfc include='reference.RFC.5101'?> <author initials="H.J." surname="Lee" fullname="H.J. Lee">
<organization showOnFrontPage="true"/>
<?rfc include='reference.RFC.5081'?> </author>
<author initials="J.H." surname="Yoon" fullname="J.H. Yoon">
<?rfc include='reference.RFC.5077'?> <organization showOnFrontPage="true"/>
</author>
<?rfc include='reference.RFC.4934'?> <author initials="J.I." surname="Lee" fullname="J.I. Lee">
<organization showOnFrontPage="true"/>
<?rfc include='reference.RFC.4572'?> </author>
<date year="2005" month="August"/>
<?rfc include='reference.RFC.4507'?> <abstract>
<t indent="0">This document proposes the addition of new cipher su
<?rfc include='reference.RFC.4492'?> ites to the Transport Layer Security (TLS) protocol to support the SEED encrypti
on algorithm as a bulk cipher algorithm. [STANDARDS-TRACK]</t>
<?rfc include='reference.RFC.4366'?> </abstract>
</front>
<?rfc include='reference.RFC.4347'?> <seriesInfo name="RFC" value="4162"/>
<seriesInfo name="DOI" value="10.17487/RFC4162"/>
<?rfc include='reference.RFC.4244'?> </reference>
<reference anchor="RFC4168" target="https://www.rfc-editor.org/info/rfc4
<?rfc include='reference.RFC.4132'?> 168" quoteTitle="true" derivedAnchor="RFC4168">
<front>
<?rfc include='reference.RFC.3920'?> <title>The Stream Control Transmission Protocol (SCTP) as a Transpor
t for the Session Initiation Protocol (SIP)</title>
<?rfc include='reference.RFC.3734'?> <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
<organization showOnFrontPage="true"/>
<?rfc include='reference.RFC.3588'?> </author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
<?rfc include='reference.RFC.3546'?> ">
<organization showOnFrontPage="true"/>
<?rfc include='reference.RFC.3489'?> </author>
<author initials="G." surname="Camarillo" fullname="G. Camarillo">
<?rfc include='reference.RFC.3316'?> <organization showOnFrontPage="true"/>
</author>
<?rfc include='reference.RFC.6614'?> <date year="2005" month="October"/>
<abstract>
<t indent="0">This document specifies a mechanism for usage of SCT
P (the Stream Control Transmission Protocol) as the transport mechanism between
SIP (Session Initiation Protocol) entities. SCTP is a new protocol that provide
s several features that may prove beneficial for transport between SIP entities
that exchange a large amount of messages, including gateways and proxies. As SI
P is transport-independent, support of SCTP is a relatively straightforward proc
ess, 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/rfc4
217" quoteTitle="true" derivedAnchor="RFC4217">
<front>
<title>Securing FTP with TLS</title>
<author initials="P." surname="Ford-Hutchinson" fullname="P. Ford-Hu
tchinson">
<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 T
LS protocol defined by RFC 2246, "The TLS Protocol Version 1.0.", and the extens
ions to the FTP protocol defined by RFC 2228, "FTP Security Extensions". It desc
ribes the subset of the extensions that are required and the parameters to be us
ed, discusses some of the policy issues that clients and servers will need to ta
ke, considers some of the implications of those policies, and discusses some exp
ected behaviours of implementations to allow interoperation. This document is i
ntended to provide TLS support for FTP in a similar way to that provided for SMT
P in RFC 2487, "SMTP Service Extension for Secure SMTP over Transport Layer Secu
rity", and HTTP in RFC 2817, "Upgrading to TLS Within HTTP/1.1.".</t>
<t indent="0">This specification is in accordance with RFC 959, "F
ile 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/rfc4
235" quoteTitle="true" derivedAnchor="RFC4235">
<front>
<title>An INVITE-Initiated Dialog Event Package for the Session Init
iation 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 thi
s 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 i
n 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/rfc4
261" quoteTitle="true" derivedAnchor="RFC4261">
<front>
<title>Common Open Policy Service (COPS) Over Transport Layer Securi
ty (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 S
ecurity (TLS) to secure Common Open Policy Service (COPS) connections over the I
nternet.</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/rfc4
279" 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="ed
itor">
<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 ciphersuit
es for the Transport Layer Security (TLS) protocol to support authentication bas
ed 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-H
ellman exchange authenticated with a pre-shared key, and the third set combines
public key authentication of the server with pre-shared key authentication of th
e 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/rfc4
346" quoteTitle="true" derivedAnchor="RFC4346">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.1</titl
e>
<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 securi
ty over the Internet. The protocol allows client/server applications to communi
cate in a way that is designed to prevent eavesdropping, tampering, or message f
orgery.</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/rfc4
497" quoteTitle="true" derivedAnchor="RFC4497">
<front>
<title>Interworking between the Session Initiation Protocol (SIP) an
d 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 Ses
sion Initiation Protocol (SIP) and QSIG within corporate telecommunication netwo
rks (also known as enterprise networks). SIP is an Internet application-layer c
ontrol (signalling) protocol for creating, modifying, and terminating sessions w
ith one or more participants. These sessions include, in particular, telephone c
alls. QSIG is a signalling protocol for creating, modifying, and terminating ci
rcuit-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 C
urrent Practices for the Internet Community, and requests discussion and suggest
ions 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/rfc4
513" 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 s
ecurity mechanisms of the Lightweight Directory Access Protocol (LDAP). This doc
ument 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 t
he Simple Authentication and Security Layer (SASL) Bind authentication method in
cluding the EXTERNAL mechanism.</t>
<t indent="0">This document discusses various authentication and a
uthorization states through which a session to an LDAP server may pass and the a
ctions 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), ob
soletes 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/rfc4
531" 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 c
lient 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/rfc4
540" 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 m
iddleboxes such as firewalls and network address translators. It is a fully com
pliant implementation of the Middlebox Communications (MIDCOM) semantics describ
ed 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 r
equirements. This memo defines an Experimental Protocol for the Internet commun
ity.</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/rfc4
582" 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 exclusiv
e access to shared resources in a (multiparty) conferencing environment. Thereby
, floor control complements other functions -- such as conference and media sess
ion setup, conference policy manipulation, and media control -- that are realize
d by other protocols.</t>
<t indent="0">This document specifies the Binary Floor Control Pro
tocol (BFCP). BFCP is used between floor participants and floor control servers,
and between floor chairs (i.e., moderators) and floor control servers. [STANDA
RDS-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/rfc4
616" quoteTitle="true" derivedAnchor="RFC4616">
<front>
<title>The PLAIN Simple Authentication and Security Layer (SASL) Mec
hanism</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/passw
ord Simple Authentication and Security Layer (SASL) mechanism called the PLAIN m
echanism. The PLAIN mechanism is intended to be used, in combination with data
confidentiality services provided by a lower layer, in protocols that lack a sim
ple 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/rfc4
642" quoteTitle="true" derivedAnchor="RFC4642">
<front>
<title>Using Transport Layer Security (TLS) with Network News Transf
er 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 T
ransfer Protocol (NNTP) that allows an NNTP client and server to use Transport L
ayer 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. [STAN
DARDS-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/rfc4
680" 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 f
or exchange of supplemental application data. TLS hello message extensions are
used to determine which supplemental data types are supported by both the TLS cl
ient and the TLS server. Then, the supplemental data handshake message is used
to exchange the data. Other documents will define the syntax of these extension
s 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/rfc4
681" 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 mes
sage defined in RFC 4680. One such mapping hint is defined in an informative se
ction, the UpnDomainHint, which may be used by a server to locate a user in a di
rectory 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/rfc4
712" quoteTitle="true" derivedAnchor="RFC4712">
<front>
<title>Transport Mappings for Real-time Application Quality-of-Servi
ce 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 d
efined in RFC 4710 using TCP as a native transport and the Simple Network Manage
ment 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/rfc4
732" 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 avenu
es for denial-of-service (DoS) attack on Internet systems. The aim is to encour
age protocol designers and network engineers towards designs that are more robus
t. We discuss partial solutions that reduce the effectiveness of attacks, and h
ow 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/rfc4
743" 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 appl
icable 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 Ob
ject Access Protocol (SOAP). NETCONF finds many benefits in this environment: f
rom the reuse of existing standards, to ease of software development, to integra
tion with deployed systems. Herein, we describe SOAP over HTTP and SOAP over Bl
ocks 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/rfc4
744" quoteTitle="true" derivedAnchor="RFC4744">
<front>
<title>Using the NETCONF Protocol over the Blocks Extensible Exchang
e 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 mapp
ing 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/rfc4
785" quoteTitle="true" derivedAnchor="RFC4785">
<front>
<title>Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Tr
ansport 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 ciphersu
ites (with no encryption) for the Pre-Shared Key (PSK) based Transport Layer Sec
urity (TLS) protocol. These ciphersuites are useful when authentication and int
egrity 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/rfc4
791" 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. Desruissea
ux">
<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 Distribu
ted Authoring and Versioning (WebDAV) protocol to specify a standard way of acce
ssing, managing, and sharing calendaring and scheduling information based on the
iCalendar format. This document defines the "calendar-access" feature of CalDA
V. [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/rfc4
823" quoteTitle="true" derivedAnchor="RFC4823">
<front>
<title>FTP Transport for Secure Peer-to-Peer Business Data Interchan
ge 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 e
xchange structured business data securely using the File Transfer Protocol (FTP)
for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or
other data used for business-to-business data interchange for which MIME packag
ing can be accomplished using standard MIME content types. Authentication and da
ta confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) s
ecurity body parts. Authenticated acknowledgements employ multipart/signed repli
es to the original message. This memo provides information for the Internet com
munity.</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/rfc4
851" quoteTitle="true" derivedAnchor="RFC4851">
<front>
<title>The Flexible Authentication via Secure Tunneling Extensible A
uthentication 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) pro
tocol. EAP-FAST is an EAP method that enables secure communication between a pe
er and a server by using the Transport Layer Security (TLS) to establish a mutua
lly 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/rfc4
964" 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="edit
or">
<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 Pus
h 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 a
nswering 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/rfc4
975" 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 Pr
otocol, 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 In
itiation 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/rfc4
976" quoteTitle="true" derivedAnchor="RFC4976">
<front>
<title>Relay Extensions for the Message Sessions Relay Protocol (MSR
P)</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 h
ave been defined. Page-mode messages stand alone and are not part of a Session I
nitiation Protocol (SIP) session, whereas session-mode messages are set up as pa
rt of a session using SIP. The Message Session Relay Protocol (MSRP) is a proto
col for near real-time, peer-to-peer exchanges of binary content without interme
diaries, which is designed to be signaled using a separate rendezvous protocol s
uch 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/rfc4
992" quoteTitle="true" derivedAnchor="RFC4992">
<front>
<title>XML Pipelining with Chunks for the Internet Registry Informat
ion 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 protoc
ol for the Internet Registry Information Service (IRIS). Data is transferred be
tween 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/rfc5
018" 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 P
rotocol (BFCP) client establishes a connection to a BFCP floor control server ou
tside 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/rfc5
019" quoteTitle="true" derivedAnchor="RFC5019">
<front>
<title>The Lightweight Online Certificate Status Protocol (OCSP) Pro
file 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 C
ertificate Status Protocol (OCSP) that addresses the scalability issues inherent
when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) en
vironments and/or in PKI environments that require a lightweight solution to min
imize 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/rfc5
023" 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 applica
tion-level protocol for publishing and editing Web resources. The protocol is b
ased on HTTP transfer of Atom-formatted representations. The Atom format is doc
umented 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/rfc5
024" 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 c
ommunication over the Internet using Transport Layer Security, provides file enc
ryption, signing, and compression using Cryptographic Message Syntax, and provid
es signed receipts for the acknowledgement of received files.</t>
<t indent="0">The protocol supports both direct peer-to-peer commu
nication and indirect communication via a Value Added Network and may be used wi
th TCP/IP, X.25, and ISDN-based networks. This memo provides information for th
e 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/rfc5
049" quoteTitle="true" derivedAnchor="RFC5049">
<front>
<title>Applying Signaling Compression (SigComp) to the Session Initi
ation 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" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="December"/>
<abstract>
<t indent="0">This document describes some specifics that apply wh
en Signaling Compression (SigComp) is applied to the Session Initiation Protocol
(SIP), such as default minimum values of SigComp parameters, compartment and st
ate management, and a few issues on SigComp over TCP. Any implementation of Sig
Comp for use with SIP must conform to this document and SigComp, and in addition
, support the SIP and Session Description Protocol (SDP) static dictionary. [ST
ANDARDS-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/rfc5
054" quoteTitle="true" derivedAnchor="RFC5054">
<front>
<title>Using the Secure Remote Password (SRP) Protocol for TLS Authe
ntication</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. Mavro
giannopoulos">
<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 a technique for using the Secure
Remote Password protocol as an authentication method for the Transport Layer Sec
urity 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/rfc5
091" 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 implemen
t Boneh-Franklin (BF) and Boneh-Boyen (BB1) Identity-based Encryption. This doc
ument is in part based on IBCS #1 v2 of Voltage Security's Identity-based Crypto
graphy 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/rfc5
158" 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 enteri
ng a delegation of DNS servers that provide reverse lookup of 6to4 IPv6 addresse
s 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 r
everse delegation, the client is primarily authenticated by its source address u
sed 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 delegat
ion 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/rfc5
216" 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), define
d in RFC 3748, provides support for multiple authentication methods. Transport
Layer Security (TLS) provides for mutual authentication, integrity-protected cip
hersuite negotiation, and key exchange between two endpoints. This document def
ines 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. [STANDAR
DS-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/rfc5
238" quoteTitle="true" derivedAnchor="RFC5238">
<front>
<title>Datagram Transport Layer Security (DTLS) over the Datagram Co
ngestion 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 Transpor
t Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP). D
TLS 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. DCC
P is a transport protocol that provides a congestion-controlled unreliable datag
ram 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/rfc5
263" quoteTitle="true" derivedAnchor="RFC5263">
<front>
<title>Session Initiation Protocol (SIP) Extension for Partial Notif
ication 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-Req
uena">
<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 ev
ent package for the Session Initiation Protocol (SIP) is represented in the Pres
ence 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 conta
ining the full set of elements is delivered. This memo defines an extension all
owing 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/rfc5
281" quoteTitle="true" derivedAnchor="RFC5281">
<front>
<title>Extensible Authentication Protocol Tunneled Transport Layer S
ecurity 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-Wils
on">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="August"/>
<abstract>
<t indent="0">EAP-TTLS is an EAP (Extensible Authentication Protoc
ol) method that encapsulates a TLS (Transport Layer Security) session, consistin
g 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 cr
eate a cryptographically secure tunnel for information exchange in the subsequen
t data phase. During the data phase, the client is authenticated to the server
(or client and server are mutually authenticated) using an arbitrary authenticat
ion mechanism encapsulated within the secure tunnel. The encapsulated authentic
ation 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 passwor
d-based authentication protocols to be used against existing authentication data
bases, while protecting the security of these legacy protocols against eavesdrop
ping, 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 I
nternet 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/rfc5
364" quoteTitle="true" derivedAnchor="RFC5364">
<front>
<title>Extensible Markup Language (XML) Format Extension for Represe
nting Copy Control Attributes in Resource Lists</title>
<author initials="M." surname="Garcia-Martin" fullname="M. Garcia-Ma
rtin">
<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 Ses
sion Initiation Protocol (SIP) request is distributed to a group of SIP User Age
nts (UAs). The sender sends a single SIP request to a server which further dist
ributes the request to the group. This SIP request contains a list of Uniform R
esource Identifiers (URIs), which identify the recipients of the SIP request. T
his URI list is expressed as a resource list XML document. This specification d
efines an XML extension to the XML resource list format that allows the sender o
f the request to qualify a recipient with a copy control level similar to the co
py 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/rfc5
422" 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 Ext
ensible Authentication Protocol (EAP-FAST) method enables secure communication b
etween a peer and a server by using Transport Layer Security (TLS) to establish
a mutually authenticated tunnel. EAP- FAST also enables the provisioning creden
tials or other information through this protected tunnel. This document describ
es 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/rfc5
469" 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="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<date year="2009" month="February"/>
<abstract>
<t indent="0">Transport Layer Security (TLS) versions 1.0 (RFC 224
6) and 1.1 (RFC 4346) include cipher suites based on DES (Data Encryption Standa
rd) and IDEA (International Data Encryption Algorithm) algorithms. DES (when us
ed 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 specifie
s 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/rfc5
734" quoteTitle="true" derivedAnchor="RFC5734">
<front>
<title>Extensible Provisioning Protocol (EPP) Transport over TCP</ti
tle>
<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 Provisioni
ng Protocol (EPP) session is mapped onto a single Transmission Control Protocol
(TCP) connection. This mapping requires use of the Transport Layer Security (TL
S) protocol to protect information exchanged between an EPP client and an EPP se
rver. 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/rfc5
878" quoteTitle="true" derivedAnchor="RFC5878">
<front>
<title>Transport Layer Security (TLS) Authorization Extensions</titl
e>
<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 i
n 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 Secu
rity Assertion Markup Language (SAML) assertions, is exchanged in the supplemen
tal data handshake message. This document defines an Experimental Protocol for t
he 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/rfc5
953" 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 Si
mple Network Management Protocol (SNMP), that uses either the Transport Layer Se
curity protocol or the Datagram Transport Layer Security (DTLS) protocol. The T
LS and DTLS protocols provide authentication and privacy services for SNMP appli
cations. This document describes how the TLS Transport Model (TLSTM) implements
the needed features of a SNMP Transport Subsystem to make this protection possi
ble in an interoperable way.</t>
<t indent="0">This Transport Model is designed to meet the securit
y and operational needs of network administrators. It supports the sending of S
NMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's impr
oved support for larger packet sizes and the DTLS mode provides potentially supe
rior operation in environments where a connectionless (e.g., UDP) transport is p
referred. Both TLS and DTLS integrate well into existing public keying infrastr
uctures.</t>
<t indent="0">This document also defines a portion of the Manageme
nt Information Base (MIB) for use with network management protocols. In particu
lar, it defines objects for managing the TLS Transport Model for SNMP. [STANDA
RDS-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/rfc6
042" quoteTitle="true" derivedAnchor="RFC6042">
<front>
<title>Transport Layer Security (TLS) Authorization Using KeyNote</t
itle>
<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 carr
ied in the client and server hello messages confirm that both parties support th
e desired authorization data types. Then, if supported by both the client and t
he 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/rfc6
176" 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 Sec
urity (TLS) clients and servers establish connections, they never negotiate the
use of Secure Sockets Layer (SSL) version 2.0. This document updates the back
ward compatibility sections found in the Transport Layer Security (TLS). [STANDA
RDS-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/rfc6
353" 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 Si
mple Network Management Protocol (SNMP), that uses either the Transport Layer Se
curity protocol or the Datagram Transport Layer Security (DTLS) protocol. The T
LS and DTLS protocols provide authentication and privacy services for SNMP appli
cations. This document describes how the TLS Transport Model (TLSTM) implements
the needed features of an SNMP Transport Subsystem to make this protection poss
ible in an interoperable way.</t>
<t indent="0">This Transport Model is designed to meet the securit
y and operational needs of network administrators. It supports the sending of S
NMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's impr
oved support for larger packet sizes and the DTLS mode provides potentially supe
rior operation in environments where a connectionless (e.g., UDP) transport is p
referred. Both TLS and DTLS integrate well into existing public keying infrastr
uctures.</t>
<t indent="0">This document also defines a portion of the Manageme
nt Information Base (MIB) for use with network management protocols. In particu
lar, it defines objects for managing the TLS Transport Model for SNMP. [STANDAR
DS-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/rfc6
367" quoteTitle="true" derivedAnchor="RFC6367">
<front>
<title>Addition of the Camellia Cipher Suites to Transport Layer Sec
urity (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 a
lgorithm as a block cipher. This document is not an Internet Standards Track s
pecification; 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/rfc6
739" 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 l
ocation information to service URIs and service boundaries. In particular, it c
an 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 spe
cification encapsulates information about service boundaries and circumscribes t
he region within which all locations map to the same service Uniform Resource Id
entifier (URI) or set of URIs for a given service.</t>
<t indent="0">This document defines an XML protocol to exchange th
ese 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 L
oST specification, the mechanism in this document can be used without the LoST p
rotocol. This document defines an Experimental Protocol for the Internet commu
nity.</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/rfc6
749" quoteTitle="true" derivedAnchor="RFC6749">
<front>
<title>The OAuth 2.0 Authorization Framework</title>
<author initials="D." surname="Hardt" fullname="D. Hardt" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="October"/>
<abstract>
<t indent="0">The OAuth 2.0 authorization framework enables a thir
d-party application to obtain limited access to an HTTP service, either on behal
f of a resource owner by orchestrating an approval interaction between the resou
rce owner and the HTTP service, or by allowing the third-party application to ob
tain access on its own behalf. This specification replaces and obsoletes the OA
uth 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/rfc6
750" quoteTitle="true" derivedAnchor="RFC6750">
<front>
<title>The OAuth 2.0 Authorization Framework: Bearer Token Usage</ti
tle>
<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 token
s in HTTP requests to access OAuth 2.0 protected resources. Any party in posses
sion of a bearer token (a "bearer") can use it to get access to the associated r
esources (without demonstrating possession of a cryptographic key). To prevent
misuse, bearer tokens need to be protected from disclosure in storage and in tra
nsport. [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/rfc7
030" 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 cl
ients using Certificate Management over CMS (CMC) messages over a secure transpo
rt. This profile, called Enrollment over Secure Transport (EST), describes a si
mple, yet functional, certificate management protocol targeting Public Key Infra
structure (PKI) clients that need to acquire client certificates and associated
Certification Authority (CA) certificates. It also supports client-generated pu
blic/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/rfc7
465" 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 the
y establish connections. This applies to all TLS versions. This document updat
es 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/rfc7
507" quoteTitle="true" derivedAnchor="RFC7507">
<front>
<title>TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventi
ng 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/rfc7
525" quoteTitle="true" derivedAnchor="RFC7525">
<front>
<title>Recommendations for Secure Use of Transport Layer Security (T
LS) 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 Transpor
t Layer Security (DTLS) are widely used to protect data exchanged over applicati
on protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few ye
ars, several serious attacks on TLS have emerged, including attacks on its most
commonly used cipher suites and their modes of operation. This document provide
s recommendations for improving the security of deployed services that use TLS a
nd 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/rfc7
562" quoteTitle="true" derivedAnchor="RFC7562">
<front>
<title>Transport Layer Security (TLS) Authorization Using Digital Tr
ansmission 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 Transmiss
ion Content Protection (DTCP) certificates as an authorization data type in the
authorization extension for the Transport Layer Security (TLS) protocol. This i
s in accordance with the guidelines for authorization extensions as specified in
RFC 5878. As with other TLS extensions, this authorization data can be include
d in the client and server hello messages to confirm that both parties support t
he desired authorization data types. If supported by both the client and the se
rver, DTCP certificates are exchanged in the supplemental data TLS handshake mes
sage as specified in RFC 4680. This authorization data type extension is in sup
port 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/rfc7
568" 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 spe
cified in RFC 6101, is not sufficiently secure. This document requires that SSL
v3 not be used. The replacement versions, in particular, Transport Layer Securi
ty (TLS) 1.2 (RFC 5246), are considerably more secure and capable protocols.</t>
<t indent="0">This document updates the backward compatibility sec
tion 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/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<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 cla
rifying that only UPPERCASE usage of the key words have the defined special mea
nings.</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/rfc8
422" 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. Pegour
ie-Gonnard">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="August"/>
<abstract>
<t indent="0">This document describes key exchange algorithms base
d on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) pr
otocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-
Hellman (ECDHE) key agreement in a TLS handshake and the use of the Elliptic Cur
ve Digital Signature Algorithm (ECDSA) and Edwards-curve Digital Signature Algor
ithm (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/download
s/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="Bhar
gavan">
<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/nistpu
bs/SpecialPublications/NIST.SP.800-52r2.pdf" quoteTitle="true" derivedAnchor="NI
ST800-52r2">
<front>
<title>Guidelines for the Selection, Configuration, and Use of Trans
port Layer Security (TLS) Implementations NIST SP800-52r2</title>
<author>
<organization showOnFrontPage="true">National Institute of Standar
ds 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/rfc3
316" 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/rfc3
489" quoteTitle="true" derivedAnchor="RFC3489">
<front>
<title>STUN - Simple Traversal of User Datagram Protocol (UDP) Throu
gh 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) Thr
ough Network Address Translators (NATs) (STUN) is a lightweight protocol that al
lows applications to discover the presence and types of NATs and firewalls betwe
en them and the public Internet. It also provides the ability for applications
to determine the public Internet Protocol (IP) addresses allocated to them by th
e NAT. STUN works with many existing NATs, and does not require any special beh
avior from them. As a result, it allows a wide variety of 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/rfc3
546" quoteTitle="true" derivedAnchor="RFC3546">
<front>
<title>Transport Layer Security (TLS) Extensions</title>
<author initials="S." surname="Blake-Wilson" fullname="S. Blake-Wils
on">
<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 generi
c extension mechanisms for the TLS handshake client and server hellos, and speci
fic extensions using these generic mechanisms. The extensions may be used by TLS
clients and servers. The extensions are backwards compatible - communication i
s possible between TLS 1.0 clients that support the extensions and TLS 1.0 serve
rs 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/rfc3
588" 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 s
uch as network access or IP mobility. Diameter is also intended to work in both
local Authentication, Authorization &amp; Accounting and roaming situations. T
his document specifies the message format, transport, error reporting, accountin
g and security services to be used by all Diameter applications. The Diameter b
ase application needs to be supported by all Diameter implementations. [STANDAR
DS-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/rfc3
734" quoteTitle="true" derivedAnchor="RFC3734">
<front>
<title>Extensible Provisioning Protocol (EPP) Transport Over TCP</ti
tle>
<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 Provisioni
ng Protocol (EPP) session is mapped onto a single Transmission Control Protocol
(TCP) connection. This mapping requires use of the Transport Layer Security (TL
S) protocol to protect information exchanged between an EPP client and an EPP se
rver. [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/rfc3
920" quoteTitle="true" derivedAnchor="RFC3920">
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</titl
e>
<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 Extensibl
e Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Ma
rkup Language (XML) elements in order to exchange structured information in clos
e to real time between any two network endpoints. While XMPP provides a general
ized, extensible framework for exchanging XML data, it is used mainly for the pu
rpose of building instant messaging and presence applications that meet the requ
irements 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/rfc4
132" quoteTitle="true" derivedAnchor="RFC4132">
<front>
<title>Addition of Camellia Cipher Suites to Transport Layer Securit
y (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 su
ites to the Transport Layer Security (TLS) protocol to support the Camellia encr
yption 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/rfc4
244" quoteTitle="true" derivedAnchor="RFC4244">
<front>
<title>An Extension to the Session Initiation Protocol (SIP) for Req
uest History Information</title>
<author initials="M." surname="Barnes" fullname="M. Barnes" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<date year="2005" month="November"/>
<abstract>
<t indent="0">This document defines a standard mechanism for captu
ring the history information associated with a Session Initiation Protocol (SIP)
request. This capability enables many enhanced services by providing the infor
mation 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 his
tory 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/rfc4
347" 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 communicat
ions privacy for datagram protocols. The protocol allows client/server applicat
ions to communicate in a way that is designed to prevent eavesdropping, tamperin
g, or message forgery. The DTLS protocol is based on the Transport Layer Securi
ty (TLS) protocol and provides equivalent security guarantees. Datagram semanti
cs of the underlying transport are preserved by the DTLS protocol.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4347"/>
<seriesInfo name="DOI" value="10.17487/RFC4347"/>
</reference>
<reference anchor="RFC4366" target="https://www.rfc-editor.org/info/rfc4
366" quoteTitle="true" derivedAnchor="RFC4366">
<front>
<title>Transport Layer Security (TLS) Extensions</title>
<author initials="S." surname="Blake-Wilson" fullname="S. Blake-Wils
on">
<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 add functionality to Transport Layer Security (TLS). It provides both generi
c extension mechanisms for the TLS handshake client and server hellos, and speci
fic extensions using these generic mechanisms.</t>
<t indent="0">The extensions may be used by TLS clients and server
s. The extensions are backwards compatible: communication is possible between T
LS clients that support the extensions and TLS servers that do not support the e
xtensions, 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/rfc4
492" 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-Wils
on">
<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 the Transport Layer Security (TLS
) protocol. In particular, it specifies the use of Elliptic Curve Diffie-Hellma
n (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital
Signature Algorithm (ECDSA) as a new authentication mechanism. This memo provid
es information for the 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/rfc4
507" quoteTitle="true" derivedAnchor="RFC4507">
<front>
<title>Transport Layer Security (TLS) Session Resumption without Ser
ver-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 resume sessions and avoid keeping \%pe
r-client session state. The TLS server encapsulates the session state into a ti
cket and forwards it to the client. The client can subsequently resume a sessio
n 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/rfc4
572" 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 establish secure conn
ection-oriented media transport sessions over the Transport Layer Security (TLS)
protocol using the Session Description Protocol (SDP). It defines a new SDP pr
otocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an S
DP 'fingerprint' attribute that identifies the certificate that will be presente
d for the TLS session. This mechanism allows media transport over TLS connectio
ns to be established securely, so long as the integrity of session descriptions
is assured.</t>
<t indent="0">This document extends and updates RFC 4145. [STANDA
RDS-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/rfc4
934" quoteTitle="true" derivedAnchor="RFC4934">
<front>
<title>Extensible Provisioning Protocol (EPP) Transport Over TCP</ti
tle>
<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 Provisioni
ng Protocol (EPP) session is mapped onto a single Transmission Control Protocol
(TCP) connection. This mapping requires use of the Transport Layer Security (TL
S) protocol to protect information exchanged between an EPP client and an EPP se
rver. 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/rfc5
077" quoteTitle="true" derivedAnchor="RFC5077">
<front>
<title>Transport Layer Security (TLS) Session Resumption without Ser
ver-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 mechanism that enables the
Transport Layer Security (TLS) server to resume sessions and avoid keeping per-
client session state. The TLS server encapsulates the session state into a tick
et and forwards it to the client. The client can subsequently resume a session
using the obtained ticket. This document obsoletes RFC 4507. [STANDARDS-TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5077"/>
<seriesInfo name="DOI" value="10.17487/RFC5077"/>
</reference>
<reference anchor="RFC5081" target="https://www.rfc-editor.org/info/rfc5
081" quoteTitle="true" derivedAnchor="RFC5081">
<front>
<title>Using OpenPGP Keys for Transport Layer Security (TLS) Authent
ication</title>
<author initials="N." surname="Mavrogiannopoulos" fullname="N. Mavro
giannopoulos">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="November"/>
<abstract>
<t indent="0">This memo proposes extensions to the Transport Layer
Security (TLS) protocol to support the OpenPGP key format. The extensions disc
ussed here include a certificate type negotiation mechanism, and the required mo
difications to the TLS Handshake Protocol. This memo defines an Experimental Pr
otocol for the 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/rfc5
101" quoteTitle="true" derivedAnchor="RFC5101">
<front>
<title>Specification of the IP Flow Information Export (IPFIX) Proto
col for the Exchange of IP Traffic Flow Information</title>
<author initials="B." surname="Claise" fullname="B. Claise" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="January"/>
<abstract>
<t indent="0">This document specifies the IP Flow Information Expo
rt (IPFIX) protocol that serves for transmitting IP Traffic Flow information ove
r the network. In order to transmit IP Traffic Flow information from an Exporti
ng Process to an information Collecting Process, a common representation of flow
data and a standard means of communicating them is required. This document des
cribes how the IPFIX Data and Template Records are carried over a number of tran
sport 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/rfc5
246" quoteTitle="true" derivedAnchor="RFC5246">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</titl
e>
<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 (TLS) protocol. The TLS protocol provides communications securi
ty over the Internet. The protocol allows client/server applications to communi
cate in a way that is designed to prevent eavesdropping, tampering, or message f
orgery. [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/rfc5
415" quoteTitle="true" derivedAnchor="RFC5415">
<front>
<title>Control And Provisioning of Wireless Access Points (CAPWAP) P
rotocol 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 Provision
ing of Wireless Access Points (CAPWAP) Protocol, meeting the objectives defined
by the CAPWAP Working Group in RFC 4564. The CAPWAP protocol is designed to be
flexible, allowing it to be used for a variety of wireless technologies. This d
ocument describes the base CAPWAP protocol, while separate binding extensions wi
ll enable its 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/rfc5
456" 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 Inter-Asterisk eXch
ange protocol, an application-layer control and media protocol for creating, mod
ifying, and terminating multimedia sessions over Internet Protocol (IP) networks
. IAX was developed by the open source community for the Asterisk Private Branc
h 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 mul
timedia.</t>
<t indent="0">IAX is an "all in one" protocol for handling multime
dia in IP networks. It combines both control and media services in the same pro
tocol. 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 work around NAT, and simplifying network and firewa
ll management. IAX employs a compact encoding that decreases bandwidth usage an
d is well suited for Internet telephony service. In addition, its open nature p
ermits new payload type additions needed to support additional services. This
document is not an Internet Standards Track specification; it is published for i
nformational 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/rfc6
012" quoteTitle="true" derivedAnchor="RFC6012">
<front>
<title>Datagram Transport Layer Security (DTLS) Transport Mapping fo
r 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 describes the transport of syslog mess
ages over the Datagram Transport Layer Security (DTLS) protocol. It provides a
secure transport for syslog messages in cases where a connectionless transport i
s 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/rfc6
083" quoteTitle="true" derivedAnchor="RFC6083">
<front>
<title>Datagram Transport Layer Security (DTLS) for Stream Control T
ransmission 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 usage of the Datagram Tr
ansport Layer Security (DTLS) protocol over the Stream Control Transmission Prot
ocol (SCTP).</t>
<t indent="0">DTLS over SCTP provides communications privacy for a
pplications that use SCTP as their transport protocol and allows client/server a
pplications to communicate in a way that is designed to prevent eavesdropping an
d detect tampering or message forgery.</t>
<t indent="0">Applications using DTLS over SCTP can use almost all
transport features provided by SCTP and 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/rfc6
084" quoteTitle="true" derivedAnchor="RFC6084">
<front>
<title>General Internet Signaling Transport (GIST) over Stream Contr
ol Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS)</ti
tle>
<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) prot
ocol currently uses TCP or Transport Layer Security (TLS) over TCP for Connectio
n mode operation. This document describes the usage of GIST over the Stream Con
trol Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS).
This document defines an Experimental Protocol for the 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/rfc6
347" 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 specifies version 1.2 of the Datagram
Transport Layer Security (DTLS) protocol. The DTLS protocol provides communicat
ions privacy for datagram protocols. The protocol allows client/server applicat
ions to communicate in a way that is designed to prevent eavesdropping, tamperin
g, or message forgery. The DTLS protocol is based on the Transport Layer Securi
ty (TLS) protocol and provides equivalent security guarantees. Datagram semanti
cs of the underlying transport are preserved by the DTLS protocol. This documen
t updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6347"/>
<seriesInfo name="DOI" value="10.17487/RFC6347"/>
</reference>
<reference anchor="RFC6460" target="https://www.rfc-editor.org/info/rfc6
460" quoteTitle="true" derivedAnchor="RFC6460">
<front>
<title>Suite B Profile for Transport Layer Security (TLS)</title>
<author initials="M." surname="Salter" fullname="M. Salter">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="January"/>
<abstract>
<t indent="0">The United States government has published guideline
s for "NSA Suite B Cryptography" that define cryptographic algorithm policy for
national security applications. This document defines a profile of Transport La
yer Security (TLS) version 1.2 that is fully compliant with Suite B. This docum
ent is not an Internet Standards Track specification; it is published for infor
mational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6460"/>
<seriesInfo name="DOI" value="10.17487/RFC6460"/>
</reference>
<reference anchor="RFC6614" target="https://www.rfc-editor.org/info/rfc6
614" quoteTitle="true" derivedAnchor="RFC6614">
<front>
<title>Transport Layer Security (TLS) Encryption for RADIUS</title>
<author initials="S." surname="Winter" fullname="S. Winter">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="McCauley" fullname="M. McCauley">
<organization showOnFrontPage="true"/>
</author>
<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 year="2012" month="May"/>
<abstract>
<t indent="0">This document specifies a transport profile for RADI
US 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="RFC7457" target="https://www.rfc-editor.org/info/rfc7
457" quoteTitle="true" derivedAnchor="RFC7457">
<front>
<title>Summarizing Known Attacks on Transport Layer Security (TLS) a
nd Datagram TLS (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="February"/>
<abstract>
<t indent="0">Over the last few years, there have been several ser
ious attacks on Transport Layer Security (TLS), including attacks on its most co
mmonly used ciphers and modes of operation. This document summarizes these atta
cks, with the goal of motivating generic and protocol-specific recommendations o
n the usage of TLS and Datagram TLS (DTLS).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7457"/>
<seriesInfo name="DOI" value="10.17487/RFC7457"/>
</reference>
<reference anchor="RFC8143" target="https://www.rfc-editor.org/info/rfc8
143" quoteTitle="true" derivedAnchor="RFC8143">
<front>
<title>Using Transport Layer Security (TLS) with Network News Transf
er Protocol (NNTP)</title>
<author initials="J." surname="Elie" fullname="J. Elie">
<organization showOnFrontPage="true"/>
</author>
<date 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="RFC8261" target="https://www.rfc-editor.org/info/rfc8
261" quoteTitle="true" derivedAnchor="RFC8261">
<front>
<title>Datagram Transport Layer Security (DTLS) Encapsulation of SCT
P Packets</title>
<author initials="M." surname="Tuexen" fullname="M. Tuexen">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Stewart" fullname="R. Stewart">
<organization showOnFrontPage="true"/>
</author>
<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" month="November"/>
<abstract>
<t indent="0">The Stream Control Transmission Protocol (SCTP) is a
transport protocol originally defined to run on top of the network protocols IP
v4 or IPv6. This document specifies how SCTP can be used on top of the Datagram
Transport Layer Security (DTLS) protocol. Using the encapsulation method descr
ibed in this document, SCTP is unaware of the protocols being used below DTLS; h
ence, explicit IP addresses cannot be used in the SCTP control chunks. As a con
sequence, 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="RFC8446" target="https://www.rfc-editor.org/info/rfc8
446" quoteTitle="true" derivedAnchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<date 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 commun
icate over the Internet in a way that is designed to prevent eavesdropping, tamp
ering, and message forgery.</t>
<t indent="0">This document updates RFCs 5705 and 6066, and obsole
tes RFCs 5077, 5246, and 6961. This document also specifies new requirements fo
r TLS 1.2 implementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC8447" target="https://www.rfc-editor.org/info/rfc8
447" quoteTitle="true" derivedAnchor="RFC8447">
<front>
<title>IANA Registry Updates for TLS and DTLS</title>
<author initials="J." surname="Salowey" fullname="J. Salowey">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Turner" fullname="S. Turner">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="August"/>
<abstract>
<t indent="0">This document describes a number of changes to TLS a
nd DTLS IANA registries that range from adding notes to the registry all the way
to changing the registration policy. These changes were mostly motivated by WG
review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.
3 development process.</t>
<t indent="0">This document updates the following RFCs: 3749, 5077
, 4680, 5246, 5705, 5878, 6520, and 7301.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8447"/>
<seriesInfo name="DOI" value="10.17487/RFC8447"/>
</reference>
</references>
</references> </references>
<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
<section title="Change Log "> ndix.a">
<t>[[RFC editor: please remove this before publication.]]</t> <name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t indent="0" pn="section-appendix.a-1">Thanks to those that provided usag
<t>From draft-ietf-tls-oldversions-deprecate-11 to e data and reviewed and/or improved
draft-ietf-tls-oldversions-deprecate-12 (IESG review): this document, including: <contact fullname="Michael Ackermann"/>, <co
<list style="symbols"> ntact fullname="David Benjamin"/>, <contact fullname="David Black"/>,
<t>Minor edits from IESG review comments.</t> <contact fullname="Deborah Brungard"/>, <contact fullname="Alan DeKok"/>
</list></t> , <contact fullname="Viktor Dukhovni"/>, <contact fullname="Julien Élie"/>,
<contact fullname="Adrian Farrelll"/>, <contact fullname="Gary Gapinski"
<t>From draft-ietf-tls-oldversions-deprecate-10 to />, <contact fullname="Alessandro Ghedini"/>, <contact fullname="Peter G
draft-ietf-tls-oldversions-deprecate-11: utmann"/>, <contact fullname="Jeremy Harris"/>, <contact fullname="Nick Hilliard
<list style="symbols"> "/>,
<t>RFC 5953 was mentioned in the wrong para of section 1.1 - it has been <contact fullname="James Hodgkinson"/>, <contact fullname="Russ Housley"/
obsoleted already.</t> >, <contact fullname="Hubert Kario"/>, <contact fullname="Benjamin Kaduk"/>, <co
</list> ntact 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"/>, <cont
act fullname="Yoav Nir"/>, <contact fullname="Andrei Popov"/>, <contact fullnam
e="Michael Richardson"/>, <contact fullname="Eric Rescorla"/>, <contact
fullname="Rich Salz"/>, <contact fullname="Mohit Sethi"/>, <contact fullname="Ya
ron 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 Wil
k"/>, and <contact fullname="Christopher Wood"/>.
</t> </t>
</section>
<t>From draft-ietf-tls-oldversions-deprecate-09 to <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
draft-ietf-tls-oldversions-deprecate-10: ="include" pn="section-appendix.b">
<list style="symbols"> <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<t>We missed adding change logs for a few versions, but <author fullname="Kathleen Moriarty" initials="K" surname="Moriarty">
since -09 was the one that underwent IETF last call, <organization abbrev="CIS" showOnFrontPage="true">Center for Internet Se
and there was some discussion, we figured it'd be good curity (CIS)</organization>
to mention substantive changes here.</t> <address>
<t>Added Ben's suggested text for "operational <postal>
considerations" following extensive last call <street/>
discussion.</t> <city>East Greenbush</city>
<t>Re-checked the references to RFC 4347 after Tom Petch <region>NY</region>
noticed we missed a couple. Added RFCs 5953 and 6353 to <country>United States of America</country>
the list here. All others were in already.</t> </postal>
<t>Fixed various typos and ack'd those who engaged a bit <email>Kathleen.Moriarty.ietf@gmail.com</email>
in the IETF LC discussion. (If we missed you and you want to be </address>
added, </author>
or if you'd rather not be mentioned, just ping the authors.) </t <author fullname="Stephen Farrell" initials="S." surname="Farrell">
> <organization showOnFrontPage="true">Trinity College Dublin</organizatio
</list></t> n>
<address>
<t>From draft-ietf-tls-oldversions-deprecate-05 to <postal>
draft-ietf-tls-oldversions-deprecate-06: <list style="symbols"> <street/>
<city>Dublin</city>
<t>Fixed "yaleman" ack.</t> <region/>
<t>Added RFC6614 to UPDATEs list.</t> <code>2</code>
<t>per preliminary AD review: <country>Ireland</country>
<list style="symbols"> </postal>
<t>Remove references from abstract</t> <phone>+353-1-896-2354</phone>
<t>s/primary technical reasons/technical reasons/</t> <email>stephen.farrell@cs.tcd.ie</email>
<t>Add rfc7030 to 1.1</t> </address>
<t>verified that all the RFCs in the (massive:-) Updates meta- </author>
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, and Germany. NIST documentation rationale remains 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 of referenced RFCs in <xref
target="updates"/> aren't informatively refering to tls1.0/1.1</t>
<t>Remove RFC7255 from 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 and aren't
OBSOLETEd</t>
<t>Added note about RFC8261 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 and similar: so far just #1</t>
<t>PR#2 noting msft browser announced deprecation (but 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/nonobsn
orms.sh</t>
<t>Removed the 'measurements' part</t>
<t>Removed SHA-1 deprecation (section 8 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>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 87 change blocks. 
1611 lines changed or deleted 3740 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/