Diff: rfc9662.original.xml

	rfc9662.original.xml	rfc9662.xml

	<?xml version='1.0' encoding='utf-8'?>	<?xml version='1.0' encoding='UTF-8'?>
	<?xml-model href="rfc7991bis.rnc"?>


	<rfc	<!-- draft submitted in xml v3 -->
	xmlns:xi="http://www.w3.org/2001/XInclude"
	category="std"
	docName="draft-ietf-uta-ciphersuites-in-sec-syslog-07"
	ipr="trust200902"
	obsoletes=""
	updates="5425 6012"
	submissionType="IETF"
	xml:lang="en"
	tocInclude="true"
	tocDepth="4"
	symRefs="true"
	sortRefs="true"
	version="3">


	<!-- *** FRONT MATTER *** -->	<!DOCTYPE rfc [
		<!ENTITY nbsp " ">
		<!ENTITY zwsp "">
		<!ENTITY nbhy "‑">
		<!ENTITY wj "⁠">
		]>


	<front>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie tf-uta-ciphersuites-in-sec-syslog-07" number="9662" ipr="trust200902" obsoletes= "" updates="5425, 6012" submissionType="IETF" consensus="true" xml:lang="en" toc Include="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">


		<front>
	<title abbrev="Cipher Suites in Secure Syslog">Updates to the Cipher Suites i n Secure Syslog</title>	<title abbrev="Cipher Suites in Secure Syslog">Updates to the Cipher Suites i n Secure Syslog</title>

	<seriesInfo name="Internet-Draft" value="draft-ietf-uta-ciphersuites-in-sec-	<seriesInfo name="RFC" value="9662"/>
	syslog-07"/>	<author fullname="Chris Lonvick" initials="C." surname="Lonvick">

	<author fullname="Chris Lonvick" initials="C." surname="Lonvick">
	<address>	<address>
	<email>lonvick.ietf@gmail.com</email>	<email>lonvick.ietf@gmail.com</email>
	</address>	</address>
	</author>	</author>

	<author fullname="Sean Turner" initials="S." surname="Turner">	<author fullname="Sean Turner" initials="S." surname="Turner">
	<organization>sn3rd</organization>	<organization>sn3rd</organization>
	<address>	<address>
	<email>sean@sn3rd.com</email>	<email>sean@sn3rd.com</email>
	</address>	</address>
	</author>	</author>

	<author fullname="Joe Salowey" initials="J." surname="Salowey">	<author fullname="Joe Salowey" initials="J." surname="Salowey">

	<organization>Venafi</organization>	<organization>Venafi</organization>
	<address>	<address>
	<email>joe@salowey.net</email>	<email>joe@salowey.net</email>
	</address>	</address>
	</author>	</author>


	<date year="2024"/>	<date month="September" year="2024"/>

	<!-- Meta-data Declarations -->


	<area>Applications and Real-Time Area</area>	<area>SEC</area>
	<workgroup>Internet Engineering Task Force</workgroup>	<workgroup>uts</workgroup>


	<keyword>syslog</keyword>	<keyword>syslog</keyword>
	<keyword>secure syslog</keyword>	<keyword>secure syslog</keyword>
	<keyword>TLS_RSA_WITH_AES_128_CBC_SHA</keyword>	<keyword>TLS_RSA_WITH_AES_128_CBC_SHA</keyword>
	<keyword>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</keyword>	<keyword>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</keyword>
	<keyword>DTLS</keyword>	<keyword>DTLS</keyword>
	<keyword>TLS</keyword>	<keyword>TLS</keyword>
	<keyword>cipher suite</keyword>	<keyword>cipher suite</keyword>


	<abstract>	<abstract>
	<t>	<t>
	The IETF published two specifications, namely RFC 5425 and	RFCs 5425 and 6012 describe using TLS and DTLS to securely
	RFC 6012, for securing the Syslog protocol using TLS and DTLS, re	transport syslog messages. This document updates the
	spectively.	cipher suites required by RFC 5245 (TLS
	</t><t>	Transport Mapping for Syslog) and RFC 6012
	This document updates the cipher suites in RFC 5425, Transport La	(DTLS Transport Mapping for Syslog). It also updates
	yer Security	the protocol recommended by RFC 6012 for secure datagram transport.
	(TLS) Transport Mapping for Syslog, and RFC 6012, Datagram Transp
	ort Layer
	Security (DTLS) Transport Mapping for Syslog. It also updates the
	transport
	protocol in RFC 6012.
	</t>	</t>
	</abstract>	</abstract>
	</front>	</front>
	<middle>	<middle>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Introduction</name>	<name>Introduction</name>

		<t>
		"Transport Layer Security (TLS) Transport Mapping for Syslog" <xref target="R
		FC5425"/> and
		"Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog" <xref
		target="RFC6012"/>
		describe using TLS and DTLS to securely transport syslog messages. Both
		of these specifications require the use of RSA-based certificates
		and the use of TLS and DTLS versions that are not the most recent.
		</t>
	<t>	<t>

	The IETF published RFC 5425, Transport Layer Security (TL	<xref target="RFC5425" sectionFormat="of" section="4.2"/>
	S)	requires that implementations <bcp14>MUST</bcp14>
	Transport Mapping for Syslog, and RFC 6012, Datagram Tran	support TLS 1.2 <xref target="RFC5246" /> and are <bcp14>
	sport Layer	REQUIRED</bcp14>
	Security (DTLS) Transport Mapping for Syslog.	to support the mandatory-to-implement cipher suite
	</t><t>	TLS_RSA_WITH_AES_128_CBC_SHA.
	Both specifications, <xref target="RFC5425" /> and <xref
	target="RFC6012" />,
	require the use of RSA-based certificates and the use of
	TLS/DTLS versions
	that are not the most recent.
	</t><t>
	<xref target="RFC5425" /> requires that implementations "
	<bcp14>MUST</bcp14>"
	support TLS 1.2 <xref target="RFC5246" /> and are "<bcp14
	>REQUIRED</bcp14>"
	to support the mandatory to implement cipher suite
	TLS_RSA_WITH_AES_128_CBC_SHA (Section 4.2).
	</t><t>	</t><t>

	<xref target="RFC6012" /> requires that implementations " <bcp14>MUST</bcp14>"	<xref target="RFC6012" sectionFormat="of" section="5.2"/> requires that implementations "<bcp14>MUST</bcp14>"
	support DTLS 1.0 <xref target="RFC4347" /> and are also	support DTLS 1.0 <xref target="RFC4347" /> and are also

	"<bcp14>REQUIRED</bcp14>" to support the mandatory to imp	"<bcp14>REQUIRED</bcp14>" to support the mandatory-to-imp
	lement cipher suite	lement cipher suite
	TLS_RSA_WITH_AES_128_CBC_SHA (Section 5.2).	TLS_RSA_WITH_AES_128_CBC_SHA.
	</t><t>	</t><t>

	The community is moving away from cipher suits that don't offer forward	The community is moving away from cipher suites that don' t offer forward
	secrecy and towards more robust suites.	secrecy and towards more robust suites.
	</t><t>	</t><t>
	The DTLS 1.0 transport <xref target="RFC4347" /> has been deprecated by	The DTLS 1.0 transport <xref target="RFC4347" /> has been deprecated by

	<xref target="BCP195" /> and the community is moving to D TLS 1.2	RFC 8996 <xref target="BCP195" />, and the community is m oving to DTLS 1.2
	<xref target="RFC6347" /> and DTLS 1.3 <xref target="RFC9 147" />.	<xref target="RFC6347" /> and DTLS 1.3 <xref target="RFC9 147" />.
	</t><t>	</t><t>
	This document updates <xref target="RFC5425" /> and <xref target="RFC6012" />	This document updates <xref target="RFC5425" /> and <xref target="RFC6012" />
	to prefer the use of TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA25 6 over the use of	to prefer the use of TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA25 6 over the use of
	TLS_RSA_WITH_AES_128_CBC_SHA.	TLS_RSA_WITH_AES_128_CBC_SHA.
	</t><t>	</t><t>

	This document also updates <xref target="RFC6012" /> to m	This document also updates <xref target="RFC6012" /> by r
	ake a recommendation	ecommending
	of a mandatory to implement secure datagram transport.	a mandatory-to-implement secure datagram transport.
	</t>	</t>
	</section>	</section>


	<section anchor="name-terminology" title="Terminology" numbered="	<section anchor="terminology" numbered="true" toc="default">
	true" toc="default">
	<t>	<name>Terminology</name>
	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bc	<t>
	p14>",	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
	"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",	",
	"<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>"	"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	,	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	"<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", a	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	nd	be
	"<bcp14>OPTIONAL</bcp14>" in this document are to be inte	interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
	rpreted as	target="RFC8174"/> when, and only when, they appear in all capitals, as
	described in BCP 14	shown here.
	[<xref target="RFC2119" format="default" sectionFormat="o	</t>
	f" derivedContent="RFC2119"/>]
	[<xref target="RFC8174" format="default" sectionFormat="o
	f" derivedContent="RFC8174"/>]
	when, and only when, they appear in all capitals, as show
	n here.
	</t>
	</section>	</section>


	<section anchor="reasons" title="Support for Updating" numbered="	<section anchor="reasons" numbered="true" toc="default">
	true" toc="default">	<name>Support for Updating</name>
	<t>	<t>

	<xref target="draft-ietf-tls-rfc8447bis-09" /> generally reminds us that	<xref target="I-D.ietf-tls-rfc8447bis" /> generally remin ds us that
	cryptographic algorithms and parameters will be broken or weakened over time.	cryptographic algorithms and parameters will be broken or weakened over time.
	Blindly implementing the cryptographic algorithms listed in any specification	Blindly implementing the cryptographic algorithms listed in any specification
	is not advised. Implementers and users need to check that the cryptographic	is not advised. Implementers and users need to check that the cryptographic
	algorithms specified continue to provide the expected lev el of security.	algorithms specified continue to provide the expected lev el of security.
	</t><t>	</t><t>

	As the Syslog Working Group determined, Syslog clients an d servers	As the Syslog Working Group determined, syslog clients an d servers
	<bcp14>MUST</bcp14> use certificates as defined in <xref target="RFC5280" />.	<bcp14>MUST</bcp14> use certificates as defined in <xref target="RFC5280" />.
	Since both <xref target="RFC5425" /> and <xref target="RF C6012" />	Since both <xref target="RFC5425" /> and <xref target="RF C6012" />
	<bcp14>REQUIRED</bcp14> the use of TLS_RSA_WITH_AES_128_C BC_SHA, it is very	<bcp14>REQUIRED</bcp14> the use of TLS_RSA_WITH_AES_128_C BC_SHA, it is very
	likely that RSA certificates have been implemented in dev ices adhering to	likely that RSA certificates have been implemented in dev ices adhering to

	those specifications. <xref target="BCP195" /> notes that ECDHE cipher suites	those specifications. RFC 9325 <xref target="BCP195" /> n otes that ECDHE cipher suites
	exist for both RSA and ECDSA certificates, so moving to a n ECDHE cipher suite	exist for both RSA and ECDSA certificates, so moving to a n ECDHE cipher suite
	will not require replacing or moving away from any curren tly installed	will not require replacing or moving away from any curren tly installed
	RSA-based certificates.	RSA-based certificates.
	</t><t>	</t><t>

	<xref target="draft-ietf-tls-deprecate-obsolete-kex-04" / > documents that the	<xref target="I-D.ietf-tls-deprecate-obsolete-kex" /> doc uments that the
	cipher suite TLS_RSA_WITH_AES_128_CBC_SHA, along with som e other cipher suites,	cipher suite TLS_RSA_WITH_AES_128_CBC_SHA, along with som e other cipher suites,
	may require mitigation techniques to achieve expected sec urity, which may be	may require mitigation techniques to achieve expected sec urity, which may be
	difficult to effectively implement. Along those lines,	difficult to effectively implement. Along those lines,

	<xref target="BCP195" /> [<xref target="RFC9325" />] note
	s that	RFC 9325 <xref target="BCP195" /> notes that
	TLS_RSA_WITH_AES_128_CBC_SHA does not provide forward sec recy, a feature that	TLS_RSA_WITH_AES_128_CBC_SHA does not provide forward sec recy, a feature that
	is highly desirable in securing event messages. That docu ment also goes on to	is highly desirable in securing event messages. That docu ment also goes on to
	recommend TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as a ciph er suite that does	recommend TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as a ciph er suite that does
	provide forward secrecy.	provide forward secrecy.
	</t><t>	</t><t>
	As such, the community is moving away from algorithms tha t do not provide	As such, the community is moving away from algorithms tha t do not provide
	forward secrecy. For example, the International Electrote chnical Commission	forward secrecy. For example, the International Electrote chnical Commission
	(IEC) has selected more robust suites such as	(IEC) has selected more robust suites such as
	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, which is also list ed as a	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, which is also list ed as a

	currently RECCOMENDED algorithm in	currently <bcp14>RECOMMENDED</bcp14> algorithm in
	<xref target="draft-ietf-tls-rfc8447bis-09" /> for their	<xref target="I-D.ietf-tls-rfc8447bis" /> for their deplo
	deployments of	yments of
	secure syslog.	secure syslog.
	</t><t>	</t><t>

	Additionally, <xref target="BCP195" />	Additionally, RFC 8996 <xref target="BCP195" />
	[<xref target="RFC8996" format="default" />] deprecates t	deprecates the use
	he use	of DTLS 1.0 <xref target="RFC4347" />, which is the manda
	of DTLS 1.0 <xref target="RFC4347" />, which is the manda	tory-to-implement
	tory to implement	transport protocol per <xref target="RFC6012" />. Therefo
	transport protocol for <xref target="RFC6012" />. Therefo	re, that transport
	re, the transport	protocol must be updated.
	protocol for <xref target="RFC6012" /> must be updated.
	</t><t>	</t><t>

	Finally, <xref target="BCP195" /> (<xref target="RFC9325"	Finally, RFC 9325 <xref target="BCP195" /> provides
	/>) provides	guidance on the support of TLS 1.3 <xref target="RFC8446"
	guidance on the support of <xref target="RFC8446" /> and	/> and
	<xref target="RFC9147" />.	DTLS 1.3 <xref target="RFC9147" />.
	</t><t>	</t><t>

	Therefore, to maintain interoperability across implementa	Therefore, to maintain interoperability across implementa
	tions, the mandatory	tions, the mandatory-to-implement cipher suites listed in <xref target="RFC5425"
	to implement cipher suites listed in <xref target="RFC542	/> and
	5" /> and
	<xref target="RFC6012" /> should be updated so that imple mentations of secure	<xref target="RFC6012" /> should be updated so that imple mentations of secure
	syslog will still interoperate and provide an acceptable and expected level	syslog will still interoperate and provide an acceptable and expected level
	of security.	of security.

	</t><t>	</t>

		<t>
	However, since there are many implementations of syslog u sing	However, since there are many implementations of syslog u sing

	the cipher suites mandatated to be used in <xref target="	the cipher suites mandated by <xref target="RFC6012" />,
	RFC6012" />, a	a
	sudden change is not desireable. To accomodate a migratio	sudden change is not desirable. To accommodate a migratio
	n path, this	n path,
	specification will allow the use of both TLS_RSA_WITH_AES	TLS_RSA_WITH_AES_128_CBC_SHA or
	_128_CBC_SHA	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 may be used, but i
	and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 but <bcp14>REQU	t
	IRES</bcp14>	is REQUIRED that TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	that TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 be preferred.	be preferred.
	</t>	</t>
	</section>	</section>


	<section anchor="updates5425" title="Updates to RFC 5425">	<section anchor="updates5425">
		<name>Updates to RFC 5425</name>
	<t>	<t>

	The mandatory to implement cipher suites are <bcp14>REQUI RED</bcp14>	The mandatory-to-implement cipher suites are <bcp14>REQUI RED</bcp14>
	to be TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_W ITH_AES_128_CBC_SHA.	to be TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_W ITH_AES_128_CBC_SHA.
	</t><t>	</t><t>
	Implementations of <xref target="RFC5425" /> <bcp14>SHOUL D</bcp14> offer	Implementations of <xref target="RFC5425" /> <bcp14>SHOUL D</bcp14> offer
	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 but <bcp14>MAY</bcp 14> offer	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 but <bcp14>MAY</bcp 14> offer
	TLS_RSA_WITH_AES_128_CBC_SHA.	TLS_RSA_WITH_AES_128_CBC_SHA.
	</t><t>	</t><t>
	Implementations of <xref target="RFC5425" /> <bcp14>MUST< /bcp14> continue to	Implementations of <xref target="RFC5425" /> <bcp14>MUST< /bcp14> continue to

	use TLS 1.2 <xref target="RFC5246" /> as the mandatory to implement	use TLS 1.2 <xref target="RFC5246" /> as the mandatory-to -implement
	transport protocol.	transport protocol.

	</t><t>	</t>
	As per <xref target="BCP195" />, implementations of <xref	<t>
	target="RFC5425" />	As per RFC 9325 <xref target="BCP195" />, implementations
		of <xref target="RFC5425" />
	<bcp14>SHOULD</bcp14> support TLS 1.3 <xref target="RFC84 46" /> and, if	<bcp14>SHOULD</bcp14> support TLS 1.3 <xref target="RFC84 46" /> and, if
	implemented, <bcp14>MUST</bcp14> prefer to negotiate TLS 1.3	implemented, <bcp14>MUST</bcp14> prefer to negotiate TLS 1.3
	over earlier versions of TLS.	over earlier versions of TLS.
	</t>	</t>
	</section>	</section>


	<section anchor="updates6012" title="Updates to RFC 6012">	<section anchor="updates6012">
		<name>Updates to RFC 6012</name>
	<t>	<t>

	The mandatory to implement cipher suites are <bcp14>REQUI RED</bcp14> to be	The mandatory-to-implement cipher suites are <bcp14>REQUI RED</bcp14> to be
	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_AE S_128_CBC_SHA.	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_AE S_128_CBC_SHA.
	</t><t>	</t><t>
	Implementations of <xref target="RFC6012" /> <bcp14>SHOUL D</bcp14> offer	Implementations of <xref target="RFC6012" /> <bcp14>SHOUL D</bcp14> offer
	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 but <bcp14>MAY</bcp 14> offer	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 but <bcp14>MAY</bcp 14> offer
	TLS_RSA_WITH_AES_128_CBC_SHA.	TLS_RSA_WITH_AES_128_CBC_SHA.

	</t><t>	</t>
	As specified in <xref target="BCP195" />, implementations	<t>
	of	As specified in RFCs 8996 and 9325 <xref target="BCP195"
		/>, implementations of
	<xref target="RFC6012" /> <bcp14>MUST NOT</bcp14> use DTL S 1.0 <xref target="RFC4347" />.	<xref target="RFC6012" /> <bcp14>MUST NOT</bcp14> use DTL S 1.0 <xref target="RFC4347" />.
	Implementations <bcp14>MUST</bcp14> use DTLS 1.2 <xref ta rget="RFC6347" />.	Implementations <bcp14>MUST</bcp14> use DTLS 1.2 <xref ta rget="RFC6347" />.
	</t><t>	</t><t>
	DTLS 1.2 <xref target="RFC6347" /> implementations <bcp14 >SHOULD</bcp14> support	DTLS 1.2 <xref target="RFC6347" /> implementations <bcp14 >SHOULD</bcp14> support

	and prefer the mandatory to implement cipher suite	and prefer the mandatory-to-implement cipher suite
	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
	</t><t>	</t><t>

	As per <xref target="BCP195" />, implementations of <xref target="RFC6012" />	As per RFC 9325 <xref target="BCP195" />, implementations of <xref target="RFC6012" />
	<bcp14>SHOULD</bcp14> support DTLS 1.3 <xref target="RFC9 147" /> and, if	<bcp14>SHOULD</bcp14> support DTLS 1.3 <xref target="RFC9 147" /> and, if
	implemented, <bcp14>MUST</bcp14> prefer to negotiate DTLS version 1.3 over	implemented, <bcp14>MUST</bcp14> prefer to negotiate DTLS version 1.3 over
	earlier versions of DTLS.	earlier versions of DTLS.
	</t>	</t>
	</section>	</section>


	<section anchor="earlyData" title="Early Data">	<section anchor="earlyData">
		<name>Early Data</name>
	<t>	<t>
	Early data (aka 0-RTT data) is a mechanism defined in TLS 1.3	Early data (aka 0-RTT data) is a mechanism defined in TLS 1.3
	<xref target="RFC8446" /> that allows a client to send da ta ("early data") as	<xref target="RFC8446" /> that allows a client to send da ta ("early data") as
	part of the first flight of messages to a server. Early d ata is permitted by	part of the first flight of messages to a server. Early d ata is permitted by
	TLS 1.3 when the client and server share a PSK, either ob tained externally or	TLS 1.3 when the client and server share a PSK, either ob tained externally or
	via a previous handshake. The client uses the PSK to auth enticate the server	via a previous handshake. The client uses the PSK to auth enticate the server
	and to encrypt the early data.	and to encrypt the early data.
	</t><t>	</t><t>

	As noted in Section 2.3 of <xref target="draft-ietf-tls-r fc8446bis-09" />, the	As noted in <xref target="I-D.ietf-tls-rfc8446bis" sectio nFormat="of" section="2.3" />, the
	security properties for early data are weaker than those for subsequent	security properties for early data are weaker than those for subsequent
	TLS-protected data. In particular, early data is not for ward secret, and	TLS-protected data. In particular, early data is not for ward secret, and
	there are no protections against the replay of early data between	there are no protections against the replay of early data between

	connections. Appendix E.5 of <xref target="draft-ietf-tls	connections. <xref target="I-D.ietf-tls-rfc8446bis" secti
	-rfc8446bis-09" />	onFormat="of" section="E.5" />
	requires applications not use early data without a profil	requires that applications not use early data without a p
	e that defines its	rofile that defines its
	use. Because syslog does not support replay protection, s	use. Because syslog does not support replay protection (s
	ee Section 8.4 of	ee
	<xref target="RFC5424" />", and most implementations esta	<xref target="RFC5424" sectionFormat="of" section="8.4"/>
	blish a long-lived	) and most implementations establish a long-lived
	connection, this document specifies that implementations MUST NOT use early	connection, this document specifies that implementations MUST NOT use early
	data.	data.
	</t>	</t>
	</section>	</section>


	<section anchor="notes" title="Authors Notes">
	<t>
	This section will be removed prior to publication.
	</t><t>
	This is version -07 for the UTA Working Group. These edit
	s reflect comments
	from IESG review.
	</t>
	</section>

	<section anchor="Acks" numbered="true" toc="default">
	<name>Acknowledgments</name>
	<t>The authors would like to thank Arijit Kumar Bose, Ste
	ffen Fries and the
	members of IEC TC57 WG15 for their review, comments, and
	suggestions. The
	authors would also like to thank Tom Petch, Juergen Schoe
	nwaelder,
	Hannes Tschofenig, Viktor Dukhovni, and the IESG members
	for their comments
	and constructive feedback.
	</t>
	</section>

	<section anchor="IANA" numbered="true" toc="default">	<section anchor="IANA" numbered="true" toc="default">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>

	<t>This document makes no requests to IANA.</t>	<t>This document has no IANA actions.</t>
	</section>	</section>
	<section anchor="Security" numbered="true" toc="default">	<section anchor="Security" numbered="true" toc="default">
	<name>Security Considerations</name>	<name>Security Considerations</name>
	<t>	<t>

	<xref target="BCP195" /> deprecates an insecure DTLS tran	RFCs 8996 and 9325 <xref target="BCP195" /> deprecate an
	sport protocol	insecure DTLS transport protocol
	from <xref target="RFC6012" /> and deprecates insecure ci	from <xref target="RFC6012" /> and deprecate insecure cip
	pher suits from	her suites from
	<xref target="RFC5425" /> and <xref target="RFC6012" />. However, the	<xref target="RFC5425" /> and <xref target="RFC6012" />. However, the
	installed base of syslog implementations is not easily up dated to	installed base of syslog implementations is not easily up dated to
	immediately adhere to those changes.	immediately adhere to those changes.
	</t><t>	</t><t>

	This document updates the mandatory to implement cipher s uites to allow	This document updates the mandatory-to-implement cipher s uites to allow
	for a migration from TLS_RSA_WITH_AES_128_CBC_SHA to	for a migration from TLS_RSA_WITH_AES_128_CBC_SHA to
	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 without deprecating the former.	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 without deprecating the former.
	Implementations should prefer to use TLS_ECDHE_RSA_WITH_A ES_128_GCM_SHA256.	Implementations should prefer to use TLS_ECDHE_RSA_WITH_A ES_128_GCM_SHA256.
	</t><t>	</t><t>
	If a device currently only has TLS_RSA_WITH_AES_128_CBC_S HA, an	If a device currently only has TLS_RSA_WITH_AES_128_CBC_S HA, an
	administrator of the network should evaluate	administrator of the network should evaluate
	the conditions and determine if TLS_RSA_WITH_AES_128_CBC_ SHA should be allowed	the conditions and determine if TLS_RSA_WITH_AES_128_CBC_ SHA should be allowed
	so that syslog messages may continue to be delivered unti l the device is	so that syslog messages may continue to be delivered unti l the device is
	updated to have TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.	updated to have TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
	</t>	</t>
	</section>	</section>
	</middle>	</middle>

	<!-- ***BACK MATTER *** -->

	<back>	<back>

		<displayreference target="I-D.ietf-tls-rfc8447bis" to="RFC8447bis"/>
		<displayreference target="I-D.ietf-tls-deprecate-obsolete-kex" to="DEPRECATE-
		KEX"/>
		<displayreference target="I-D.ietf-tls-rfc8446bis" to="RFC8446bis"/>
	<references>	<references>
	<name>References</name>	<name>References</name>
	<references>	<references>
	<name>Normative References</name>	<name>Normative References</name>

		<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
		19.xml'/>
		<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
		74.xml'/>
		<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.54
		25.xml'/>
		<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52
		46.xml'/>
		<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.54
		24.xml'/>
		<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
		46.xml'/>
		<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.63
		47.xml'/>
		<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.43
		47.xml'/>
		<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.60
		12.xml'/>
		<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52
		80.xml'/>


	<referencegroup anchor="BCP14" target="https://www.rfc-editor.org/info/bcp14">	<referencegroup anchor="BCP195" target="https://www.rfc-editor.org/info/b
	<!-- reference.RFC.2119.xml -->	cp195">
	<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.
	<front>	8996.xml'/>
	<title>Key words for use in RFCs to Indicate Requirement Levels</title>	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.
	<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></	9325.xml'/>
	author>	</referencegroup>
	<date year='1997' month='March' />
	<abstract><t>In many standards track documents several words are used to signify
	the requirements in the specification. These words are often capitalized. This
	document defines these words as they should be interpreted in IETF documents.
	This document specifies an Internet Best Current Practices for the Internet Comm
	unity, and requests discussion and suggestions for improvements.</t></abstract>
	</front>
	<seriesInfo name='BCP' value='14'/>
	<seriesInfo name='RFC' value='2119'/>
	<seriesInfo name='DOI' value='10.17487/RFC2119'/>
	</reference>
	<!-- reference.RFC.8174.xml -->
	<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
	<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth
	or>
	<date year='2017' month='May' />
	<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
	pecifications. This document aims to reduce the ambiguity by clarifying that on
	ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
	tract>
	</front>
	<seriesInfo name='BCP' value='14'/>
	<seriesInfo name='RFC' value='8174'/>
	<seriesInfo name='DOI' value='10.17487/RFC8174'/>
	</reference>
	</referencegroup>

	<reference anchor='RFC5425' target='https://www.rfc-editor.org/info/rfc5425'>
	<front>
	<title>Transport Layer Security (TLS) Transport Mapping for Syslog</title>
	<author initials='F.' surname='Miao' fullname='F. Miao' role='editor'><organizat
	ion /></author>
	<author initials='Y.' surname='Ma' fullname='Y. Ma' role='editor'><organization
	/></author>
	<author initials='J.' surname='Salowey' fullname='J. Salowey' role='editor'><org
	anization /></author>
	<date year='2009' month='March' />
	<abstract><t>This document describes the use of Transport Layer Security (TLS) t
	o provide a secure connection for the transport of syslog messages. This documen
	t describes the security threats to syslog and how TLS can be used to counter su
	ch threats. [STANDARDS-TRACK]</t></abstract>
	</front>
	<seriesInfo name='RFC' value='5425'/>
	<seriesInfo name='DOI' value='10.17487/RFC5425'/>
	</reference>

	<reference anchor='RFC5246' target='https://www.rfc-editor.org/info/rfc5246'>
	<front>
	<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
	<author initials='T.' surname='Dierks' fullname='T. Dierks'><organization /></au
	thor>
	<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization />
	</author>
	<date year='2008' month='August' />
	<abstract><t>This document specifies Version 1.2 of the Transport Layer Security
	(TLS) protocol. The TLS protocol provides communications security over the Int
	ernet. The protocol allows client/server applications to communicate in a way t
	hat is designed to prevent eavesdropping, tampering, or message forgery. [STAND
	ARDS-TRACK]</t></abstract>
	</front>
	<seriesInfo name='RFC' value='5246'/>
	<seriesInfo name='DOI' value='10.17487/RFC5246'/>
	</reference>

	<reference anchor='RFC5424'>
	<front>
	<title>The Syslog Protocol</title>
	<author initials='R.' surname='Gerhards' fullname='R. Gerhards'>
	<organization /></author>
	<date year='2009' month='March' />
	<abstract>
	<t>This document describes the syslog protocol, which is used to convey event
	notification messages. This protocol utilizes a layered architecture, which allo
	ws the
	use of any number of transport protocols for transmission of syslog messages. It
	also
	provides a message format that allows vendor-specific extensions to be provided
	in a
	structured way.</t><t> This document has been written with the original de
	sign
	goals for traditional syslog in mind. The need for a new layered specification h
	as
	arisen because standardization efforts for reliable and secure syslog extensions
	suffer
	from the lack of a Standards-Track and transport-independent RFC. Without this d
	ocument,
	each other standard needs to define its own syslog packet format and transport m
	echanism,
	which over time will introduce subtle compatibility issues. This document tries
	to
	provide a foundation that syslog extensions can build on. This layered architect
	ure
	approach also provides a solid basis that allows code to be written once for eac
	h syslog
	feature rather than once for each transport. [STANDARDS-TRACK]</t></abstract></f
	ront>
	<seriesInfo name='RFC' value='5424' />
	<format type='TXT' octets='85162' target='http://www.rfc-editor.org/rfc/rfc5424.
	txt' />
	</reference>

	<reference anchor='RFC8446' target='https://www.rfc-editor.org/info/rfc8446'>
	<front>
	<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
	<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization />
	</author>
	<date year='2018' month='August' />
	<abstract><t>This document specifies version 1.3 of the Transport Layer Security
	(TLS) protocol. TLS allows client/server applications to communicate over the
	Internet in a way that is designed to prevent eavesdropping, tampering, and mess
	age forgery.</t><t>This document updates RFCs 5705 and 6066, and obsoletes RFCs
	5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2
	implementations.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='8446'/>
	<seriesInfo name='DOI' value='10.17487/RFC8446'/>
	</reference>

	<reference anchor='RFC6347' target='https://www.rfc-editor.org/info/rfc6347'>
	<front>
	<title>Datagram Transport Layer Security Version 1.2</title>
	<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization />
	</author>
	<author initials='N.' surname='Modadugu' fullname='N. Modadugu'><organization />
	</author>
	<date year='2012' month='January' />
	<abstract><t>This document specifies version 1.2 of the Datagram Transport Layer
	Security (DTLS) protocol. The DTLS protocol provides communications privacy fo
	r datagram protocols. The protocol allows client/server applications to communi
	cate in a way that is designed to prevent eavesdropping, tampering, or message f
	orgery. The DTLS protocol is based on the Transport Layer Security (TLS) protoc
	ol and provides equivalent security guarantees. Datagram semantics of the under
	lying transport are preserved by the DTLS protocol. This document updates DTLS
	1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t></abstract>
	</front>
	<seriesInfo name='RFC' value='6347'/>
	<seriesInfo name='DOI' value='10.17487/RFC6347'/>
	</reference>

	<reference anchor='RFC4347' target='https://www.rfc-editor.org/info/rfc4347'>
	<front>
	<title>Datagram Transport Layer Security</title>
	<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization />
	</author>
	<author initials='N.' surname='Modadugu' fullname='N. Modadugu'><organization />
	</author>
	<date year='2006' month='April' />
	<abstract><t>This document specifies Version 1.0 of the Datagram Transport Layer
	Security (DTLS) protocol. The DTLS protocol provides communications privacy fo
	r datagram protocols. The protocol allows client/server applications to communi
	cate in a way that is designed to prevent eavesdropping, tampering, or message f
	orgery. The DTLS protocol is based on the Transport Layer Security (TLS) protoc
	ol and provides equivalent security guarantees. Datagram semantics of the under
	lying 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='RFC6012' target='https://www.rfc-editor.org/info/rfc6012'>
	<front>
	<title>Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog</ti
	tle>
	<author initials='J.' surname='Salowey' fullname='J. Salowey'><organization /></
	author>
	<author initials='T.' surname='Petch' fullname='T. Petch'><organization /></auth
	or>
	<author initials='R.' surname='Gerhards' fullname='R. Gerhards'><organization />
	</author>
	<author initials='H.' surname='Feng' fullname='H. Feng'><organization /></author
	>
	<date year='2010' month='October' />
	<abstract><t>This document describes the transport of syslog messages over the D
	atagram Transport Layer Security (DTLS) protocol. It provides a secure transpor
	t for syslog messages in cases where a connectionless transport is desired. [ST
	ANDARDS-TRACK]</t></abstract>
	</front>
	<seriesInfo name='RFC' value='6012'/>
	<seriesInfo name='DOI' value='10.17487/RFC6012'/>
	</reference>

	<reference anchor='RFC5280' target='https://www.rfc-editor.org/info/rfc5280'>
	<front>
	<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revo
	cation List (CRL) Profile</title>
	<author initials='D.' surname='Cooper' fullname='D. Cooper'><organization /></au
	thor>
	<author initials='S.' surname='Santesson' fullname='S. Santesson'><organization
	/></author>
	<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></
	author>
	<author initials='S.' surname='Boeyen' fullname='S. Boeyen'><organization /></au
	thor>
	<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></
	author>
	<author initials='W.' surname='Polk' fullname='W. Polk'><organization /></author
	>
	<date year='2008' month='May' />
	<abstract><t>This memo profiles the X.509 v3 certificate and X.509 v2 certificat
	e revocation list (CRL) for use in the Internet. An overview of this approach a
	nd model is provided as an introduction. The X.509 v3 certificate format is des
	cribed in detail, with additional information regarding the format and semantics
	of Internet name forms. Standard certificate extensions are described and two
	Internet-specific extensions are defined. A set of required certificate extensi
	ons is specified. The X.509 v2 CRL format is described in detail along with sta
	ndard and Internet-specific extensions. An algorithm for X.509 certification pa
	th validation is described. An ASN.1 module and examples are provided in the ap
	pendices. [STANDARDS-TRACK]</t></abstract>
	</front>
	<seriesInfo name='RFC' value='5280'/>
	<seriesInfo name='DOI' value='10.17487/RFC5280'/>
	</reference>

	<referencegroup anchor="BCP195" target="https://www.rfc-editor.org/info/bcp195">
	<reference anchor='RFC8996' target='https://www.rfc-editor.org/info/rfc8996'>
	<front>
	<title>Deprecating TLS 1.0 and TLS 1.1</title>
	<author initials='K.' surname='Moriarty' fullname='K. Moriarty'><organization />
	</author>
	<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></
	author>
	<date year='2021' month='March' />
	<abstract><t>This document formally deprecates Transport Layer Security (TLS) ve
	rsions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been
	moved to Historic status. These versions lack support for current and recommend
	ed cryptographic algorithms and mechanisms, and various government and industry
	profiles of applications using TLS now mandate avoiding these old TLS versions.
	TLS version 1.2 became the recommended version for IETF protocols in 2008 (subse
	quently being obsoleted by TLS version 1.3 in 2018), providing sufficient time t
	o transition away from older versions. Removing support for older versions from
	implementations reduces the attack surface, reduces opportunity for misconfigura
	tion, and streamlines library and product maintenance. </t><t>This document also
	deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2,
	and there is no DTLS version 1.1.</t><t>This document updates many RFCs that no
	rmatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This
	document also updates the best practices for TLS usage in RFC 7525; hence, it i
	s part of BCP 195.</t></abstract>
	</front>
	<seriesInfo name='BCP' value='195'/>
	<seriesInfo name='RFC' value='8996'/>
	<seriesInfo name='DOI' value='10.17487/RFC8996'/>
	</reference>
	<reference anchor="RFC9325" target="https://www.rfc-editor.org/info/rfc9325">
	<front>
	<title>Recommendations for Secure Use of Transport Layer Security (TLS) and
	Datagram Transport Layer Security (DTLS)</title>
	<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
	<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
	<author fullname="T. Fossati" initials="T." surname="Fossati"/>
	<date month="November" year="2022"/>
	<abstract>
	<t>Transport Layer Security (TLS) and Datagram Transport Layer Security (D
	TLS) are used to protect data exchanged over a wide range of application protoco
	ls and can also form the basis for secure transport protocols. Over the years, t
	he industry has witnessed several serious attacks on TLS and DTLS, including att
	acks on the most commonly used cipher suites and their modes of operation. This
	document provides the latest recommendations for ensuring the security of deploy
	ed services that use TLS and DTLS. These recommendations are applicable to the m
	ajority of use cases.</t>
	<t>RFC 7525, an earlier version of the TLS recommendations, was published
	when the industry was transitioning to TLS 1.2. Years later, this transition is
	largely complete, and TLS 1.3 is widely available. This document updates the gui
	dance given the new environment and obsoletes RFC 7525. In addition, this docume
	nt updates RFCs 5288 and 6066 in view of recent attacks.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="195"/>
	<seriesInfo name="RFC" value="9325"/>
	<seriesInfo name="DOI" value="10.17487/RFC9325"/>
	</reference>
	</referencegroup>


	<reference anchor='RFC9147' target='https://www.rfc-editor.org/info/rfc9147'>	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
	<front>	47.xml'/>
	<title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>
	<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization />
	</author>
	<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organizatio
	n /></author>
	<author initials='N.' surname='Modadugu' fullname='N. Modadugu'><organization />
	</author>
	<date year='2022' month='April' />
	<abstract><t>This document specifies version 1.3 of the Datagram Transport Layer
	Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communic
	ate over
	the Internet in a way that is designed to prevent eavesdropping, tampering, and
	message
	forgery.
	</t><t>
	The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protoco
	l and
	provides equivalent security guarantees with the exception of order
	protection / non-replayability. Datagram semantics of the underlying transport
	are
	preserved by the DTLS protocol.</t><t>This document obsoletes RFC 6347.
	</t></abstract>
	</front>
	<seriesInfo name='RFC' value='9147'/>
	<seriesInfo name='DOI' value='10.17487/RFC9147'/>
	</reference>

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


	<reference anchor="draft-ietf-tls-rfc8447bis-09">	<!-- [I-D.ietf-tls-rfc8447bis] IESG state: I-D Exists -->
	<front>	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.
	<title>IANA Registry Updates for TLS and DTLS</title>	ietf-tls-rfc8447bis"/>
	<author fullname="Joseph A. Salowey" initials="J. A." surname="Salowey">
	<organization>Venafi</organization>
	</author>
	<author fullname="Sean Turner" initials="S." surname="Turner">
	<organization>sn3rd</organization>
	</author>
	<date day="28" month="March" year="2023"/>
	<abstract>
	<t>This document updates the changes to TLS and DTLS IANA registries made
	in RFC 8447. It adds a new value "D" for discouraged to the recommended column o
	f the selected TLS registries. This document updates the following RFCs: 3749, 5
	077, 4680, 5246, 5705, 5878, 6520, 7301, and 8447.</t>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-tls-rfc8447bis-09"/>
	</reference>


	<reference anchor="draft-ietf-tls-deprecate-obsolete-kex-04" target="https://www	<!-- [I-D.ietf-tls-deprecate-obsolete-kex] IESG state: AD Evaluation::External P
	.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-04.txt">	arty -->
	<front>	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.
	<title>Deprecating Obsolete Key Exchange Methods in TLS</title>	ietf-tls-deprecate-obsolete-kex"/>
	<author fullname="Carrick Bartle" initials="C." surname="Bartle">
	<organization>Apple, Inc.</organization>
	</author>
	<author fullname="Nimrod Aviram" initials="N." surname="Aviram"/>
	<date day="11" month="July" year="2023"/>
	<abstract>
	<t>This document makes several prescriptions regarding the following key e
	xchange methods in TLS, most of which have been superseded by better options:</t
	>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-tls-deprecate-obsolete-kex
	-04"/>
	<format target="https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsol
	ete-kex-04.txt" type="TXT"/>
	</reference>


	<reference anchor="draft-ietf-tls-rfc8446bis-09" target="https://www.ietf.org/ar	<!--[I-D.ietf-tls-rfc8446bis] IESG state: I-D Exists -->
	chive/id/draft-ietf-tls-rfc8446bis-09.txt">	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.
	<front>	ietf-tls-rfc8446bis"/>
	<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
	<author fullname="Eric Rescorla" initials="E." surname="Rescorla">
	<organization>Mozilla</organization>
	</author>
	<date day="7" month="July" year="2023"/>
	<abstract>
	<t>This document specifies version 1.3 of the Transport Layer Security (TL
	S) protocol. TLS allows client/server applications to communicate over the Inter
	net in a way that is designed to prevent eavesdropping, tampering, and message f
	orgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs
	5077, 5246, 6961, and 8446. This document also specifies new requirements for T
	LS 1.2 implementations.</t>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-tls-rfc8446bis-09"/>
	<format target="https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-09.t
	xt" type="TXT"/>
	</reference>

	</references>	</references>
	</references>	</references>


		<section anchor="Acks" numbered="false" toc="default">
		<name>Acknowledgments</name>
		<t>The authors would like to thank <contact fullname="Ari
		jit Kumar Bose"/>, <contact fullname="Steffen Fries"/>, and the
		members of IEC TC57 WG15 for their review, comments, and
		suggestions. The
		authors would also like to thank <contact fullname="Tom P
		etch"/>, <contact fullname="Juergen Schoenwaelder"/>,
		<contact fullname="Hannes Tschofenig"/>, <contact fullnam
		e="Viktor Dukhovni"/>, and the IESG members for their comments
		and constructive feedback.
		</t>
		</section>

	</back>	</back>
	</rfc>	</rfc>

End of changes. 56 change blocks.
	556 lines changed or deleted	198 lines changed or added
This html diff was produced by rfcdiff 1.48.