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

<!-- draft submitted in xml v3 -->

<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

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

 <!-- ***** FRONT MATTER ***** -->

 <front>
   <title abbrev="Cipher Suites in Secure Syslog">Updates to the Cipher Suites in Secure Syslog</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-uta-ciphersuites-in-sec-syslog-07"/> name="RFC" value="9662"/>
    <author fullname="Chris Lonvick" initials="C." surname="Lonvick">
      <address>
        <email>lonvick.ietf@gmail.com</email>
     </address>
    </author>

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

     <author fullname="Joe Salowey" initials="J." surname="Salowey">
       <organization>Venafi</organization>
      <address>
        <email>joe@salowey.net</email>
     </address>
    </author>

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

   <!-- Meta-data Declarations -->

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

    <area>SEC</area>
    <workgroup>uts</workgroup>

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

<!-- [rfced] Abstract: Please consider the following update to improve the flow and readability of the text.

Original:
   The IETF published two specifications, namely RFC 5425 and RFC 6012,
   for securing the Syslog protocol using TLS and DTLS, respectively.

   This document updates the cipher suites in RFC 5425, Transport Layer
   Security (TLS) Transport Mapping for Syslog, and RFC 6012, Datagram
   Transport Layer Security (DTLS) Transport Mapping for Syslog.  It
   also updates the transport protocol in RFC 6012.

Perhaps:
   RFCs 5425 and 6012 describe using TLS and DTLS to securely
   transport syslog messages.  This document updates the
   cipher suites required by RFC 5245 (TLS
   Transport Mapping for Syslog) and RFC 6012
   (DTLS Transport Mapping for Syslog).  It also updates
   the protocol recommended by RFC 6012 for secure datagram transport.
-->

	<abstract>
		<t>
		The IETF published two specifications, namely RFC 5425 and
		RFC 6012, for securing the Syslog protocol using TLS and DTLS, respectively.
		</t><t>
		This document updates the cipher suites in RFC 5425, Transport Layer Security
		(TLS) Transport Mapping for Syslog, and RFC 6012, Datagram Transport Layer
		Security (DTLS) Transport Mapping for Syslog. It also updates the transport
		protocol in RFC 6012.
		</t>
    </abstract>
	</front>
	<middle>
    <section numbered="true" toc="default">
    	<name>Introduction</name>
			<t>
<!-- [rfced] Section 1: If the change to the abstract is accepted, may we update the introduction in a similar manner?

Original:
   The IETF published RFC 5425, Transport Layer Security (TLS) Transport
   Mapping for Syslog, and RFC 6012, Datagram Transport Layer Security
   (DTLS) Transport Mapping for Syslog.
			</t><t>

   Both specifications, [RFC5425] and [RFC6012], require the use of RSA-
   based certificates and the use of TLS/DTLS versions that are not the
   most recent.

Perhaps:
   "Transport Layer Security (TLS) Transport Mapping for Syslog" [RFC5425] and
   "Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog" [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>
			The IETF published RFC 5425, "Transport Layer Security (TLS)
			Transport Mapping for Syslog", and RFC 6012, "Datagram Transport Layer
			Security (DTLS) Transport Mapping for Syslog".
			Both specifications, <xref target="RFC5425" /> and <xref target="RFC6012" />,
			require the use of RSA-based certificates and the use of TLS/DTLS TLS and DTLS versions
			that are not the most recent.
			</t><t>
			<xref target="RFC5425" /> sectionFormat="of" section="4.2"/> requires that implementations "<bcp14>MUST</bcp14>" <bcp14>MUST</bcp14>
			support TLS 1.2 <xref target="RFC5246" /> and are "<bcp14>REQUIRED</bcp14>" <bcp14>REQUIRED</bcp14>
			to support the mandatory to implement mandatory-to-implement cipher suite
			TLS_RSA_WITH_AES_128_CBC_SHA (Section 4.2).
			TLS_RSA_WITH_AES_128_CBC_SHA.
			</t><t>
			<xref target="RFC6012" /> sectionFormat="of" section="5.2"/> requires that implementations "<bcp14>MUST</bcp14>"
			support DTLS 1.0 <xref target="RFC4347" /> and are also
			"<bcp14>REQUIRED</bcp14>" to support the mandatory to implement mandatory-to-implement cipher suite
			TLS_RSA_WITH_AES_128_CBC_SHA (Section 5.2).
			TLS_RSA_WITH_AES_128_CBC_SHA.
			</t><t>
			The community is moving away from cipher suits suites that don't offer forward
			secrecy and towards more robust suites.
			</t><t>
			The DTLS 1.0 transport <xref target="RFC4347" /> has been deprecated by
			RFC 8996 <xref target="BCP195" /> />, and the community is moving to DTLS 1.2
			<xref target="RFC6347" /> and DTLS 1.3 <xref target="RFC9147" />.
			</t><t>
			This document updates <xref target="RFC5425" /> and <xref target="RFC6012" />
			to prefer the use of TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 over the use of
			TLS_RSA_WITH_AES_128_CBC_SHA.
			</t><t>
			This document also updates <xref target="RFC6012" /> to make a recommendation
			of by recommending
			a mandatory to implement mandatory-to-implement secure datagram transport.
			</t>
		</section>

		<section anchor="name-terminology" title="Terminology" anchor="terminology" numbered="true" toc="default">

		  <name>Terminology</name>
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14
			[<xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/>]
			[<xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/>] BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
		</section>

		<section anchor="reasons" title="Support for Updating" numbered="true" toc="default">
		  <name>Support for Updating</name>
			<t>
			<xref target="draft-ietf-tls-rfc8447bis-09" target="I-D.ietf-tls-rfc8447bis" /> generally reminds us that
			cryptographic algorithms and parameters will be broken or weakened over time.
			Blindly implementing the cryptographic algorithms listed in any specification
			is not advised. Implementers and users need to check that the cryptographic
			algorithms specified continue to provide the expected level of security.
			</t><t>
			As the Syslog Working Group determined, Syslog syslog clients and servers
			<bcp14>MUST</bcp14> use certificates as defined in <xref target="RFC5280" />.
			Since both <xref target="RFC5425" /> and <xref target="RFC6012" />
			<bcp14>REQUIRED</bcp14> the use of TLS_RSA_WITH_AES_128_CBC_SHA, it is very
			likely that RSA certificates have been implemented in devices adhering to
			those specifications. RFC 9325 <xref target="BCP195" /> notes that ECDHE cipher suites
			exist for both RSA and ECDSA certificates, so moving to an ECDHE cipher suite
			will not require replacing or moving away from any currently installed
			RSA-based certificates.
			</t><t>
			<xref target="draft-ietf-tls-deprecate-obsolete-kex-04" target="I-D.ietf-tls-deprecate-obsolete-kex" /> documents that the
			cipher suite TLS_RSA_WITH_AES_128_CBC_SHA, along with some other cipher suites,
			may require mitigation techniques to achieve expected security, which may be
			difficult to effectively implement. Along those lines,

RFC 9325 <xref target="BCP195" /> [<xref target="RFC9325" />] notes that
			TLS_RSA_WITH_AES_128_CBC_SHA does not provide forward secrecy, a feature that
			is highly desirable in securing event messages. That document also goes on to
			recommend TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as a cipher suite that does
			provide forward secrecy.
			</t><t>
 			As such, the community is moving away from algorithms that do not provide
 			forward secrecy. For example, the International Electrotechnical Commission
 			(IEC) has selected more robust suites such as
 			TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, which is also listed as a
 			currently RECCOMENDED <bcp14>RECOMMENDED</bcp14> algorithm in
			<xref target="draft-ietf-tls-rfc8447bis-09" target="I-D.ietf-tls-rfc8447bis" /> for their deployments of
			secure syslog.
			</t><t>
			Additionally, RFC 8996 <xref target="BCP195" />
			[<xref target="RFC8996" format="default" />]
			deprecates the use
			of DTLS 1.0 <xref target="RFC4347" />, which is the mandatory to implement mandatory-to-implement
			transport protocol for per <xref target="RFC6012" />. Therefore, the that transport
			protocol for <xref target="RFC6012" /> must be updated.
			</t><t>
			Finally, RFC 9325 <xref target="BCP195" /> (<xref target="RFC9325" />) provides
			guidance on the support of TLS 1.3 <xref target="RFC8446" /> and
			DTLS 1.3 <xref target="RFC9147" />.
			</t><t>
			Therefore, to maintain interoperability across implementations, the mandatory
			to implement mandatory-to-implement cipher suites listed in <xref target="RFC5425" /> and
			<xref target="RFC6012" /> should be updated so that implementations of secure
			syslog will still interoperate and provide an acceptable and expected level
			of security.
			</t><t>
			</t>

<!-- [rfced] Section 3: "REQUIRES" is not a keyword that is defined by RFC 2119 or RFC 8174.  May we rephrase this sentence to use "REQUIRED" instead?

Original:
   To accomodate a migration path, this specification
   will allow the use of both TLS_RSA_WITH_AES_128_CBC_SHA and
   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 but REQUIRES that
   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 be preferred.

Perhaps:
  To accommodate a migration path,
  TLS_RSA_WITH_AES_128_CBC_SHA or
  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 may be used, but it
  is REQUIRED that TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  be preferred.
-->
			<t>
			However, since there are many implementations of syslog using
			the cipher suites mandatated to be used in mandated by <xref target="RFC6012" />, a
			sudden change is not desireable. desirable. To accomodate accommodate a migration path, this
			specification will allow the use of both TLS_RSA_WITH_AES_128_CBC_SHA
			and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 but <bcp14>REQUIRES</bcp14> REQUIRES
			that TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 be preferred.
			</t>
		</section>

		<section anchor="updates5425" title="Updates anchor="updates5425">
		  <name>Updates to RFC 5425"> 5425</name>
			<t>
			The mandatory to implement mandatory-to-implement cipher suites are <bcp14>REQUIRED</bcp14>
			to be TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_AES_128_CBC_SHA.
			</t><t>
			Implementations of <xref target="RFC5425" /> <bcp14>SHOULD</bcp14> offer
			TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 but <bcp14>MAY</bcp14> offer
			TLS_RSA_WITH_AES_128_CBC_SHA.
			</t><t>
			Implementations of <xref target="RFC5425" /> <bcp14>MUST</bcp14> continue to
			use TLS 1.2 <xref target="RFC5246" /> as the mandatory to implement mandatory-to-implement
			transport protocol.
     		       </t><t>
     		       </t>
<t>
			As per RFC 9325 <xref target="BCP195" />, implementations of <xref target="RFC5425" />
			<bcp14>SHOULD</bcp14> support TLS 1.3 <xref target="RFC8446" /> and, if
			implemented, <bcp14>MUST</bcp14> prefer to negotiate TLS 1.3
			over earlier versions of TLS.
 			</t>
		</section>

		<section anchor="updates6012" title="Updates anchor="updates6012">
		  <name>Updates to RFC 6012"> 6012</name>
			<t>
			The mandatory to implement mandatory-to-implement cipher suites are <bcp14>REQUIRED</bcp14> to be
			TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_AES_128_CBC_SHA.
			</t><t>
			Implementations of <xref target="RFC6012" /> <bcp14>SHOULD</bcp14> offer
			TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 but <bcp14>MAY</bcp14> offer
			TLS_RSA_WITH_AES_128_CBC_SHA.
			</t><t>
			</t>
<!-- [rfced] Throughout: Note that where [BCP195] was referenced without mention of a specific RFC, we have added pointers to the specific RFC for ease of the reader.  That is, it is easy for the reader to identify where to look for more information.  Please review to ensure the updates are correct.

For example, we made the following update in Section 4:

Original:
   As per [BCP195], implementations of [RFC5425] SHOULD support TLS 1.3
   [RFC8446] and, if implemented, MUST prefer to negotiate TLS 1.3 over
   earlier versions of TLS.

Current:
   As per RFC 9325 [BCP195], implementations of [RFC5425] SHOULD support
   TLS 1.3 [RFC8446] and, if implemented, MUST prefer to negotiate TLS
   1.3 over earlier versions of TLS.
-->

<t>
			As specified in RFCs 8996 and 9325 <xref target="BCP195" />, implementations of
			<xref target="RFC6012" /> <bcp14>MUST NOT</bcp14> use DTLS 1.0 <xref target="RFC4347" />.
			Implementations <bcp14>MUST</bcp14> use DTLS 1.2 <xref target="RFC6347" />.
			</t><t>
			DTLS 1.2 <xref target="RFC6347" /> implementations <bcp14>SHOULD</bcp14> support
			and prefer the mandatory to implement mandatory-to-implement cipher suite
			TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
			</t><t>
			As per RFC 9325 <xref target="BCP195" />, implementations of <xref target="RFC6012" />
			<bcp14>SHOULD</bcp14> support DTLS 1.3 <xref target="RFC9147" /> and, if
			implemented, <bcp14>MUST</bcp14> prefer to negotiate DTLS version 1.3 over
			earlier versions of DTLS.
 			</t>
		</section>

		<section anchor="earlyData" title="Early Data"> anchor="earlyData">
		  <name>Early Data</name>
			<t>
			Early data (aka 0-RTT data) is a mechanism defined in TLS 1.3
			<xref target="RFC8446" /> that allows a client to send data ("early data") as
			part of the first flight of messages to a server. Early data is permitted by
			TLS 1.3 when the client and server share a PSK, either obtained externally or
			via a previous handshake. The client uses the PSK to authenticate the server
			and to encrypt the early data.
			</t><t>
			As noted in Section 2.3 of <xref target="draft-ietf-tls-rfc8446bis-09" target="I-D.ietf-tls-rfc8446bis" sectionFormat="of" section="2.3" />, the
			security properties for early data are weaker than those for subsequent
			TLS-protected data.  In particular, early data is not forward secret, and
			there are no protections against the replay of early data between
			connections. Appendix E.5 of <xref target="draft-ietf-tls-rfc8446bis-09" target="I-D.ietf-tls-rfc8446bis" sectionFormat="of" section="E.5" />
			requires that applications not use early data without a profile that defines its
			use. Because syslog does not support replay protection, see Section 8.4 of protection (see
			<xref target="RFC5424" />", sectionFormat="of" section="8.4"/>) and most implementations establish a long-lived
			connection, this document specifies that implementations MUST NOT use early
			data.
			</t>
		</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 edits 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, Steffen Fries and the
			members of IEC TC57 WG15 for their review, comments, and suggestions. The
			authors would also like to thank Tom Petch, Juergen Schoenwaelder,
			Hannes Tschofenig, Viktor Dukhovni, and the IESG members for their comments
			and constructive feedback.
			</t>
		</section>

		<section anchor="IANA" numbered="true" toc="default">
			<name>IANA Considerations</name>
<t>This document makes has no requests to IANA.</t> IANA actions.</t>
		</section>
		<section anchor="Security" numbered="true" toc="default">
			<name>Security Considerations</name>
			<t>
			RFCs 8996 and 9325 <xref target="BCP195" /> deprecates deprecate an insecure DTLS transport protocol
			from <xref target="RFC6012" /> and deprecates deprecate insecure cipher suits suites from
			<xref target="RFC5425" /> and <xref target="RFC6012" />. However, the
			installed base of syslog implementations is not easily updated to
			immediately adhere to those changes.
			</t><t>
			This document updates the mandatory to implement mandatory-to-implement cipher suites to allow
			for a migration from TLS_RSA_WITH_AES_128_CBC_SHA to
			TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 without deprecating the former.
			Implementations should prefer to use TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
			</t><t>
			If a device currently only has TLS_RSA_WITH_AES_128_CBC_SHA, an
			administrator of the network should evaluate
			the conditions and determine if TLS_RSA_WITH_AES_128_CBC_SHA should be allowed
			so that syslog messages may continue to be delivered until the device is
			updated to have TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
			</t>
		</section>
  </middle>
  <!--  *****BACK MATTER ***** -->

 <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>
      <name>References</name>
      <references>
        <name>Normative References</name>
	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'/>
	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml'/>
	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5425.xml'/>
	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml'/>
	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5424.xml'/>
	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml'/>
	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml'/>
	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4347.xml'/>
	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6012.xml'/>
	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml'/>

	<referencegroup anchor="BCP14" target="https://www.rfc-editor.org/info/bcp14"> anchor="BCP195" target="https://www.rfc-editor.org/info/bcp195">
	  <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8996.xml'/>
	  <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml'/>
	</referencegroup>

	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml'/>

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

<!-- reference.RFC.2119.xml [I-D.ietf-tls-rfc8447bis] IESG state: I-D Exists -->
<reference  anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<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 Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tls-rfc8447bis"/>

<!-- reference.RFC.8174.xml [I-D.ietf-tls-deprecate-obsolete-kex] IESG state: AD Evaluation::External Party -->
<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 /></author>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</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'><organization /></author>
<author initials='Y.' surname='Ma' fullname='Y. Ma' role='editor'><organization /></author>
<author initials='J.' surname='Salowey' fullname='J. Salowey' role='editor'><organization /></author>
<date year='2009' month='March' />
<abstract><t>This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages. This document describes the security threats
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tls-deprecate-obsolete-kex"/>

<!--[I-D.ietf-tls-rfc8446bis] IESG state: I-D Exists -->
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tls-rfc8446bis"/>

      </references>
    </references>

		<section anchor="Acks" numbered="false" toc="default">
			<name>Acknowledgments</name>
			<t>The authors would like to syslog thank <contact fullname="Arijit Kumar Bose"/>, <contact fullname="Steffen Fries"/>, and how TLS can be used to counter such 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 /></author>
<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 Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5246'/>
<seriesInfo name='DOI' value='10.17487/RFC5246'/>
</reference>

<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 allows the
use of any number of transport protocols for transmission
			members of syslog messages. It also
provides a message format that allows vendor-specific extensions to be provided in a
structured way.&lt;/t>&lt;t> This document has been written with the original design
goals for traditional syslog in mind. The need for a new layered specification has
arisen because standardization efforts IEC TC57 WG15 for reliable and secure syslog extensions suffer
from the lack of a Standards-Track and transport-independent RFC. Without this document,
each other standard needs to define its own syslog packet format their review, comments, and transport mechanism,
which over time will introduce subtle compatibility issues. This document tries to
provide a foundation that syslog extensions can build on. This layered architecture
approach suggestions. The
			authors would also provides a solid basis that allows code to be written once for each syslog
feature rather than once for each transport. [STANDARDS-TRACK]</t></abstract></front>
<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 like to prevent eavesdropping, tampering, and message forgery.</t><t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, thank <contact fullname="Tom Petch"/>, <contact fullname="Juergen Schoenwaelder"/>,
			<contact fullname="Hannes Tschofenig"/>, <contact fullname="Viktor Dukhovni"/>, 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 IESG members for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol their comments
			and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by constructive feedback.
			</t>
		</section>

<!-- [rfced] Please review 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 "Inclusive Language" portion of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and provides equivalent security guarantees.  Datagram semantics of the underlying transport let us know if any changes 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</title>
<author initials='J.' surname='Salowey' fullname='J. Salowey'><organization /></author>
<author initials='T.' surname='Petch' fullname='T. Petch'><organization /></author>
<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 Datagram Transport Layer Security (DTLS) protocol.  It provides a secure transport for syslog messages in cases where a connectionless transport is desired.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6012'/>
<seriesInfo name='DOI' value='10.17487/RFC6012'/>
</reference>

<reference  anchor='RFC5280' target='https://www.rfc-editor.org/info/rfc5280'>
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials='D.' surname='Cooper' fullname='D. Cooper'><organization /></author>
<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 /></author>
<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 certificate revocation list (CRL) for use in the Internet.  An overview needed.  Updates of this approach and model is provided as an introduction.  The X.509 v3 certificate format is described nature typically
result 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 extensions is specified.  The X.509 v2 CRL format more precise language, which is described in detail along with standard and Internet-specific extensions.  An algorithm helpful for X.509 certification path validation is described.  An ASN.1 module and examples are provided in the appendices.  [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) versions 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 recommended 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 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance. </t><t>This 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 readers.

Note that normatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage our script did not flag any words in RFC 7525; hence, it is 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 (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases.</t>
      <t>RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, particular, but this document updates RFCs 5288 and 6066 in view of recent attacks.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="195"/>
  <seriesInfo name="RFC" value="9325"/>
  <seriesInfo name="DOI" value="10.17487/RFC9325"/>
</reference>
</referencegroup>

<reference  anchor='RFC9147' target='https://www.rfc-editor.org/info/rfc9147'>
<front>
<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'><organization /></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 communicate 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 protocol 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>
        <name>Informative References</name>

<reference anchor="draft-ietf-tls-rfc8447bis-09">
  <front>
    <title>IANA Registry Updates for TLS and DTLS</title>
    <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 of the selected TLS registries. This document updates the following RFCs: 3749, 5077, 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.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-04.txt">
  <front>
    <title>Deprecating Obsolete Key Exchange Methods in TLS</title>
    <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 exchange 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-obsolete-kex-04.txt" type="TXT"/>
</reference>

<reference anchor="draft-ietf-tls-rfc8446bis-09" target="https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-09.txt">
  <front>
    <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 (TLS) protocol. TLS allows client/server applications to communicate over the Internet in should
still be reviewed as a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, and 8446. This document also specifies new requirements for TLS 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.txt" type="TXT"/>
</reference>

      </references>
    </references> best practice.
-->

 </back>
</rfc>