rfc8997xml2.original.xml		rfc8997.xml
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
	<rfc ipr="trust200902" category="std" updates="8314" docName="draft-ietf-uta-tls		nsus="true" docName="draft-ietf-uta-tls-for-email-05" indexInclude="true" ipr="t
	-for-email-05">		rust200902" number="8997" prepTime="2021-03-22T15:07:13" scripts="Common,Latin"
	<?rfc toc="yes"?>		sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="tr
	<?rfc symrefs="yes"?>		ue" updates="8314" xml:lang="en">
	<?rfc sortrefs="yes"?>		<link href="https://datatracker.ietf.org/doc/draft-ietf-uta-tls-for-email-05"
	<?rfc compact="yes"?>		rel="prev"/>
	<?rfc subcompact="no"?>		<link href="https://dx.doi.org/10.17487/rfc8997" rel="alternate"/>
	<?rfc private=""?>		<link href="urn:issn:2070-1721" rel="alternate"/>
	<?rfc topblock="yes"?>		<front>
	<?rfc comments="no"?>		<title abbrev="TLS For Email">Deprecation of TLS 1.1 for Email Submission an
	<front>		d Access</title>
	<title abbrev="TLS For Email ">Deprecation of use of TLS 1.1 for Email Submissio		<seriesInfo name="RFC" value="8997" stream="IETF"/>
	n and Access</title>		<author initials="L." surname="Velvindron" fullname="Loganaden Velvindron">
			<organization showOnFrontPage="true">cyberstorm.mu</organization>
	<author initials="L." surname="Velvindron" fullname="Loganaden Velvindron">		<address>
	<organization>cyberstorm.mu</organization>		<postal>
	<address>		<street>88 Avenue De Plevitz Roches Brunes</street>
	<postal>		<city>Rose Hill</city>
	<street>88 Avenue De Plevitz Roches Brunes</street>		<code>71259</code>
	<city>Rose Hill</city>		<country>Mauritius</country>
	<code>71259</code>		</postal>
	<country>Mauritius</country>		<phone>+230 59762817</phone>
	</postal>		<email>logan@cyberstorm.mu</email>
	<phone>+230 59762817</phone>		<uri/>
	<email>logan@cyberstorm.mu</email>		</address>
	<uri></uri>		</author>
	</address>
	</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="2020" month="March" day="24"/>		<area>Internet</area>
			<workgroup/>
	<area>Internet</area>		<abstract pn="section-abstract">
	<workgroup></workgroup>		<t indent="0" pn="section-abstract-1">This specification updates the curre
	<keyword></keyword>		nt recommendation for the use of
			the Transport Layer Security (TLS) protocol to provide confidentiality of email
	<abstract>
	<t>This specification updates current recommendation for the use of
	Transport Layer Security (TLS) protocol to provide confidentiality of email
	between a Mail User Agent (MUA) and a Mail Submission Server or Mail Access		between a Mail User Agent (MUA) and a Mail Submission Server or Mail Access
	Server. This document updates RFC8314.		Server. This document updates RFC 8314.</t>
	</t>		</abstract>
	</abstract>		<boilerplate>
			<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
	</front>		"exclude" pn="section-boilerplate.1">
			<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
	<middle>		>
			<t indent="0" pn="section-boilerplate.1-1">
	<section anchor="introduction" title="Introduction">		This is an Internet Standards Track document.
	<t><xref target="RFC8314"/> defines the minimum recommended version for TLS as		</t>
	version 1.1.		<t indent="0" pn="section-boilerplate.1-2">
	Due to the deprecation of TLS 1.1 in <xref target="I-D.ietf-tls-oldversions-depr		This document is a product of the Internet Engineering Task Force
	ecate"></xref>,		(IETF). It represents the consensus of the IETF community. It has
	this recommendation is no longer valid. Therefore this document updates <xref ta		received public review and has been approved for publication by
	rget="RFC8314"/>		the Internet Engineering Steering Group (IESG). Further
	so that the minimum version for TLS is TLS 1.2.		information on Internet Standards is available in Section 2 of
	</t>		RFC 7841.
	</section>		</t>
			<t indent="0" pn="section-boilerplate.1-3">
	<section title="Conventions Used in This Document">		Information about the current status of this document, any
	<t>		errata, and how to provide feedback on it may be obtained at
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		<eref target="https://www.rfc-editor.org/info/rfc8997" brackets="non
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		e"/>.
	document are to be interpreted as described in <xref target="RFC2119"/>		</t>
	when they		</section>
	appear in ALL CAPS. These words may also appear in this document in		<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
	lower case as plain English words, absent their normative meanings.		ude" pn="section-boilerplate.2">
	</t>		<name slugifiedName="name-copyright-notice">Copyright Notice</name>
	</section>		<t indent="0" pn="section-boilerplate.2-1">
			Copyright (c) 2021 IETF Trust and the persons identified as the
	<section anchor="update" title="Updates to RFC8314">		document authors. All rights reserved.
	<t>OLD: </t>		</t>
	<t>"4.1. Deprecation of Services Using Cleartext and TLS Versions Less Than 1.1		<t indent="0" pn="section-boilerplate.2-2">
	"</t>		This document is subject to BCP 78 and the IETF Trust's Legal
	<t>NEW:</t>		Provisions Relating to IETF Documents
	<t>"4.1. Deprecation of Services Using Cleartext and TLS Versions Less Than 1.2"		(<eref target="https://trustee.ietf.org/license-info" brackets="none
	</t>		"/>) in effect on the date of
	<t>OLD:</t>		publication of this document. Please review these documents
	<t>		carefully, as they describe your rights and restrictions with
	"As soon as practicable, MSPs currently supporting Secure Sockets		respect to this document. Code Components extracted from this
	Layer (SSL) 2.x, SSL 3.0, or TLS 1.0 SHOULD transition their users		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>
			</li>
			<li pn="section-toc.1-1.2">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
			ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
			derivedContent="" format="title" sectionFormat="of" target="name-conventions-us
			ed-in-this-do">Conventions Used in This Document</xref></t>
			</li>
			<li pn="section-toc.1-1.3">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref der
			ivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref
			derivedContent="" format="title" sectionFormat="of" target="name-updates-to-rfc
			-8314">Updates to RFC 8314</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-iana-considerations">IANA Consider
			ations</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-security-considerations">Security
			Considerations</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-references">References</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.6.2">
			<li pn="section-toc.1-1.6.2.1">
			<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
			"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-normative-references">
			Normative References</xref></t>
			</li>
			<li pn="section-toc.1-1.6.2.2">
			<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
			"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-informative-references
			">Informative References</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.7">
			<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="" forma
			t="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent=""
			format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgemen
			ts</xref></t>
			</li>
			<li pn="section-toc.1-1.8">
			<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" forma
			t="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent=""
			format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addr
			esses</xref></t>
			</li>
			</ul>
			</section>
			</toc>
			</front>
			<middle>
			<section anchor="introduction" numbered="true" toc="include" removeInRFC="fa
			lse" pn="section-1">
			<name slugifiedName="name-introduction">Introduction</name>
			<t indent="0" pn="section-1-1"><xref target="RFC8314" format="default" sec
			tionFormat="of" derivedContent="RFC8314"/> defines the minimum
			recommended version of TLS as version 1.1. Due to the deprecation of
			TLS 1.1 in <xref target="RFC8996" format="default" sectionFormat="of" deri
			vedContent="RFC8996"/>, this recommendation is no longer valid. Therefore,
			this document updates <xref target="RFC8314" format="default" sectionForma
			t="of" derivedContent="RFC8314"/> so that
			the minimum version for TLS is TLS 1.2.</t>
			</section>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-2">
			<name slugifiedName="name-conventions-used-in-this-do">Conventions Used in
			This Document</name>
			<t indent="0" pn="section-2-1">
			The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
			IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
			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 anchor="update" numbered="true" toc="include" removeInRFC="false" p
			n="section-3">
			<name slugifiedName="name-updates-to-rfc-8314">Updates to RFC 8314</name>
			<t indent="0" pn="section-3-1">OLD:</t>
			<blockquote pn="section-3-2">4.1. Deprecation of Services Using Cleartext
			and TLS Versions Less
			Than 1.1</blockquote>
			<t indent="0" pn="section-3-3">NEW:</t>
			<blockquote pn="section-3-4">4.1. Deprecation of Services Using Cleartext
			and TLS Versions Less
			Than 1.2</blockquote>
			<t indent="0" pn="section-3-5">OLD:</t>
			<blockquote pn="section-3-6">As soon as practicable, MSPs currently suppor
			ting Secure Sockets
			Layer (SSL) 2.x, SSL 3.0, or TLS 1.0 <bcp14>SHOULD</bcp14> transition thei
			r users
	to TLS 1.1 or later and discontinue support for those earlier		to TLS 1.1 or later and discontinue support for those earlier
	versions of SSL and TLS."		versions of SSL and TLS.</blockquote>
	</t>		<t indent="0" pn="section-3-7">NEW:</t>
	<t>NEW:</t>		<blockquote pn="section-3-8">As soon as practicable, MSPs currently suppor
	<t>		ting Secure
	"As soon as practicable, MSPs currently supporting Secure Sockets		Sockets Layer (SSL) 2.x, SSL 3.0, TLS 1.0, or TLS 1.1
	Layer (SSL) 2.x, SSL 3.0, TLS 1.0 or TLS 1.1 SHOULD transition their users		<bcp14>SHOULD</bcp14> transition their users to TLS 1.2 or later and
	to TLS 1.2 or later and discontinue support for those earlier		discontinue support for those earlier versions of SSL and
	versions of SSL and TLS."		TLS.</blockquote>
	</t>		<t indent="0" pn="section-3-9">In <xref target="RFC8314" sectionFormat="of
	<t>		" section="4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8314
	In Section 4.1, the text should be revised from:		#section-4.1" derivedContent="RFC8314"/>, the
	</t>		text should be revised from:</t>
	<t> OLD:</t>		<t indent="0" pn="section-3-10"> OLD:</t>
	<t>		<blockquote pn="section-3-11">One way is for the server to
	One way is for the server to
	refuse a ClientHello message from any client sending a		refuse a ClientHello message from any client sending a
	ClientHello.version field corresponding to any version of SSL or		ClientHello.version field corresponding to any version of SSL or
	TLS 1.0.		TLS 1.0.</blockquote>
	</t>		<t indent="0" pn="section-3-12">NEW:</t>
	<t>NEW:</t>		<blockquote pn="section-3-13">
	<t>
	One way is for the server to		One way is for the server to
	refuse a ClientHello message from any client sending a		refuse a ClientHello message from any client sending a
	ClientHello.version field corresponding to any version of SSL or		ClientHello.version field corresponding to any version of SSL or
	TLS earlier than TLS1.2.		TLS earlier than TLS 1.2.</blockquote>
	</t>		<t indent="0" pn="section-3-14"> OLD:</t>
	<t> OLD:</t>		<blockquote pn="section-3-15">It is <bcp14>RECOMMENDED</bcp14> that new us
	<t>		ers be required
	"It is RECOMMENDED that new users be required to use TLS version 1.1		to use TLS version 1.1 or greater from the start. However, an MSP may
	or greater from the start. However, an MSP may find it necessary to		find it necessary to make exceptions to accommodate some legacy systems
	make exceptions to accommodate some legacy systems that support only		that support only earlier versions of TLS or only
	earlier versions of TLS or only cleartext."		cleartext.</blockquote>
	</t>		<t indent="0" pn="section-3-16">NEW:</t>
	<t>NEW:</t>		<blockquote pn="section-3-17">It is <bcp14>RECOMMENDED</bcp14> that new us
	<t>		ers be required
	"It is RECOMMENDED that new users be required to use TLS version 1.2		to use TLS version 1.2 or greater from the start. However, an MSP may
	or greater from the start. However, an MSP may find it necessary to		find it necessary to make exceptions to accommodate some legacy systems
	make exceptions to accommodate some legacy systems that support only		that support only earlier versions of TLS or only
	earlier versions of TLS or only cleartext."		cleartext.</blockquote>
	</t>		<t indent="0" pn="section-3-18">OLD:</t>
	<t>OLD:</t>		<blockquote pn="section-3-19">If, however, an MUA provides such an indicat
	<t>		ion, it
	"		<bcp14>MUST NOT</bcp14> indicate confidentiality for any connection that d
	If, however, an MUA provides such an indication, it		oes not
	MUST NOT indicate confidentiality for any connection that does not
	at least use TLS 1.1 with certificate verification and also meet		at least use TLS 1.1 with certificate verification and also meet
	the minimum confidentiality requirements associated with that		the minimum confidentiality requirements associated with that
	account.		account.</blockquote>
	"		<t indent="0" pn="section-3-20">NEW:</t>
	</t>		<blockquote pn="section-3-21">If, however, an MUA provides such an indicat
	<t>NEW:</t>		ion, it
	<t>		<bcp14>MUST NOT</bcp14> indicate confidentiality for any connection that d
	"		oes not
	If, however, an MUA provides such an indication, it
	MUST NOT indicate confidentiality for any connection that does not
	at least use TLS 1.2 with certificate verification and also meet		at least use TLS 1.2 with certificate verification and also meet
	the minimum confidentiality requirements associated with that		the minimum confidentiality requirements associated with that
	account.		account.</blockquote>
	"		<t indent="0" pn="section-3-22">OLD</t>
	</t>		<blockquote pn="section-3-23">MUAs <bcp14>MUST</bcp14> implement TLS 1.2 <
	<t>OLD</t>		xref target="RFC5246" format="default" sectionFormat="of" derivedContent="RFC524
	<t>		6"/> or later. Earlier TLS and
	"		SSL versions <bcp14>MAY</bcp14> also be supported, so long as the MUA requ
	MUAs MUST implement TLS 1.2 <xref target="RFC5246"/> or later. Earlier TLS and		ires at
	SSL versions MAY also be supported, so long as the MUA requires at		least TLS 1.1 <xref target="RFC4346" format="default" sectionFormat="of"
	least TLS 1.1 <xref target="RFC4346"/> when accessing accounts that are		derivedContent="RFC4346"/> when accessing accounts that are
	configured to impose minimum confidentiality requirements.		configured to impose minimum confidentiality requirements.</blockquote>
	"		<t indent="0" pn="section-3-24">NEW:</t>
	</t>		<blockquote pn="section-3-25">MUAs <bcp14>MUST</bcp14> implement TLS 1.2
	<t>NEW:</t>		<xref target="RFC5246" format="default" sectionFormat="of" derivedContent="RFC52
	<t>		46"/> or later, e.g., TLS 1.3 <xref target="RFC8446" format="default" sectionFo
	"		rmat="of" derivedContent="RFC8446"/>. Earlier TLS and
	MUAs MUST implement TLS 1.2 <xref target="RFC5246"/> or later e.g TLS 1.3 <xre		SSL versions <bcp14>MAY</bcp14> also be supported, so long as the MUA requ
	f target="RFC8446"/>. Earlier TLS and		ires at
	SSL versions MAY also be supported, so long as the MUA requires at		least TLS 1.2 <xref target="RFC5246" format="default" sectionFormat="of"
	least TLS 1.2 <xref target="RFC5246"/> when accessing accounts that are		derivedContent="RFC5246"/> when accessing accounts that are
	configured to impose minimum confidentiality requirements.		configured to impose minimum confidentiality requirements.</blockquote>
	"		<t indent="0" pn="section-3-26">OLD:</t>
	</t>		<blockquote pn="section-3-27">The default minimum expected level of confid
	<t>OLD:</t>		entiality for all new
	<t>		accounts <bcp14>MUST</bcp14> require successful validation of the server's
	"		certificate and <bcp14>SHOULD</bcp14> require negotiation of TLS version 1.1
	The default minimum expected level of confidentiality for all new		or
	accounts MUST require successful validation of the server's
	certificate and SHOULD require negotiation of TLS version 1.1 or
	greater. (Future revisions to this specification may raise these		greater. (Future revisions to this specification may raise these
	requirements or impose additional requirements to address newly		requirements or impose additional requirements to address newly
	discovered weaknesses in protocols or cryptographic algorithms.		discovered weaknesses in protocols or cryptographic algorithms.)</blockquote>
	"		<t indent="0" pn="section-3-28">NEW:</t>
	</t>		<blockquote pn="section-3-29">The default minimum expected level of confid
	<t>NEW:</t>		entiality for all new
	<t>		accounts <bcp14>MUST</bcp14> require successful validation of the server's
	"		certificate and <bcp14>SHOULD</bcp14> require negotiation of TLS version 1.2
	The default minimum expected level of confidentiality for all new		or
	accounts MUST require successful validation of the server's
	certificate and SHOULD require negotiation of TLS version 1.2 or
	greater. (Future revisions to this specification may raise these		greater. (Future revisions to this specification may raise these
	requirements or impose additional requirements to address newly		requirements or impose additional requirements to address newly
	discovered weaknesses in protocols or cryptographic algorithms.		discovered weaknesses in protocols or cryptographic algorithms.)</blockquote>
	"		</section>
	</t>		<section anchor="iana-considerations" numbered="true" toc="include" removeIn
	</section>		RFC="false" pn="section-4">
			<name slugifiedName="name-iana-considerations">IANA Considerations</name>
	<section anchor="iana-considerations" title="IANA Considerations">		<t indent="0" pn="section-4-1">This document has no IANA actions.</t>
	<t>None of the proposed measures have an impact on IANA.		</section>
	</t>		<section anchor="security-considerations" numbered="true" toc="include" remo
	</section>		veInRFC="false" pn="section-5">
			<name slugifiedName="name-security-considerations">Security Considerations
	<section anchor="security-considerations" title="Security Considerations">		</name>
	<t>The purpose of this document is to document updated recommendations		<t indent="0" pn="section-5-1">The purpose of this document is to document
	for using TLS with Email services. Those recommendations are based on		updated recommendations
	<xref target="I-D.ietf-tls-oldversions-deprecate"></xref>.		for using TLS with email services. Those recommendations are based on
	</t>		<xref target="RFC8996" format="default" sectionFormat="of" derivedContent=
	</section>		"RFC8996"/>.</t>
			</section>
	<section anchor="Acknowledgement" title="Acknowledgement">		</middle>
	<t>The authors would like to thank Vittorio Bertola and		<back>
	Viktor Dukhovni for their feedback.		<references pn="section-6">
	</t>		<name slugifiedName="name-references">References</name>
	</section>		<references pn="section-6.1">
			<name slugifiedName="name-normative-references">Normative References</na
	</middle>		me>
	<back>		<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
	<references title="Informative References">		119" quoteTitle="true" derivedAnchor="RFC2119">
	<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4346.xml"		<front>
	?>		<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	</references>		le>
	<references title="Normative References">		<author initials="S." surname="Bradner" fullname="S. Bradner">
	<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8314.xml"		<organization showOnFrontPage="true"/>
	?>		</author>
	<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"		<date year="1997" month="March"/>
	?>		<abstract>
	<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"		<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="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"		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="http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D		e Internet Community, and requests discussion and suggestions for improvements.<
	.ietf-tls-oldversions-deprecate.xml"?>		/t>
	</references>		</abstract>
			</front>
	</back>		<seriesInfo name="BCP" value="14"/>
			<seriesInfo name="RFC" value="2119"/>
			<seriesInfo name="DOI" value="10.17487/RFC2119"/>
			</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="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="RFC8314" target="https://www.rfc-editor.org/info/rfc8
			314" quoteTitle="true" derivedAnchor="RFC8314">
			<front>
			<title>Cleartext Considered Obsolete: Use of Transport Layer Securit
			y (TLS) for Email Submission and Access</title>
			<author initials="K." surname="Moore" fullname="K. Moore">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="C." surname="Newman" fullname="C. Newman">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2018" month="January"/>
			<abstract>
			<t indent="0">This specification outlines current recommendations
			for the use of Transport Layer Security (TLS) to provide confidentiality of emai
			l traffic between a Mail User Agent (MUA) and a Mail Submission Server or Mail A
			ccess Server. This document updates RFCs 1939, 2595, 3501, 5068, 6186, and 6409
			.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="8314"/>
			<seriesInfo name="DOI" value="10.17487/RFC8314"/>
			</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="RFC8996" target="https://www.rfc-editor.org/info/rfc8
			996" quoteTitle="true" derivedAnchor="RFC8996">
			<front>
			<title>Deprecating TLS 1.0 and TLS 1.1</title>
			<author initials="K" surname="Moriarty" fullname="Kathleen Moriarty"
			>
			<organization showOnFrontPage="true">Dell EMC</organization>
			</author>
			<author initials="S" surname="Farrell" fullname="Stephen Farrell">
			<organization showOnFrontPage="true">Trinity College Dublin</organ
			ization>
			</author>
			<date month="March" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8996"/>
			<seriesInfo name="DOI" value="10.17487/RFC8996"/>
			</reference>
			</references>
			<references pn="section-6.2">
			<name slugifiedName="name-informative-references">Informative References
			</name>
			<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>
			</references>
			</references>
			<section anchor="Acknowledgement" numbered="false" toc="include" removeInRFC
			="false" pn="section-appendix.a">
			<name slugifiedName="name-acknowledgements">Acknowledgements</name>
			<t indent="0" pn="section-appendix.a-1">The authors would like to thank <c
			ontact fullname="Vittorio Bertola"/> and <contact fullname="Viktor Dukhovn
			i"/> for their
			feedback.</t>
			</section>
			<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
			="include" pn="section-appendix.b">
			<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
			<author initials="L." surname="Velvindron" fullname="Loganaden Velvindron"
			>
			<organization showOnFrontPage="true">cyberstorm.mu</organization>
			<address>
			<postal>
			<street>88 Avenue De Plevitz Roches Brunes</street>
			<city>Rose Hill</city>
			<code>71259</code>
			<country>Mauritius</country>
			</postal>
			<phone>+230 59762817</phone>
			<email>logan@cyberstorm.mu</email>
			<uri/>
			</address>
			</author>
			<author fullname="Stephen Farrell" initials="S." surname="Farrell">
			<organization showOnFrontPage="true">Trinity College Dublin</organizatio
			n>
			<address>
			<postal>
			<street/>
			<city>Dublin</city>
			<region/>
			<code>2</code>
			<country>Ireland</country>
			</postal>
			<phone>+353-1-896-2354</phone>
			<email>stephen.farrell@cs.tcd.ie</email>
			</address>
			</author>
			</section>
			</back>
	</rfc>		</rfc>
End of changes. 17 change blocks.
	217 lines changed or deleted		498 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/