rfc9850.original.xml		rfc9850.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='UTF-8'?>
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4.		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	4) -->		-ietf-tls-keylogfile-05" number="9850" updates="" obsoletes="" xml:lang="en" cat
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft		egory="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="
	-ietf-tls-keylogfile-05" category="info" consensus="true" submissionType="IETF"		true" symRefs="true" version="3">
	tocInclude="true" sortRefs="true" symRefs="true" version="3">
	<!-- xml2rfc v2v3 conversion 3.28.1 -->
	<front>		<front>
	<title abbrev="SSLKEYLOGFILE">The SSLKEYLOGFILE Format for TLS</title>		<title abbrev="SSLKEYLOGFILE">The SSLKEYLOGFILE Format for TLS</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-tls-keylogfile-05"/>		<seriesInfo name="RFC" value="9850"/>
	<author fullname="Martin Thomson">		<author fullname="Martin Thomson">
	<organization>Mozilla</organization>		<organization>Mozilla</organization>
	<address>		<address>
	<email>mt@lowentropy.net</email>		<email>mt@lowentropy.net</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Yaroslav Rosomakho">		<author fullname="Yaroslav Rosomakho">
	<organization>Zscaler</organization>		<organization>Zscaler</organization>
	<address>		<address>
	<email>yrosomakho@zscaler.com</email>		<email>yrosomakho@zscaler.com</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Hannes Tschofenig">		<author fullname="Hannes Tschofenig">
	<organization abbrev="H-BRS">University of Applied Sciences Bonn-Rhein-Sie g</organization>		<organization abbrev="H-BRS">University of Applied Sciences Bonn-Rhein-Sie g</organization>
	<address>		<address>
	<email>Hannes.Tschofenig@gmx.net</email>		<email>Hannes.Tschofenig@gmx.net</email>
	</address>		</address>
	</author>		</author>
	<date year="2025" month="June" day="09"/>		<date year="2025" month="December"/>
	<area>Security</area>		<area>SEC</area>
	<workgroup>Transport Layer Security</workgroup>		<workgroup>tls</workgroup>
	<keyword>network transparency</keyword>		<keyword>network transparency</keyword>
	<keyword>tls</keyword>		<keyword>tls</keyword>
	<keyword>blockchain</keyword>		<keyword>blockchain</keyword>
	<abstract>		<abstract>
	<?line 47?>		<t>This document describes a format that supports logging information about the
			secrets used in a TLS
	<t>A format that supports logging information about the secrets used in a TLS		connection. Recording secrets to a file in SSLKEYLOGFILE format
	connection is described. Recording secrets to a file in SSLKEYLOGFILE format
	allows diagnostic and logging tools that use this file to decrypt messages		allows diagnostic and logging tools that use this file to decrypt messages
	exchanged by TLS endpoints. This format is intended for use in systems where		exchanged by TLS endpoints. This format is intended for use in systems where
	TLS only protects test data.</t>		TLS only protects test data.</t>
	</abstract>		</abstract>
	<note removeInRFC="true">
	<name>About This Document</name>
	<t>
	The latest revision of this draft can be found at <eref target="https://
	tlswg.github.io/sslkeylogfile/draft-ietf-tls-keylogfile.html"/>.
	Status information for this document may be found at <eref target="https
	://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/"/>.
	</t>
	<t>
	Discussion of this document takes place on the
	Transport Layer Security Working Group mailing list (<eref target="mailt
	o:tls@ietf.org"/>),
	which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
	wse/tls/"/>.
	Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/tls/"/>
	.
	</t>
	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://github.com/tlswg/sslkeylogfile"/>.</t>
	</note>
	</front>		</front>
	<middle>		<middle>
	<?line 56?>
	<section anchor="introduction">		<section anchor="introduction">
	<name>Introduction</name>		<name>Introduction</name>
	<t>Debugging or analyzing protocols can be challenging when TLS <xref targ et="TLS13"/> is used		<t>Debugging or analyzing protocols can be challenging when TLS <xref targ et="RFC9846"/> is used
	to protect the content of communications. Inspecting the content of encrypted		to protect the content of communications. Inspecting the content of encrypted
	messages in diagnostic tools can enable more thorough analysis.</t>		messages in diagnostic tools can enable more thorough analysis.</t>
	<t>Over time, multiple TLS implementations have informally adopted a file format		<t>Over time, multiple TLS implementations have informally adopted a file format
	for logging the secret values generated by the TLS key schedule. In many		for logging the secret values generated by the TLS key schedule. In many
	implementations, the file that the secrets are logged to is specified in an		implementations, the file that the secrets are logged to is specified in an
	environment variable named "SSLKEYLOGFILE", hence the name of SSLKEYLOGFILE		environment variable named "SSLKEYLOGFILE", hence the name of SSLKEYLOGFILE
	format. Note the use of "SSL" as this convention originally predates the		format. Note the use of "SSL" as this convention originally predates the
	adoption of TLS as the name of the protocol.</t>		adoption of TLS as the name of the protocol.</t>
	<t>This document describes the SSLKEYLOGFILE format. This format can be u sed for		<t>This document describes the SSLKEYLOGFILE format. This format can be u sed for
	TLS 1.2 <xref target="TLS12"/> and TLS 1.3 <xref target="TLS13"/>. The format a lso		TLS 1.2 <xref target="RFC5246"/> and TLS 1.3 <xref target="RFC9846"/>. The form at also
	supports earlier TLS versions, though use of earlier versions is strongly discou raged		supports earlier TLS versions, though use of earlier versions is strongly discou raged
	<xref target="RFC8996"/><xref target="RFC9325"/>. This format can also be used		<xref target="RFC8996"/> <xref target="RFC9325"/>. This format can also be used
	with DTLS <xref target="DTLS13"/>, QUIC		with DTLS <xref target="RFC9147"/>, QUIC
	<xref target="RFC9000"/><xref target="RFC9001"/>, and other protocols that also		<xref target="RFC9000"/> <xref target="RFC9001"/>, and other protocols that use
	use the TLS key		the TLS key
	schedule. Use of this format could complement other protocol-specific logging		schedule. Use of this format could complement other protocol-specific logging
	such as QLOG <xref target="QLOG"/>.</t>		such as qlog <xref target="I-D.ietf-quic-qlog-main-schema"/>.</t>
	<t>This document also defines labels that can be used to log information		<t>This document also defines labels that can be used to log information
	about exchanges that use Encrypted Client Hello (ECH) <xref target="ECH"/>.</t>		about exchanges that use Encrypted Client Hello (ECH) <xref target="RFC9849"/>.< /t>
	<section anchor="applicability-statement">		<section anchor="applicability-statement">
	<name>Applicability Statement</name>		<name>Applicability Statement</name>
	<t>The artifact that this document describes - if made available to enti		<t>The artifact that this document describes -- if made available to ent
	ties other		ities other
	than endpoints - completely undermines the core guarantees that TLS provides.		than endpoints -- completely undermines the core guarantees that TLS provides.
	This format is intended for use in systems where TLS only protects test data.		This format is intended for use in systems where TLS only protects test data.
	While the access that this information provides to TLS connections can be useful		While the access that this information provides to TLS connections can be useful
	for diagnosing problems while developing systems, this mechanism <bcp14>MUST NOT </bcp14> be		for diagnosing problems while developing systems, this mechanism <bcp14>MUST NOT </bcp14> be
	used in a production system. For software that is compiled, use of conditional		used in a production system. For software that is compiled, use of conditional
	compilation is the best way to ensure that deployed binaries cannot be		compilation is the best way to ensure that deployed binaries cannot be
	configured to enable key logging.</t>		configured to enable key logging.</t>
	<t><xref target="security"/> addresses a number of additional concerns t hat arise from the use		<t><xref target="security"/> addresses a number of additional concerns t hat arise from the use
	of key logging.</t>		of key logging.</t>
	</section>		</section>
	<section anchor="conventions-and-definitions">		<section anchor="conventions-and-definitions">
	<name>Conventions and Definitions</name>		<name>Conventions</name>
	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp		<t>
	14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	nterpreted as		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and		to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
	only when, they		<xref target="RFC8174"/> when, and only when, they appear in all capitals,
	appear in all capitals, as shown here.</t>		as shown here.
	<?line -18?>		</t>
			</section>
	</section>
	</section>		</section>
	<section anchor="the-sslkeylogfile-format">		<section anchor="the-sslkeylogfile-format">
	<name>The SSLKEYLOGFILE Format</name>		<name>The SSLKEYLOGFILE Format</name>
	<t>A file in SSLKEYLOGFILE format is a text file. This document specifies the		<t>A file in SSLKEYLOGFILE format is a text file. This document specifies the
	character encoding as UTF-8 <xref target="RFC3629"/>. Though the format itself only		character encoding as UTF-8 <xref target="RFC3629"/>. Though the format itself only
	includes ASCII characters <xref target="RFC0020"/>, comments <bcp14>MAY</bcp14> contain other characters.		includes ASCII characters <xref target="RFC0020"/>, comments <bcp14>MAY</bcp14> contain other characters.
	Though Unicode is permitted in comments, the file <bcp14>MUST NOT</bcp14> contai n a Unicode		Though Unicode is permitted in comments, the file <bcp14>MUST NOT</bcp14> contai n a Unicode
	byte order mark (U+FEFF).</t>		byte order mark (U+FEFF).</t>
	<t>Lines are terminated using the line ending convention of the platform o n which		<t>Lines are terminated using the line-ending convention of the platform o n which
	the file is generated. Tools that process these files <bcp14>MUST</bcp14> accep t CRLF (U+13		the file is generated. Tools that process these files <bcp14>MUST</bcp14> accep t CRLF (U+13
	followed by U+10), CR (U+13), or LF (U+10) as a line terminator. Lines are		followed by U+10), CR (U+13), or LF (U+10) as a line terminator. Lines are
	ignored if they are empty or if the first character is an octothorpe character		ignored if they are empty or if the first character is an octothorpe character
	('#', U+23). Other lines of the file each contain a single secret.</t>		('#', U+23). Other lines of the file each contain a single secret.</t>
	<t>Implementations that record secrets to a file do so continuously as tho se		<t>Implementations that record secrets to a file do so continuously as tho se
	secrets are generated.</t>		secrets are generated.</t>
	<t>Each secret is described using a single line composed of three values t hat are		<t>Each secret is described using a single line composed of three values t hat are
	separated by a single space character (U+20). These values are:</t>		separated by a single space character (U+20). These values are:</t>
	<dl>
			<!-- [rfced] Sections 2.2 and 2.3 also include descriptions of labels defined
			in this document. Should these sections also be mentioned in this
			sentence?
			Original:
			The label identifies the type of secret that is being conveyed;
			see Section 2.1 for a description of the labels that are defined
			in this document.
			Perhaps:
			The label identifies the type of secret that is being conveyed;
			see Sections 2.1, 2.2, and 2.3 for descriptions of the labels that are define
			d
			in this document.
			-->
			<dl spacing="normal" newline="true">
	<dt>label:</dt>		<dt>label:</dt>
	<dd>		<dd>
	<t>The label identifies the type of secret that is being conveyed; see <xref target="labels"/>		<t>The label identifies the type of secret that is being conveyed; see <xref target="labels"/>
	for a description of the labels that are defined in this document.</t>		for descriptions of the labels that are defined in this document.</t>
	</dd>		</dd>
	<dt>client_random:</dt>		<dt>client_random:</dt>
	<dd>		<dd>
	<t>The 32-byte value of the Random field from the ClientHello message that		<t>The 32-byte value of the Random field from the ClientHello message that
	established the TLS connection. This value is encoded as 64 hexadecimal		established the TLS connection. This value is encoded as 64 hexadecimal
	characters. In a log that can include secrets from multiple connections, this		characters. In a log that can include secrets from multiple connections, this
	field can be used to identify a connection.</t>		field can be used to identify a connection.</t>
	</dd>		</dd>
	<dt>secret:</dt>		<dt>secret:</dt>
	<dd>		<dd>
	<t>The value of the identified secret for the identified connection. This value		<t>The value of the identified secret for the identified connection. This value
	is encoded in hexadecimal, with a length that depends on the size of the		is encoded in hexadecimal, with a length that depends on the size of the
	secret.</t>		secret.</t>
	</dd>		</dd>
	</dl>		</dl>
	<t>For the hexadecimal values of the <tt>client_random</tt> or <tt>secret<		<t>For the hexadecimal values of <tt>client_random</tt> or <tt>secret</tt>
	/tt>, no convention		, no convention
	exists for the case of characters 'a' through 'f' (or 'A' through 'F'). Files		exists for the case of characters "a" through "f" (or "A" through "F"). Files
	can be generated with either, so either form <bcp14>MUST</bcp14> be accepted whe n processing a		can be generated with either, so either form <bcp14>MUST</bcp14> be accepted whe n processing a
	file.</t>		file.</t>
	<t>Diagnostic tools that accept files in this format might choose to ignor e lines		<t>Diagnostic tools that accept files in this format might choose to ignor e lines
	that do not conform to this format in the interest of ensuring that secrets can		that do not conform to this format in the interest of ensuring that secrets can
	be obtained from corrupted files.</t>		be obtained from corrupted files.</t>
	<t>Logged secret values are not annotated with the cipher suite or other c onnection		<t>Logged secret values are not annotated with the cipher suite or other c onnection
	parameters. A record of the TLS handshake might therefore be needed to use the		parameters. Therefore, a record of the TLS handshake might be needed to use the
	logged secrets.</t>		logged secrets.</t>
	<section anchor="labels">		<section anchor="labels">
	<name>Secret Labels for TLS 1.3</name>		<name>Secret Labels for TLS 1.3</name>
			<!--[rfced] Is "the Random" correct here, or should this be updated to "the
			Random field" or "the value of the Random field"?
			Original:
			If ECH was
			successfully negotiated for a given connection, these labels MUST be
			followed by the Random from the Inner ClientHello. Otherwise, the
			Random from the Outer ClientHello MUST be used.
			...
			These labels MUST always use the Random from the Outer ClientHello.
			Perhaps:
			If ECH was
			successfully negotiated for a given connection, these labels MUST be
			followed by the Random field from the Inner ClientHello. Otherwise, the
			Random field from the Outer ClientHello MUST be used.
			...
			These labels MUST always use the Random field from the Outer ClientHello.
			-->
	<t>An implementation of TLS 1.3 produces a number of values as part of t he key		<t>An implementation of TLS 1.3 produces a number of values as part of t he key
	schedule (see <xref section="7.1" sectionFormat="of" target="TLS13"/>). If ECH w as successfully negotiated for a		schedule (see <xref section="7.1" sectionFormat="of" target="RFC9846"/>). If ECH was successfully negotiated for a
	given connection, these labels <bcp14>MUST</bcp14> be followed by the Random fro m the Inner ClientHello.		given connection, these labels <bcp14>MUST</bcp14> be followed by the Random fro m the Inner ClientHello.
	Otherwise, the Random from the Outer ClientHello <bcp14>MUST</bcp14> be used.</t >		Otherwise, the Random from the Outer ClientHello <bcp14>MUST</bcp14> be used.</t >
	<t>Each of the following labels correspond to the equivalent secret prod
	uced by the key schedule:</t>		<t>Each of the following labels correspond to the equivalent secret produced by
	<dl newline="true">		the key schedule:</t>
			<dl spacing="normal" newline="true">
	<dt>CLIENT_EARLY_TRAFFIC_SECRET:</dt>		<dt>CLIENT_EARLY_TRAFFIC_SECRET:</dt>
	<dd>		<dd>
	<t>This secret is used to protect records sent by the client as earl y data, if		<t>This secret is used to protect records sent by the client as earl y data, if
	early data is attempted by the client. Note that a server that rejects early		early data is attempted by the client. Note that a server that rejects early
	data will not log this secret, though a client that attempts early data can do		data will not log this secret, though a client that attempts early data can do
	so unconditionally.</t>		so unconditionally.</t>
	</dd>		</dd>
	<dt>EARLY_EXPORTER_SECRET:</dt>		<dt>EARLY_EXPORTER_SECRET:</dt>
	<dd>		<dd>
	<t>This secret is used for early exporters. Like the		<t>This secret is used for early exporters. Like
	CLIENT_EARLY_TRAFFIC_SECRET, this is only generated when early data is		CLIENT_EARLY_TRAFFIC_SECRET, this is only generated when early data is
	attempted and might not be logged by a server if early data is rejected.</t>		attempted and might not be logged by a server if early data is rejected.</t>
	</dd>		</dd>
	<dt>CLIENT_HANDSHAKE_TRAFFIC_SECRET:</dt>		<dt>CLIENT_HANDSHAKE_TRAFFIC_SECRET:</dt>
	<dd>		<dd>
	<t>This secret is used to protect handshake records sent by the clie nt.</t>		<t>This secret is used to protect handshake records sent by the clie nt.</t>
	</dd>		</dd>
	<dt>SERVER_HANDSHAKE_TRAFFIC_SECRET:</dt>		<dt>SERVER_HANDSHAKE_TRAFFIC_SECRET:</dt>
	<dd>		<dd>
	<t>This secret is used to protect handshake records sent by the serv er.</t>		<t>This secret is used to protect handshake records sent by the serv er.</t>
	skipping to change at line 200 ¶		skipping to change at line 224 ¶
	<tt>client_application_traffic_secret_0</tt> in the TLS 1.3 key schedule.</t>		<tt>client_application_traffic_secret_0</tt> in the TLS 1.3 key schedule.</t>
	</dd>		</dd>
	<dt>SERVER_TRAFFIC_SECRET_0:</dt>		<dt>SERVER_TRAFFIC_SECRET_0:</dt>
	<dd>		<dd>
	<t>This secret is used to protect application_data records sent by t he server		<t>This secret is used to protect application_data records sent by t he server
	immediately after the handshake completes. This secret is identified as		immediately after the handshake completes. This secret is identified as
	<tt>server_application_traffic_secret_0</tt> in the TLS 1.3 key schedule.</t>		<tt>server_application_traffic_secret_0</tt> in the TLS 1.3 key schedule.</t>
	</dd>		</dd>
	<dt>EXPORTER_SECRET:</dt>		<dt>EXPORTER_SECRET:</dt>
	<dd>		<dd>
	<t>This secret is used in generating exporters <xref section="7.5" s ectionFormat="of" target="TLS13"/>.</t>		<t>This secret is used in generating exporters (<xref section="7.5" sectionFormat="of" target="RFC9846"/>).</t>
	</dd>		</dd>
	</dl>		</dl>
	<t>These labels all appear in uppercase in the key log, but they corresp ond to		<t>These labels all appear in uppercase in the key log, but they corresp ond to
	lowercase labels in the TLS key schedule (<xref section="7.1" sectionFormat="of" target="TLS13"/>), except for		lowercase labels in the TLS key schedule (<xref section="7.1" sectionFormat="of" target="RFC9846"/>), except for
	the application data secrets as noted. For example, "EXPORTER_SECRET" in the		the application data secrets as noted. For example, "EXPORTER_SECRET" in the
	log file corresponds to the secret named <tt>exporter_secret</tt>.</t>		log file corresponds to the secret named <tt>exporter_secret</tt>.</t>
	<t>Note that the order that labels appear here corresponds to the order in which		<t>Note that the order that labels appear here corresponds to the order in which
	they are presented in <xref target="TLS13"/>, but there is no guarantee that imp lementations		they are presented in <xref target="RFC9846"/>, but there is no guarantee that i mplementations
	will log secrets strictly in this order.</t>		will log secrets strictly in this order.</t>
	</section>		</section>
	<section anchor="secret-labels-for-tls-12">		<section anchor="secret-labels-for-tls-12">
	<name>Secret Labels for TLS 1.2</name>		<name>Secret Labels for TLS 1.2</name>
	<t>Implementations of TLS 1.2 <xref target="TLS12"/> (and also earlier v ersions) use the		<t>Implementations of TLS 1.2 <xref target="RFC5246"/> (and also earlier versions) use the
	label "CLIENT_RANDOM" to identify the "master" secret for the connection.</t>		label "CLIENT_RANDOM" to identify the "master" secret for the connection.</t>
	</section>		</section>
	<section anchor="secret-labels-for-ech">		<section anchor="secret-labels-for-ech">
	<name>Secret Labels for ECH</name>		<name>Secret Labels for ECH</name>
	<t>With ECH <xref target="ECH"/>, additional secrets are derived		<t>With ECH <xref target="RFC9849"/>, additional secrets are derived
	during the handshake to encrypt the Inner ClientHello message using Hybrid Publi c		during the handshake to encrypt the Inner ClientHello message using Hybrid Publi c
	Key Encryption (HPKE) <xref target="HPKE"/>. A client can log the ECH labels des		Key Encryption (HPKE) <xref target="RFC9180"/>. A client can log the ECH labels
	cribed below		described below
	if it offered ECH regardless of server acceptance. The server can log the labels		if it offered ECH, regardless of server acceptance. The server can log the label
	only if it		s only if it
	successfully decrypted the ECH offered by the client, though it could choose to do so		successfully decrypted the ECH offered by the client, though it could choose to do so
	only when it accepts ECH.</t>		only when it accepts ECH.</t>
	<t>These labels <bcp14>MUST</bcp14> always use the Random from the Outer ClientHello.</t>		<t>These labels <bcp14>MUST</bcp14> always use the Random from the Outer ClientHello.</t>
	<dl>		<dl spacing="normal" newline="true">
	<dt>ECH_SECRET:</dt>		<dt>ECH_SECRET:</dt>
	<dd>		<dd>
	<t>This label corresponds to the KEM shared secret used by HPKE		<t>This label corresponds to the Key Encapsulation Mechanism (KEM) s
	(<tt>shared_secret</tt> in the algorithms in <xref section="5.1.1" sectionFormat		hared secret used by HPKE
	="of" target="HPKE"/>).		(<tt>shared_secret</tt> in the algorithms in <xref section="5.1.1" sectionFormat
	Length of the secret is defined by the KEM negotiated for use with ECH.</t>		="of" target="RFC9180"/>).
			The length of the secret is defined by the KEM negotiated for use with ECH.</t>
	</dd>		</dd>
	<dt>ECH_CONFIG:</dt>		<dt>ECH_CONFIG:</dt>
	<dd>		<dd>
	<t>The ECHConfig used to construct the ECH extension. The value is l ogged		<t>The ECHConfig used to construct the ECH extension. The value is l ogged
	in hexadecimal representation.</t>		in hexadecimal representation.</t>
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	</section>		</section>
	<section anchor="security">		<section anchor="security">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>Access to the content of a file in SSLKEYLOGFILE format allows an attac ker to		<t>Access to the content of a file in SSLKEYLOGFILE format allows an attac ker to
	break the confidentiality and integrity protection on any TLS connections that		break the confidentiality and integrity protection on any TLS connections that
	are included in the file. This includes both active connections and connections		are included in the file. This includes both active connections and connections
	for which encrypted records were previously stored. Ensuring adequate access		for which encrypted records were previously stored. Therefore, ensuring adequat
	control on these files therefore becomes very important.</t>		e access
			control on these files becomes very important.</t>
	<t>Implementations that support logging this data need to ensure that logg ing can		<t>Implementations that support logging this data need to ensure that logg ing can
	only be enabled by those who are authorized. Allowing logging to be initiated		only be enabled by those who are authorized. Allowing logging to be initiated
	by any entity that is not otherwise authorized to observe or modify the content		by any entity that is not otherwise authorized to observe or modify the content
	of connections for which secrets are logged could represent a privilege		of connections for which secrets are logged could represent a privilege
	escalation attack. Implementations that enable logging also need to ensure that		escalation attack. Implementations that enable logging also need to ensure that
	access to logged secrets is limited, using appropriate file permissions or		access to logged secrets is limited, using appropriate file permissions or
	equivalent access control mechanisms.</t>		equivalent access control mechanisms.</t>
	<t>In order to support decryption, the secrets necessary to remove record		<t>In order to support decryption, the secrets necessary to remove record
	protection are logged. However, as the keys that can be derived from these		protection are logged. However, as the keys that can be derived from these
	secrets are symmetric, an adversary with access to these secrets is also able to		secrets are symmetric, an adversary with access to these secrets is also able to
	encrypt data for an active connection. This might allow for injection or		encrypt data for an active connection. This might allow for injection or
	modification of application data on a connection that would otherwise be		modification of application data on a connection that would otherwise be
	protected by TLS.</t>		protected by TLS.</t>
			<!-- [rfced] Would updating "(e.g., [RFC8471])" and "(e.g., [RFC9261])" as
			follows be more precise and clear? Please review.
			Original:
			For instance, exporters might be used for session
			bindings (e.g., [RFC8471]), authentication (e.g., [RFC9261]), or
			other derived secrets that are used in application context.
			Perhaps:
			For instance, exporters might be used for session
			bindings (e.g., in the Token Binding protocol [RFC8471]),
			authentication (e.g., in the mechanism defined in [RFC9261]), or
			other derived secrets that are used in application context.
			-->
	<t>As some protocols rely on TLS for generating encryption keys, the SSLKE YLOGFILE		<t>As some protocols rely on TLS for generating encryption keys, the SSLKE YLOGFILE
	format includes keys that identify the secret used in TLS exporters or early		format includes keys that identify the secret used in TLS exporters or early
	exporters (<xref section="7.5" sectionFormat="of" target="TLS13"/>). Knowledge of these secrets can enable		exporters (<xref section="7.5" sectionFormat="of" target="RFC9846"/>). Knowledg e of these secrets can enable
	more than inspection or modification of encrypted data, depending on how an		more than inspection or modification of encrypted data, depending on how an
	application protocol uses exporters. For instance, exporters might be used for		application protocol uses exporters. For instance, exporters might be used for
	session bindings (e.g., <xref target="RFC8471"/>), authentication (e.g., <xref t arget="RFC9261"/>), or		session bindings (e.g., <xref target="RFC8471"/>), authentication (e.g., <xref t arget="RFC9261"/>), or
	other derived secrets that are used in application context. An adversary that		other derived secrets that are used in application context. An adversary that
	obtains these secrets might be able to use this information to attack these		obtains these secrets might be able to use this information to attack these
	applications. A TLS implementation might either choose to omit these secrets in		applications. A TLS implementation might either choose to omit these secrets in
	contexts where the information might be abused or require separate		contexts where the information might be abused or require separate
	authorization to enable logging of exporter secrets.</t>		authorization to enable logging of exporter secrets.</t>
	<t>Using an environment variable, such as <tt>SSLKEYLOGFILE</tt>, to enabl e logging		<t>Using an environment variable, such as <tt>SSLKEYLOGFILE</tt>, to enabl e logging
	implies that access to the launch context for the application is needed to		implies that access to the launch context for the application is needed to
	authorize logging. On systems that support specially-named files, logs might be		authorize logging. On systems that support specially named files, logs might be
	directed to these names so that logging does not result in storage, but enable		directed to these names so that logging does not result in storage but enables
	consumption by other programs. In both cases, applications might require		consumption by other programs. In both cases, applications might require
	special authorization or they might rely on system-level access control to limit		special authorization or might rely on system-level access control to limit
	access to these capabilities.</t>		access to these capabilities.</t>
			<!--[rfced] We have some questions about the citations and section pointers in
			the sentence below.
			a) RFC-to-be 9846 (draft-ietf-tls-rfc8446bis), which uses the citation [TLS13]
			in this document, obsoletes RFC 8446. Should the citation to [RFC8446] in this
			sentence be updated to [TLS13] and the reference entry for [RFC8446] be
			removed? Also, note that Section 1.2 and Appendix E.1 in RFC 8446 seem to
			align with Section 1.3 and Appendix F.1 of RFC-to-be 9846
			(draft-ietf-tls-rfc8446bis). Please confirm.
			b) RFC 4492 has been obsoleted by RFC 8422. We recommend replacing [RFC4492]
			with [RFC8422] in this sentence. If this change is made, the section pointers
			will also likely need to be updated. Sections 2.2 and 2.4 in RFC 4492 seem to
			align with Sections 2.1 and 2.2 in RFC 8422. Please review.
			(If RFC 4492 must be referenced, we suggest mentioning RFC 8422 (e.g., RFC
			4492 has been obsoleted by RFC 8422) per Section 4.8.6 in the RFC Style Guide
			(RFC 7322).)
			Original:
			Forward secrecy guarantees provided in TLS 1.3 (see Section 1.2 and
			Appendix E.1 of [RFC8446]) and some modes of TLS 1.2 (such as those
			in Sections 2.2 and 2.4 of [RFC4492]) do not hold if key material is
			recorded.
			Perhaps:
			Forward secrecy guarantees provided in TLS 1.3 (see Section 1.3 and
			Appendix F.1 of [TLS13]) and some modes of TLS 1.2 (such as those
			in Sections 2.1 and 2.2 of [RFC8422]) do not hold if key material is
			recorded.
			-->
	<t>Forward secrecy guarantees provided in TLS 1.3 (see Section <xref targe t="RFC8446" section="1.2" sectionFormat="bare"/> and Appendix <xref target="RFC8 446" section="E.1" sectionFormat="bare"/> of <xref target="RFC8446"/>) and some modes of TLS 1.2 (such as those in Sections <xref target="RFC4492" section="2.2" sectionFormat="bare"/> and <xref target="RFC4492" section="2.4" sectionFormat=" bare"/> of <xref target="RFC4492"/>) do not hold if key material is recorded. A ccess to key		<t>Forward secrecy guarantees provided in TLS 1.3 (see Section <xref targe t="RFC8446" section="1.2" sectionFormat="bare"/> and Appendix <xref target="RFC8 446" section="E.1" sectionFormat="bare"/> of <xref target="RFC8446"/>) and some modes of TLS 1.2 (such as those in Sections <xref target="RFC4492" section="2.2" sectionFormat="bare"/> and <xref target="RFC4492" section="2.4" sectionFormat=" bare"/> of <xref target="RFC4492"/>) do not hold if key material is recorded. A ccess to key
	material allows an attacker to decrypt data exchanged in any previously logged T LS		material allows an attacker to decrypt data exchanged in any previously logged T LS
	connections.</t>		connections.</t>
	<t>Logging the TLS 1.2 "master" secret provides the recipient of that secr et far		<t>Logging the TLS 1.2 "master" secret provides the recipient of that secr et far
	greater access to an active connection than TLS 1.3 secrets. In addition to		greater access to an active connection than TLS 1.3 secrets provide. In additio n to
	reading and altering protected messages, the TLS 1.2 "master" secret confers the		reading and altering protected messages, the TLS 1.2 "master" secret confers the
	ability to resume the connection and impersonate either endpoint, insert records		ability to resume the connection and impersonate either endpoint, insert records
	that result in renegotiation, and forge Finished messages. Implementations can		that result in renegotiation, and forge Finished messages. Implementations can
	avoid the risks associated with these capabilities by not logging this secret		avoid the risks associated with these capabilities by not logging this secret
	value.</t>		value.</t>
	<t>Access to the ECH_SECRET record in the SSLKEYLOGFILE allows the attacke r to decrypt		<t>Access to the ECH_SECRET record in SSLKEYLOGFILE allows the attacker to decrypt
	the ECH extension and thereby reveal the content of the Inner ClientHello messag e,		the ECH extension and thereby reveal the content of the Inner ClientHello messag e,
	including the payload of the Server Name Indication (SNI) extension.</t>		including the payload of the Server Name Indication (SNI) extension.</t>
	<t>Access to the HPKE-established shared secret used in ECH introduces a p otential		<t>Access to the HPKE-established shared secret used in ECH introduces a p otential
	attack surface against the HPKE library since access to this keying material		attack surface against the HPKE library since access to this keying material
	is normally not available otherwise.</t>		is normally not available otherwise.</t>
	</section>		</section>
	<section anchor="iana-considerations">		<section anchor="iana-considerations">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>This document registers a media type (<xref target="iana-media"/>)		<t>This document registers a media type (<xref target="iana-media"/>)
	and creates a registry for labels (<xref target="iana-labels-registry"/>).</t>		and creates a registry for labels (<xref target="iana-labels-registry"/>).</t>
	<section anchor="iana-media">		<!-- [rfced] IANA Considerations section
			a) Section 4.1: FYI - We made a minor change (i.e., added a period) to the
			media type template. If no objections, we will ask IANA to update the template
			at https://www.iana.org/assignments/media-types/application/sslkeylogfile
			accordingly prior to publication.
			b) Section 4.2: Please review the suggestions below for the description of
			EARLY_EXPORTER_SECRET and let us know which is preferred.
			Note: If this is description updated, we will request that IANA update the
			registry to match the edited document prior to publication. Link to registry:
			https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-sslkeyl
			ogfile-labels
			Original:
			Early exporters secret
			Perhaps:
			Secret for early exporters
			Or:
			Early exporter secret
			c) Section 4.2: We note that these two sentences include two different
			citations that describe the role of the designated expert (i.e., Section 17 of
			[RFC8447] and [RFC8126]). Is the intent to cite both references, or is citing
			just one sufficient to aid the reader?
			Original:
			The role of the designated expert is described in
			Section 17 of [RFC8447]. The designated expert [RFC8126] ensures
			that the specification is publicly available.
			Perhaps (include both citations in first sentence):
			The role of the designated expert is described in
			Section 17 of [RFC8447] and Section 5 of [RFC8126]. The designated
			expert ensures that the specification is publicly available.
			Or (only include citation in first sentence and remove citation in second):
			The role of the designated expert is described in
			Section 17 of [RFC8447]. The designated
			expert ensures that the specification is publicly available.
			d) Is "location" the best word choice here? Would "organization", "group", or
			something else be an improvement?
			Original:
			It is sufficient to
			have an Internet-Draft (that is posted and never published as an RFC)
			or to cite a document from another standards body, industry
			consortium, or any other location.
			Perhaps:
			It is sufficient to
			cite an Internet-Draft (that is posted but not published as an RFC)
			or a document from another standards body, an industry
			consortium, or any other organization.
			-->
			<section anchor="iana-media">
	<name>SSLKEYLOGFILE Media Type</name>		<name>SSLKEYLOGFILE Media Type</name>
	<t>The "<tt>application/sslkeylogfile</tt>" media type can be used to de scribe content in		<t>The "<tt>application/sslkeylogfile</tt>" media type can be used to de scribe content in
	the SSLKEYLOGFILE format. IANA [has added/is requested to add] the following		the SSLKEYLOGFILE format. IANA has added the following
	information to the "Media Types" registry at		information to the "Media Types" registry at
	<eref target="https://www.iana.org/assignments/media-types">https://www.iana.org		<eref brackets="angle" target="https://www.iana.org/assignments/media-types"/>:<
	/assignments/media-types</eref>:</t>		/t>
	<dl spacing="compact">		<dl spacing="normal" newline="false">
	<dt>Type name:</dt>		<dt>Type name:</dt><dd>application</dd>
	<dd>		<dt>Subtype name:</dt> <dd>sslkeylogfile</dd>
	<t>application</t>		<dt>Required parameters:</dt> <dd>N/A</dd>
	</dd>		<dt>Optional parameters:</dt> <dd>N/A</dd>
	<dt>Subtype name:</dt>		<dt>Encoding considerations:</dt> <dd>UTF-8 without BOM, or ASCII only
	<dd>		</dd>
	<t>sslkeylogfile</t>		<dt>Security considerations:</dt> <dd>See <xref target="security"/>.</
	</dd>		dd>
	<dt>Required parameters:</dt>		<dt>Interoperability considerations:</dt> <dd>Line endings might diffe
	<dd>		r from platform convention.</dd>
	<t>N/A</t>		<dt>Published specification:</dt> <dd>RFC 9850</dd>
	</dd>		<dt>Applications that use this media type:</dt> <dd>Diagnostic and
	<dt>Optional parameters:</dt>		analysis tools that need to decrypt data that is otherwise protected
	<dd>		by TLS.</dd>
	<t>N/A</t>		<dt>Fragment identifier considerations:</dt> <dd>N/A</dd>
	</dd>
	<dt>Encoding considerations:</dt>
	<dd>
	<t>UTF-8 without BOM, or ASCII only</t>
	</dd>
	<dt>Security considerations:</dt>
	<dd>
	<t>See <xref target="security"/>.</t>
	</dd>
	<dt>Interoperability considerations:</dt>
	<dd>
	<t>Line endings might differ from platform convention</t>
	</dd>
	<dt>Published specification:</dt>
	<dd>
	<t>RFC XXXX (RFC Editor: please update)</t>
	</dd>
	<dt>Applications that use this media type:</dt>
	<dd>
	<t>Diagnostic and analysis tools that need to decrypt data that is o
	therwise
	protected by TLS.</t>
	</dd>
	<dt>Fragment identifier considerations:</dt>
	<dd>
	<t>N/A</t>
	</dd>
	<dt>Additional information:</dt>		<dt>Additional information:</dt>
	<dd>		<dd><t><br/></t>
	<dl spacing="compact">		<dl spacing="compact">
	<dt>Deprecated alias names for this type:</dt>		<dt>Deprecated alias names for this type:</dt>
	<dd>N/A</dd>		<dd>N/A</dd>
	<dt>Magic number(s):</dt>		<dt>Magic number(s):</dt>
	<dd>N/A</dd>		<dd>N/A</dd>
	<dt>File extension(s):</dt>		<dt>File extension(s):</dt>
	<dd>N/A</dd>		<dd>N/A</dd>
	<dt>Macintosh file type code(s):</dt>		<dt>Macintosh file type code(s):</dt>
	<dd>N/A</dd>		<dd>N/A</dd>
	</dl>		</dl>
	</dd>		</dd>
	<dt>Person &amp; email address to contact for further information:</dt >		<dt>Person &amp; email address to contact for further information:</dt >
	<dd>		<dd><br/>TLS WG (tls@ietf.org)</dd>
	<t>TLS WG (tls@ietf.org)</t>
	</dd>
	<dt>Intended usage:</dt>		<dt>Intended usage:</dt>
	<dd>		<dd>COMMON</dd>
	<t>COMMON</t>
	</dd>
	<dt>Restrictions on usage:</dt>		<dt>Restrictions on usage:</dt>
	<dd>		<dd>N/A</dd>
	<t>N/A</t>
	</dd>
	<dt>Author:</dt>		<dt>Author:</dt>
	<dd>		<dd>IETF TLS Working Group</dd>
	<t>IETF TLS Working Group</t>
	</dd>
	<dt>Change controller:</dt>		<dt>Change controller:</dt>
	<dd>		<dd>IETF</dd>
	<t>IETF</t>
	</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="iana-labels-registry">		<section anchor="iana-labels-registry">
	<name>SSLKEYLOGFILE Labels Registry</name>		<name>TLS SSLKEYLOGFILE Labels Registry</name>
	<t>IANA is requested to create a new registry "TLS SSLKEYLOGFILE Labels"		<t>IANA has created a new registry named "TLS SSLKEYLOGFILE Labels" with
	, within the		in the
	existing "Transport Layer Security (TLS) Parameters" registry page.		existing "Transport Layer Security (TLS) Parameters" registry group.
	This new registry reserves labels used for SSLKEYLOGFILE entries.		This new registry reserves labels used for SSLKEYLOGFILE entries.
	The initial contents of this registry are as follows.</t>		The initial contents of this registry are as follows:</t>
	<table>		<table>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Value</th>		<th align="left">Value</th>
	<th align="left">Description</th>		<th align="left">Description</th>
	<th align="left">Reference</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">CLIENT_RANDOM</td>		<td align="left">CLIENT_RANDOM</td>
	<td align="left">Master secret in TLS 1.2 and earlier</td>		<td align="left">Master secret in TLS 1.2 and earlier</td>
	<td align="left">This document</td>		<td align="left">RFC 9850</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">CLIENT_EARLY_TRAFFIC_SECRET</td>		<td align="left">CLIENT_EARLY_TRAFFIC_SECRET</td>
	<td align="left">Secret for client early data records</td>		<td align="left">Secret for client early data records</td>
	<td align="left">This document</td>		<td align="left">RFC 9850</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">EARLY_EXPORTER_SECRET</td>		<td align="left">EARLY_EXPORTER_SECRET</td>
	<td align="left">Early exporters secret</td>		<td align="left">Early exporters secret</td>
	<td align="left">This document</td>		<td align="left">RFC 9850</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">CLIENT_HANDSHAKE_TRAFFIC_SECRET</td>		<td align="left">CLIENT_HANDSHAKE_TRAFFIC_SECRET</td>
	<td align="left">Secret protecting client handshake</td>		<td align="left">Secret protecting client handshake</td>
	<td align="left">This document</td>		<td align="left">RFC 9850</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">SERVER_HANDSHAKE_TRAFFIC_SECRET</td>		<td align="left">SERVER_HANDSHAKE_TRAFFIC_SECRET</td>
	<td align="left">Secret protecting server handshake</td>		<td align="left">Secret protecting server handshake</td>
	<td align="left">This document</td>		<td align="left">RFC 9850</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">CLIENT_TRAFFIC_SECRET_0</td>		<td align="left">CLIENT_TRAFFIC_SECRET_0</td>
	<td align="left">Secret protecting client records post handshake</ td>		<td align="left">Secret protecting client records post handshake</ td>
	<td align="left">This document</td>		<td align="left">RFC 9850</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">SERVER_TRAFFIC_SECRET_0</td>		<td align="left">SERVER_TRAFFIC_SECRET_0</td>
	<td align="left">Secret protecting server records post handshake</ td>		<td align="left">Secret protecting server records post handshake</ td>
	<td align="left">This document</td>		<td align="left">RFC 9850</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">EXPORTER_SECRET</td>		<td align="left">EXPORTER_SECRET</td>
	<td align="left">Exporter secret after handshake</td>		<td align="left">Exporter secret after handshake</td>
	<td align="left">This document</td>		<td align="left">RFC 9850</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">ECH_SECRET</td>		<td align="left">ECH_SECRET</td>
	<td align="left">HPKE KEM shared secret used in the ECH</td>		<td align="left">HPKE KEM shared secret used in the ECH</td>
	<td align="left">This document</td>		<td align="left">RFC 9850</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">ECH_CONFIG</td>		<td align="left">ECH_CONFIG</td>
	<td align="left">ECHConfig used for construction of the ECH</td>		<td align="left">ECHConfig used for construction of the ECH</td>
	<td align="left">This document</td>		<td align="left">RFC 9850</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t>New assignments in the "SSLKEYLOGFILE Labels" registry will be admini
	stered by IANA through		<t>New assignments in the "TLS SSLKEYLOGFILE Labels" registry will be ad
	Specification Required procedure <xref target="RFC8126"/>. The role of the desig		ministered by IANA through
	nated expert is described		the Specification Required procedure <xref target="RFC8126"/>. The role of the d
			esignated expert is described
	in <xref section="17" sectionFormat="of" target="RFC8447"/>. The designated expe rt <xref target="RFC8126"/> ensures that the specification is		in <xref section="17" sectionFormat="of" target="RFC8447"/>. The designated expe rt <xref target="RFC8126"/> ensures that the specification is
	publicly available. It is sufficient to have an Internet-Draft (that is posted		publicly available. In the Reference column, it is sufficient to cite an Intern
	and never published		et-Draft (that is posted but not published
	as an RFC) or to cite a document from another standards body, industry consortiu		as an RFC) or a document from another standards body, an industry consortium, or
	m, or any other location.		any other location.
	An expert may provide more in-depth reviews, but their approval should not be ta		The designated expert may provide more in-depth reviews, but their approval shou
	ken as an endorsement		ld not be taken as an endorsement
	of the SSLKEYLOGFILE label.</t>		of the SSLKEYLOGFILE label.</t>
	</section>		</section>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
			<displayreference target="RFC5246" to="TLS12"/>
			<displayreference target="RFC9147" to="DTLS13"/>
			<displayreference target="RFC9180" to="HPKE"/>
			<displayreference target="RFC9846" to="TLS13"/>
			<displayreference target="RFC9849" to="ECH"/>
			<displayreference target="I-D.ietf-quic-qlog-main-schema" to="QLOG"/>
	<references anchor="sec-combined-references">		<references anchor="sec-combined-references">
	<name>References</name>		<name>References</name>
	<references anchor="sec-normative-references">		<references anchor="sec-normative-references">
	<name>Normative References</name>		<name>Normative References</name>
	<reference anchor="TLS13">
	<front>
	<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
	e>
	<author fullname="Eric Rescorla" initials="E." surname="Rescorla">
	<organization>Independent</organization>
	</author>
	<date day="17" month="February" year="2025"/>
	<abstract>
	<t> This document specifies version 1.3 of the Transport Layer S
	ecurity
	(TLS) protocol. TLS allows client/server applications to communicate
	over the Internet in 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, 8422, 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-12"
	/>
	</reference>
	<reference anchor="TLS12">
	<front>
	<title>The Transport Layer Security (TLS) Protocol Version 1.2</titl
	e>
	<author fullname="T. Dierks" initials="T." surname="Dierks"/>
	<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
	<date month="August" year="2008"/>
	<abstract>
	<t>This document specifies Version 1.2 of the Transport Layer Secu
	rity (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. [STAN
	DARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5246"/>
	<seriesInfo name="DOI" value="10.17487/RFC5246"/>
	</reference>
	<reference anchor="ECH">
	<front>
	<title>TLS Encrypted Client Hello</title>
	<author fullname="Eric Rescorla" initials="E." surname="Rescorla">
	<organization>Independent</organization>
	</author>
	<author fullname="Kazuho Oku" initials="K." surname="Oku">
	<organization>Fastly</organization>
	</author>
	<author fullname="Nick Sullivan" initials="N." surname="Sullivan">
	<organization>Cryptography Consulting LLC</organization>
	</author>
	<author fullname="Christopher A. Wood" initials="C. A." surname="Woo
	d">
	<organization>Cloudflare</organization>
	</author>
	<date day="20" month="March" year="2025"/>
	<abstract>
	<t> This document describes a mechanism in Transport Layer Secur
	ity (TLS)
	for encrypting a ClientHello message under a server public key.
	Discussion Venues		<!-- [RFC9846 / TLS]
			draft-ietf-tls-rfc8446bis-14
			companion doc
			in RFC-EDITOR as of 12/12/25
			-->
			<reference anchor="RFC9846" target="https://www.rfc-editor.org/info/rfc9846">
			<front>
			<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
			<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
			<organization>Independent</organization>
			</author>
			<date month='December' year='2025'/>
			</front>
			<seriesInfo name="RFC" value="9846"/>
			<seriesInfo name="DOI" value="10.17487/RFC9846"/>
			</reference>
	This note is to be removed before publishing as an RFC.		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml" />
	Source for this draft and an issue tracker can be found at		<!-- [RFC9849 / ECH]
	https://github.com/tlswg/draft-ietf-tls-esni		draft-ietf-tls-esni-25
	(https://github.com/tlswg/draft-ietf-tls-esni).		companion doc
			in AUTH48 as of 11/14/25
			-->
			<reference anchor="RFC9849" target="https://www.rfc-editor.org/info/rfc9849">
			<front>
			<title>TLS Encrypted Client Hello</title>
			<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
			<organization>Independent</organization>
			</author>
			<author initials="K." surname="Oku" fullname="Kazuho Oku">
			<organization>Fastly</organization>
			</author>
			<author initials="N." surname="Sullivan" fullname="Nick Sullivan">
			<organization>Cryptography Consulting LLC</organization>
			</author>
			<author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
			<organization>Cloudflare</organization>
			</author>
			<date month='December' year='2025'/>
			</front>
			<seriesInfo name="RFC" value="9849"/>
			<seriesInfo name="DOI" value="10.17487/RFC9849"/>
			</reference>
	</t>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	</abstract>		119.xml"/>
	</front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-24"/>		174.xml"/>
	</reference>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
	<reference anchor="RFC2119">		629.xml"/>
	<front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit		180.xml"/>
	le>
	<author fullname="S. Bradner" initials="S." surname="Bradner"/>
	<date month="March" year="1997"/>
	<abstract>
	<t>In many standards track documents several words are used to sig
	nify the requirements in the specification. These words are often capitalized. T
	his document defines these words as they should be interpreted in IETF documents
	. This document specifies an Internet Best Current Practices for the Internet Co
	mmunity, and requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	</reference>
	<reference anchor="RFC8174">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	tle>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<date month="May" year="2017"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protoco
	l specifications. This document aims to reduce the ambiguity by clarifying that
	only UPPERCASE usage of the key words have the defined special meanings.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>
	<reference anchor="RFC3629">
	<front>
	<title>UTF-8, a transformation format of ISO 10646</title>
	<author fullname="F. Yergeau" initials="F." surname="Yergeau"/>
	<date month="November" year="2003"/>
	<abstract>
	<t>ISO/IEC 10646-1 defines a large character set called the Univer
	sal Character Set (UCS) which encompasses most of the world's writing systems. T
	he originally proposed encodings of the UCS, however, were not compatible with m
	any current applications and protocols, and this has led to the development of U
	TF-8, the object of this memo. UTF-8 has the characteristic of preserving the fu
	ll US-ASCII range, providing compatibility with file systems, parsers and other
	software that rely on US-ASCII values but are transparent to other values. This
	memo obsoletes and replaces RFC 2279.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="63"/>
	<seriesInfo name="RFC" value="3629"/>
	<seriesInfo name="DOI" value="10.17487/RFC3629"/>
	</reference>
	<reference anchor="HPKE">
	<front>
	<title>Hybrid Public Key Encryption</title>
	<author fullname="R. Barnes" initials="R." surname="Barnes"/>
	<author fullname="K. Bhargavan" initials="K." surname="Bhargavan"/>
	<author fullname="B. Lipp" initials="B." surname="Lipp"/>
	<author fullname="C. Wood" initials="C." surname="Wood"/>
	<date month="February" year="2022"/>
	<abstract>
	<t>This document describes a scheme for hybrid public key encrypti
	on (HPKE). This scheme provides a variant of public key encryption of arbitrary-
	sized plaintexts for a recipient public key. It also includes three authenticate
	d variants, including one that authenticates possession of a pre-shared key and
	two optional ones that authenticate possession of a key encapsulation mechanism
	(KEM) private key. HPKE works for any combination of an asymmetric KEM, key deri
	vation function (KDF), and authenticated encryption with additional data (AEAD)
	encryption function. Some authenticated variants may not be supported by all KEM
	s. We provide instantiations of the scheme using widely used and efficient primi
	tives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based ke
	y derivation function (HKDF), and SHA2.</t>
	<t>This document is a product of the Crypto Forum Research Group (
	CFRG) in the IRTF.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9180"/>
	<seriesInfo name="DOI" value="10.17487/RFC9180"/>
	</reference>
	</references>		</references>
	<references anchor="sec-informative-references">		<references anchor="sec-informative-references">
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="RFC8792">		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<front>		792.xml"/>
	<title>Handling Long Lines in Content of Internet-Drafts and RFCs</t		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	itle>		996.xml"/>
	<author fullname="K. Watsen" initials="K." surname="Watsen"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	<author fullname="E. Auerswald" initials="E." surname="Auerswald"/>		325.xml"/>
	<author fullname="A. Farrel" initials="A." surname="Farrel"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	<author fullname="Q. Wu" initials="Q." surname="Wu"/>		147.xml"/>
	<date month="June" year="2020"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	<abstract>		000.xml"/>
	<t>This document defines two strategies for handling long lines in		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	width-bounded text content. One strategy, called the "single backslash" strateg		001.xml"/>
	y, is based on the historical use of a single backslash ('\') character to indic		<!-- [QLOG]
	ate where line-folding has occurred, with the continuation occurring with the fi		draft-ietf-quic-qlog-main-schema-13
	rst character that is not a space character (' ') on the next line. The second s		IESG State: I-D Exists as of 09/30/25
	trategy, called the "double backslash" strategy, extends the first strategy by a		-->
	dding a second backslash character to identify where the continuation begins and		<reference anchor="I-D.ietf-quic-qlog-main-schema" target="https://datatracker.i
	is thereby able to handle cases not supported by the first strategy. Both strat		etf.org/doc/html/draft-ietf-quic-qlog-main-schema-13">
	egies use a self-describing header enabling automated reconstitution of the orig		<front>
	inal content.</t>		<title>qlog: Structured Logging for Network Protocols</title>
	</abstract>		<author initials="R." surname="Marx" fullname="Robin Marx" role="editor">
	</front>		<organization>Akamai</organization>
	<seriesInfo name="RFC" value="8792"/>		</author>
	<seriesInfo name="DOI" value="10.17487/RFC8792"/>		<author initials="L." surname="Niccolini" fullname="Luca Niccolini" role="editor
	</reference>		">
	<reference anchor="RFC8996">		<organization>Meta</organization>
	<front>		</author>
	<title>Deprecating TLS 1.0 and TLS 1.1</title>		<author initials="M." surname="Seemann" fullname="Marten Seemann" role="editor">
	<author fullname="K. Moriarty" initials="K." surname="Moriarty"/>		</author>
	<author fullname="S. Farrell" initials="S." surname="Farrell"/>		<author initials="L." surname="Pardue" fullname="Lucas Pardue" role="editor">
	<date month="March" year="2021"/>		<organization>Cloudflare</organization>
	<abstract>		</author>
	<t>This document formally deprecates Transport Layer Security (TLS		<date month="October" day="20" year="2025"/>
	) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have		</front>
	been moved to Historic status. These versions lack support for current and recom		<seriesInfo name="Internet-Draft" value="draft-ietf-quic-qlog-main-schema-13"/>
	mended cryptographic algorithms and mechanisms, and various government and indus		</reference>
	try profiles of applications using TLS now mandate avoiding these old TLS versio		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
	ns. TLS version 1.2 became the recommended version for IETF protocols in 2008 (s		020.xml"/>
	ubsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient ti		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	me to transition away from older versions. Removing support for older versions f		471.xml"/>
	rom implementations reduces the attack surface, reduces opportunity for misconfi		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	guration, and streamlines library and product maintenance.</t>		261.xml"/>
	<t>This document also deprecates Datagram TLS (DTLS) version 1.0 (		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1.</t>		446.xml"/>
	<t>This document updates many RFCs that normatively refer to TLS v		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	ersion 1.0 or TLS version 1.1, as described herein. This document also updates t		492.xml"/>
	he best practices for TLS usage in RFC 7525; hence, it is part of BCP 195.</t>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	</abstract>		126.xml"/>
	</front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<seriesInfo name="BCP" value="195"/>		447.xml"/>
	<seriesInfo name="RFC" value="8996"/>		</references>
	<seriesInfo name="DOI" value="10.17487/RFC8996"/>		</references>
	</reference>
	<reference anchor="RFC9325">
	<front>
	<title>Recommendations for Secure Use of Transport Layer Security (T
	LS) 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 Sec
	urity (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, inclu
	ding attacks on the most commonly used cipher suites and their modes of operatio
	n. This document provides the latest recommendations for ensuring the security o
	f 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 pu
	blished when the industry was transitioning to TLS 1.2. Years later, this transi
	tion 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, thi
	s 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>
	<reference anchor="DTLS13">
	<front>
	<title>The Datagram Transport Layer Security (DTLS) Protocol Version
	1.3</title>
	<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
	<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
	>
	<author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
	<date month="April" year="2022"/>
	<abstract>
	<t>This document specifies version 1.3 of the Datagram Transport L
	ayer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to com
	municate over the Internet in a way that is designed to prevent eavesdropping, t
	ampering, 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 exceptio
	n 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>
	<reference anchor="RFC9000">
	<front>
	<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
	<author fullname="J. Iyengar" initials="J." role="editor" surname="I
	yengar"/>
	<author fullname="M. Thomson" initials="M." role="editor" surname="T
	homson"/>
	<date month="May" year="2021"/>
	<abstract>
	<t>This document defines the core of the QUIC transport protocol.
	QUIC provides applications with flow-controlled streams for structured communica
	tion, low-latency connection establishment, and network path migration. QUIC inc
	ludes security measures that ensure confidentiality, integrity, and availability
	in a range of deployment circumstances. Accompanying documents describe the int
	egration of TLS for key negotiation, loss detection, and an exemplary congestion
	control algorithm.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9000"/>
	<seriesInfo name="DOI" value="10.17487/RFC9000"/>
	</reference>
	<reference anchor="RFC9001">
	<front>
	<title>Using TLS to Secure QUIC</title>
	<author fullname="M. Thomson" initials="M." role="editor" surname="T
	homson"/>
	<author fullname="S. Turner" initials="S." role="editor" surname="Tu
	rner"/>
	<date month="May" year="2021"/>
	<abstract>
	<t>This document describes how Transport Layer Security (TLS) is u
	sed to secure QUIC.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9001"/>
	<seriesInfo name="DOI" value="10.17487/RFC9001"/>
	</reference>
	<reference anchor="QLOG">
	<front>
	<title>qlog: Structured Logging for Network Protocols</title>
	<author fullname="Robin Marx" initials="R." surname="Marx">
	<organization>Akamai</organization>
	</author>
	<author fullname="Luca Niccolini" initials="L." surname="Niccolini">
	<organization>Meta</organization>
	</author>
	<author fullname="Marten Seemann" initials="M." surname="Seemann">
	</author>
	<author fullname="Lucas Pardue" initials="L." surname="Pardue">
	<organization>Cloudflare</organization>
	</author>
	<date day="17" month="March" year="2025"/>
	<abstract>
	<t> qlog provides extensible structured logging for network prot
	ocols,
	allowing for easy sharing of data that benefits common debug and
	analysis methods and tooling. This document describes key concepts
	of qlog: formats, files, traces, events, and extension points. This
	definition includes the high-level log file schemas, and generic
	event schemas. Requirements and guidelines for creating protocol-
	specific event schemas are also presented. All schemas are defined
	independent of serialization format, allowing logs to be represented
	in various ways such as JSON, CSV, or protobuf.
	Note to Readers
	Note to RFC editor: Please remove this section before publication.		<section anchor="example">
			<name>Example</name>
			<t>The following is a sample of a file in SSLKEYLOGFILE format, including
			secrets from two
			TLS 1.3 connections.</t>
	Feedback and discussion are welcome at https://github.com/quicwg/qlog		<!--[rfced] This document contains an informative reference to [RFC8792], but
	(https://github.com/quicwg/qlog). Readers are advised to refer to		the only mentions of RFC 8792 are in notes within <artwork> in Appendix A.
	the "editor's draft" at that URL for an up-to-date version of this		Where may we cite [RFC8792] in the text? We suggest adding a sentence
	document.		at the beginning of Appendix A as follows.
	Concrete examples of integrations of this schema in various		Perhaps:
	programming languages can be found at https://github.com/quiclog/		The examples below use line wrapping per [RFC8792].
	qlog/ (https://github.com/quiclog/qlog/).		-->
	</t>		<!-- [rfced] Please review the artwork elements used in Appendix A. Should
	</abstract>		these be tagged as sourcecode instead? If these should be sourcecode,
	</front>		please let us whether the "type" attribute should be set. If the current
	<seriesInfo name="Internet-Draft" value="draft-ietf-quic-qlog-main-sch		list of preferred values for "type"
	ema-11"/>		(see https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types)
	</reference>		does not contain an applicable type, then feel free to suggest a new one.
	<reference anchor="RFC0020">		Also, it is acceptable to leave the "type" attribute not set.
	<front>		-->
	<title>ASCII format for network interchange</title>
	<author fullname="V.G. Cerf" initials="V.G." surname="Cerf"/>
	<date month="October" year="1969"/>
	</front>
	<seriesInfo name="STD" value="80"/>
	<seriesInfo name="RFC" value="20"/>
	<seriesInfo name="DOI" value="10.17487/RFC0020"/>
	</reference>
	<reference anchor="RFC8471">
	<front>
	<title>The Token Binding Protocol Version 1.0</title>
	<author fullname="A. Popov" initials="A." role="editor" surname="Pop
	ov"/>
	<author fullname="M. Nystroem" initials="M." surname="Nystroem"/>
	<author fullname="D. Balfanz" initials="D." surname="Balfanz"/>
	<author fullname="J. Hodges" initials="J." surname="Hodges"/>
	<date month="October" year="2018"/>
	<abstract>
	<t>This document specifies version 1.0 of the Token Binding protoc
	ol. The Token Binding protocol allows client/server applications to create long-
	lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and con
	nections. Applications are then enabled to cryptographically bind security token
	s to the TLS layer, preventing token export and replay attacks. To protect priva
	cy, the Token Binding identifiers are only conveyed over TLS and can be reset by
	the user at any time.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8471"/>
	<seriesInfo name="DOI" value="10.17487/RFC8471"/>
	</reference>
	<reference anchor="RFC9261">
	<front>
	<title>Exported Authenticators in TLS</title>
	<author fullname="N. Sullivan" initials="N." surname="Sullivan"/>
	<date month="July" year="2022"/>
	<abstract>
	<t>This document describes a mechanism that builds on Transport La
	yer Security (TLS) or Datagram Transport Layer Security (DTLS) and enables peers
	to provide proof of ownership of an identity, such as an X.509 certificate. Thi
	s proof can be exported by one peer, transmitted out of band to the other peer,
	and verified by the receiving peer.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9261"/>
	<seriesInfo name="DOI" value="10.17487/RFC9261"/>
	</reference>
	<reference anchor="RFC8446">
	<front>
	<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
	e>
	<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
	<date month="August" year="2018"/>
	<abstract>
	<t>This document specifies version 1.3 of the Transport Layer Secu
	rity (TLS) protocol. TLS allows client/server applications to communicate over t
	he Internet in a way that is designed to prevent eavesdropping, tampering, and m
	essage forgery.</t>
	<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
	77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
	plementations.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8446"/>
	<seriesInfo name="DOI" value="10.17487/RFC8446"/>
	</reference>
	<reference anchor="RFC4492">
	<front>
	<title>Elliptic Curve Cryptography (ECC) Cipher Suites for Transport
	Layer Security (TLS)</title>
	<author fullname="S. Blake-Wilson" initials="S." surname="Blake-Wils
	on"/>
	<author fullname="N. Bolyard" initials="N." surname="Bolyard"/>
	<author fullname="V. Gupta" initials="V." surname="Gupta"/>
	<author fullname="C. Hawk" initials="C." surname="Hawk"/>
	<author fullname="B. Moeller" initials="B." surname="Moeller"/>
	<date month="May" year="2006"/>
	<abstract>
	<t>This document describes new key exchange algorithms based on El
	liptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol.
	In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key
	agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Al
	gorithm (ECDSA) as a new authentication mechanism. This memo provides informatio
	n for the Internet community.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="4492"/>
	<seriesInfo name="DOI" value="10.17487/RFC4492"/>
	</reference>
	<reference anchor="RFC8126">
	<front>
	<title>Guidelines for Writing an IANA Considerations Section in RFCs
	</title>
	<author fullname="M. Cotton" initials="M." surname="Cotton"/>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<author fullname="T. Narten" initials="T." surname="Narten"/>
	<date month="June" year="2017"/>
	<abstract>
	<t>Many protocols make use of points of extensibility that use con
	stants to identify various protocol parameters. To ensure that the values in the
	se fields do not have conflicting uses and to promote interoperability, their al
	locations are often coordinated by a central record keeper. For IETF protocols,
	that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
	<t>To make assignments in a given registry prudently, guidance des
	cribing the conditions under which new values should be assigned, as well as whe
	n and how modifications to existing values can be made, is needed. This document
	defines a framework for the documentation of these guidelines by specification
	authors, in order to assure that the provided guidance for the IANA Consideratio
	ns is clear and addresses the various issues that are likely in the operation of
	a registry.</t>
	<t>This is the third edition of this document; it obsoletes RFC 52
	26.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="26"/>
	<seriesInfo name="RFC" value="8126"/>
	<seriesInfo name="DOI" value="10.17487/RFC8126"/>
	</reference>
	<reference anchor="RFC8447">
	<front>
	<title>IANA Registry Updates for TLS and DTLS</title>
	<author fullname="J. Salowey" initials="J." surname="Salowey"/>
	<author fullname="S. Turner" initials="S." surname="Turner"/>
	<date month="August" year="2018"/>
	<abstract>
	<t>This document describes a number of changes to TLS and DTLS IAN
	A registries that range from adding notes to the registry all the way to changin
	g the registration policy. These changes were mostly motivated by WG review of t
	he TLS- and DTLS-related registries undertaken as part of the TLS 1.3 developmen
	t process.</t>
	<t>This document updates the following RFCs: 3749, 5077, 4680, 524
	6, 5705, 5878, 6520, and 7301.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8447"/>
	<seriesInfo name="DOI" value="10.17487/RFC8447"/>
	</reference>
	</references>
	</references>
	<?line 436?>
	<section anchor="example">
	<name>Example</name>
	<t>The following is a sample of a file in this format, including secrets f
	rom two
	TLS 1.3 connections.</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	# NOTE: '\' line wrapping per RFC 8792		# NOTE: '\' line wrapping per RFC 8792
	CLIENT_HANDSHAKE_TRAFFIC_SECRET \		CLIENT_HANDSHAKE_TRAFFIC_SECRET \
	cf34899b3dcb8c9fe7160ceaf95d354a294793b67a2e49cb9cca4d69b43593a0 \		cf34899b3dcb8c9fe7160ceaf95d354a294793b67a2e49cb9cca4d69b43593a0 \
	be4a28d81ce41242ff31c6d8a6615852178f2cd75eaca2ee8768f9ed51282b38		be4a28d81ce41242ff31c6d8a6615852178f2cd75eaca2ee8768f9ed51282b38
	SERVER_HANDSHAKE_TRAFFIC_SECRET \		SERVER_HANDSHAKE_TRAFFIC_SECRET \
	cf34899b3dcb8c9fe7160ceaf95d354a294793b67a2e49cb9cca4d69b43593a0 \		cf34899b3dcb8c9fe7160ceaf95d354a294793b67a2e49cb9cca4d69b43593a0 \
	258179721fa704e2f1ee16688b4b0419967ddea5624cd5ad0863288dc5ead35f		258179721fa704e2f1ee16688b4b0419967ddea5624cd5ad0863288dc5ead35f
	CLIENT_HANDSHAKE_TRAFFIC_SECRET \		CLIENT_HANDSHAKE_TRAFFIC_SECRET \
	skipping to change at line 904 ¶		skipping to change at line 754 ¶
	SERVER_TRAFFIC_SECRET_0 \		SERVER_TRAFFIC_SECRET_0 \
	8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \		8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \
	04ffc7c154f71ba5f530c7344b0496f60ce71b9b7c6b0e203ea574bfcdf14e27		04ffc7c154f71ba5f530c7344b0496f60ce71b9b7c6b0e203ea574bfcdf14e27
	EXPORTER_SECRET \		EXPORTER_SECRET \
	8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \		8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \
	befb5db5ac6785b5dd4c6a8c4693c379ec0a1486b5fd035b25e50c3c95abc500		befb5db5ac6785b5dd4c6a8c4693c379ec0a1486b5fd035b25e50c3c95abc500
	]]></artwork>		]]></artwork>
	</section>		</section>
	<section numbered="false" anchor="acknowledgments">		<section numbered="false" anchor="acknowledgments">
	<name>Acknowledgments</name>		<name>Acknowledgments</name>
	<t>The SSLKEYLOGFILE format originated in the NSS project, but it has evol ved over		<t>The SSLKEYLOGFILE format originated in the Network Security Services (N SS) project, but it has evolved over
	time as TLS has changed. Many people contributed to this evolution. The author s		time as TLS has changed. Many people contributed to this evolution. The author s
	are only documenting the format as it is used while extending it to cover ECH.</ t>		are only documenting the format as it is used while extending it to cover ECH.</ t>
	</section>		</section>
	</back>		</back>
	<!-- ##markdown-source:
	H4sIAAAAAAAAA7Vc6XLcRpL+j6fAUBEraZekcDUOre0xTZEWw5ToIaXxeGc2
	rAJQaGLUDbQBNKm2rHmWfZZ9sv0yqwpHsynLsxpHyCK7C1lZeXx5VEIHBwdW
	V3YL+dTee3Ut7aur8+9Ofjy/+Pb07PzEPq2bpejsom7sV+dXe5ZI00beYOlk
	2Z6ViU7O62bz1C6rorasvM4qsQTNvBFFd1DKrjjoFu3BW7lZ1POiXMgDZ2a1
	63RZtm1ZV91mhcVnJ69OrWq9TGXz1MpB8qmV1VUrq3bdPrW7Zi0t7O1bopGC
	eJDZuim7zZ51Wzdv5029XtEhGlG1q7rp7HOxkY09rMLmWJg/tewDu5IdPQSi
	tBoEq2xDn4NJ+itd1Nnb7FqUlXUjqzUYse3f3sC21Tn2fgDpsprb39Ij9PlS
	lAt8DupfkywO62ZOH4smu8bH1123ap8+eUKr6KPyRh6aZU/ogydpU9+28gme
	f0LPzcvuep0qgrfzJ227GARL3y8gu7YbUeZ1h+qxw7KePvHkXiUdXnfLxZ5l
	iXV3XTckOBC37WK9WCj1vhBNV1b2q+t62dYVfwmeRVX+IjqoFQvqX8rFQvA3
	Uklh2X29qG9l1TX1anMIRdwl+6No6nYhbuzLuq2X4u11vYP0f7WZWMhmTHrT
	mPVf/6K+Pczq5V36z0VVydZ+1WbXdSGrcr6D/OsKamhaKNauC/totVqUMrev
	shKmgme/qavq4PJaltXBVSkVAeMdzw++ubwa86X2Oxz2+3q+fMdHtyr2MGz1
	1LLId/rfbPvy9DiOEg9fWAcHB6DewlozPHNkq3V2d43/tesVWWNrQ2lzsrqe
	TF3hoXpN66TdyqyRWLVucQzoTJBHk39VMuOlZWvnss2aMpX5IXaXGZyF6Jkn
	uxoPkVnQ41OcUBtaYgHNgkwp5lXddmVmiyrv+erqetEqnsEEfsCOTA6Ec+yx
	WXX2UratmMvWku/gftUcvKYb4tSWVb6qy6prwdsrflTJAD/hU3yLpYRTRBr8
	tZu2k8vWvr2WjbSIQF0tNvaqqTucF2zAQWxgjDjU4l2Web6QlvXAPiPTzNcs
	Fct6JtO14h/ERSUWm1/oFyJUZ3SgTFR2Km2wu1jIildi04qZfv/+j/jL9T98
	ID5J9BYOq5lgtUABYL4jG4OpLtdVmbHm6JhnwBlSDsluuhQ2SOICOSMwOvNI
	7krWxJqsRAoZL+uGRF4DkebX6hxt2eLwF7ByuyuXct9erhdducJiYr1c4qcl
	9lPs2NfiRhrTWkCSIq+JAWMS2gJIA72+e6uzb8RiDR7nspKN6JRS6WvaCHBj
	wzFkvgbg0KGBltXG2tp/n9crc7kWU5MGfPOmoAvpQtAktrIotaFXlqxuyqau
	iBpYaUqWCEFBvh3J9u1r8m8mTwtI2JMVljooGH0JJfI6sjgsI0p7tmiVYUNZ
	iBzsWHVTQh4stFUjKa7RGmmxBHlBwYLgR4dt6WdjZdAT2zzi6ppPYTxVPbLL
	GbfcRFspez8+Yo9wDz1Y6B/IQr0vgTYzLwhhqeSz6mvffO1/eXbw7LCPEE2R
	xUEQpmX74QPvY/Rvi0VbWz0iSdEANTl3sBlMtSLZBrXYzBrzPesPDljNIa+8
	bLN63cDAcwu+RIiYJOBR/Zz43kwzMD0ocdGf9hZRz36mvfGZOg097AbRhw/7
	9p9enx1r2onjOD1tx3HpaxJGDRk3I49nA+Q9FI71dmyN7Ph1q7U4Yq1eL3Jy
	c23ZW4QPtNlmxoMgyOyazOJPUC1xT38Pmvh5XWYHP2PtAaJMdUB7LwXksW0r
	zGkui5Ji3kKk0hxhbBNwHFAaxw5LxQ4DxCPkPjHoYx9DddjhuQTw249Ojp8/
	JovB31N7kW1VMmPWgwcqlGYiLRcUW6/g3ywM4lralE8UIuuMk++2+QO7LIAS
	OdbfUM6UqiBC/taV+J7laoFENYQNPKQk30kY1hrxolmyRBS0AkLma4HUrpPm
	qKRU6OamxMaH1u+NOfZHY84P1wrJcIIM6UQ7Ou84fJvt6XREbwjX7Uh7SGwY
	eDX+6/AEoTAvtFEub+SiXnE0V0zuq82WkrRbtkv7xeurV/bLi1egaQ05wqqP
	hPpBWDaKAruti+5WNBqMGe+WK+yU7xu/Bqt5SQ+KhaW+FCbNoGOnJItbsVF6
	a9eGVC5Xi3pDEQKQ2ZAycc6q7ogtkCzKOZbm6inWO4UP7S8wsPfvW52OE5Dl
	eQPZgoawVVlBjOFTzRfxmMmmMh7dlGC9aOqlgXULy6f0yYCPe2hvGR6ekWsx
	yVYZMT1ClUZr75FUEVT2jHTp58sTYM7lyTP6+er50fl5/4OlV1w9v3h9/mz4
	aXjy+OLFi5OXz9TDpK3JR9bei6Mf9xRo7V18/+rs4uURYhI0OfUkVhwjJJlx
	g6jEkby1+gSQnvnm+Pv//R83II8GIHqum0Cm6pfYjQL8QnmOhkgydPUrZLex
	xGoFYGcbWkDOYlV2gKF9ArP2ur6tbHIRyPPf/0qS+e+n9hdptnKDr/QHdODJ
	h0Zmkw9ZZnc/ufOwEuKOj3Zs00tz8vmWpKf8Hv04+d3IffThF39cAGrsAzf+
	41cWGZF9X6nNyf1HUmxyHwEgedfxMhP7es2azEdlGPBtqhhg90hqak7moYDX
	r04PYq1IP/QSHUI5KHdDKC+7Vi4K1iwqk2yxJhw6ujo+O7N7uq2toqXjeA5F
	S0phJYEthML5KgKTjnLDM4SlvBlKLHAl6UwrQuOuU4ZnqIxyvh6dDFFhnrbS
	DfIweBv2WAqU9I9e/8fpyenpY1jXOQM8WzujPaee69Ykp6wUoDj9Ps7XdO4F
	wCJRQAKEotm11XNTjlJZkt1Q2AAvNZzLVi1uFe8E86hvji/PT4lD1wdiU7Wk
	cmF84Dzex7fqO/wIjNUrncekNKG4NeeoG+zbH88qgfsEiyWzvuEjy+WKatdG
	fwhmGkDuYBJkSThs1tVUFqzk8JX16OGDh/tgyvMfY5sL1t+CN6uLQSdSIDsZ
	9EFiXZikHMI/2yogWD4NV5U7Ssq8RkxhamW1rtctVRj0TA0UHuf5g9wt64QY
	0BXGuHrVKu5ZYslRDKoprvERGilNUaKxn7ZZib46Gc6zEtlINqQSz3msst62
	J4LnUadzcoW/n7J/8282wjfOZFySO0TEgmbbhM9U9kaI4Pef+FrCtVSy9uGD
	ZXOaIfQRV2MzHSd0JCCV6OV3QB/yyjhb+wlJTl4vezZ974BdiE9iqF7yGqhG
	ImPtQ6JK91S2pwtP3hj8IZwjHJftNQVnnREP2YrBKbUHfmA84phjhwGCwTsk
	c1mJyhKkRkjB5aDgzLTPWDUW9TbE3PWl6yhDUikOyY5PsZXtar2Qpkd8WtrY
	eulMpNLr0lgwq2Xrm3tODT5G5y6r8aH3VZGCg8pq3l33mRCwqSX44WK3/MXw
	AVK9l51qBkbUjE1qpt9M1P6GEOGNevzNvl3VI+Sz5Luy7dr+UJnQqdwA9w/F
	Q/Iehu+HxUP7EZY+PBp9dvqQfOOUgM/SEh+qfj6lLAlP9snd1Y8ccBRKplID
	JS2mJorGU3ZniyOeZT3bbnMo21cAqyDXGL8OZctyfk3QV9ctJz4KLhWkWUrY
	tU1JJmWYxAzWjJ8vlQo4WaK8lTswyFlVIKEenLZFnNjCGeqUMFFqzwHiNWs+
	EjNHcUk1K6bNEXJe4oHT3UFcrIhyRXJq1yWHOhNRe0OzCLiWUrvMkUFZbQDk
	ikjy8/ZavJVaFkRAFiQEsFtJmSun0PWstRgz2Oq890qxe64AR98JqC7BA41U
	SF+qrc6R6W7QOlVNbOXj5vhIAlD9GabH1bT9SMHhle5URocuLfuDbq3B4M4K
	G0Un6gmkl2suqKjZu8HJ5nVXsjAZQK15CVsfSW5fR2qNosYIx7F5DIcGCM/w
	fDOGw0OLo+QtKoj9nU9crLvpE/1eBEgmmJnwytuTdWm+yIRku0JJpUwTwRfV
	PyTHOZ/SixZuz/O4rwY4Oz4/O3n56qeTo8vzH396dXl0enp2/NPVyfHlySsN
	dtR46YOpgUnTq1QmRSuwo95BAQtpjpo4Gy5t95FuUDjoP+A8A5ndcjXq+6kn
	hyYa+S9IN9yLVHnC37lkZjqgx5RuS9QS5CIqHvT89i0lYVhSFNWuY+44COR0
	m0DNm2pUoy42pAMWzslfvr+4fHVy+VvSIYtSpOU76ncp7zsv30oN0h8RuS6/
	y1ZVTiOIJNSbSI/uiXr5Ua2lPFjVxKbvqTIWJcCy2BK/EiZbmWbp+dHLZ6iV
	vjv5JyxhgJL7bQI7XZ1c/hky/NftpE47nGlK/yfnU3YQqhdFJvATS+v+I1H8
	RlmSE5pQclp0UkfenkvTX+qvKIaNR/mBII2aoDxmoGtEUZTZT+qpn5w3Ju4Y
	+Jx0ynsJ/8vOrQT8mc+tiP6/zv2p/gkq2q8ISXsfnQSS2TiQHFrvnyJk3FJe
	8OUe3TfvfeCOzhAgqJsx9DbW+KnhLElzrJtF+3aqbt02U+S2KKioBzS90UnH
	p7Qf3R/t9qkly6lO3XBJOpKlcvm+XmoJJbhEpTQRGSLpad/e25Kg7hBx2FfV
	2MB1awKOFq66NXljpKmV9gZqGaCclquCnH81olNi497oDvrqgXJUa6sydoWF
	sCGlz+E+rRdxw/UE8ti+fauLqmn5aXHwoAMa6bRdU2YdTNoki8zB4UdTHe9u
	WdunN8NdyocP9iMCam68b99vPB6SLK4P9zR8XQIoL17sTUoTksveUrQQ9N52
	xTEpWnayjIzIsn6gHJJyI9WX5yuNoQE6rqxxeCRHuZWbvHbs4txvVVe0O/Of
	vhxUpffzTdqUuf39GiVhZn0HVeo7A7LRR8+//+6ELwroB3UXEzvUhToy8ZvC
	tArykpnXJjRU+Pi1vrUQ6UrKGAtJzQ9a2Mi5aPIFtWC4yOaAqEoDUWXykGs6
	/fF4E70BB2Omak3ySH09rWtb2shsOokRfSJS9pc9fc3BDQ6r75PSEsVXS/QO
	t3BG9YwWt2LT9pdMv5lSEjYeP78Di8rOdrjcdycvbKi3GUoRxk0ciRQDtH70
	Rn1tvNzAlVjM6waGtWyVUxqomh26Gqymmn18CGLnqrbVKe64baMaFlqSxNRW
	2k4CuNV2rM94fPHy9OzbvkrHR8d8OdBHOhocAoLrW3bSmHzXoWjjsnwo7MtW
	Z1AU5iY1OUxJQ4/QTmY96Gd96A6ghZs2GgTeP+ivHVAC6Rud2vipubX/+PSE
	racn6P6y60T2lvCzttJGireGUqGgQfDVGUEMlaRz5kiHdq646NJ7c+fCiDs1
	5Om6g5IbdY47yX2nN62pI5HRMMqECu06+p0vnhiyh6GEPpu4lQrAb0rV0Ws7
	6lJiqxNTPUPaP6+haH0NRlc8XVMvdNOjb6GOy1VkG/gEDrwhjEcUEtW97UZ9
	Ez0aSSCDoxhJNe/23ZNZRVU8O2oq9S2Ttk5y5dvrmuFSzUSVv/B5jvp6rZ91
	UbcrpTJji/JzqIRvKDd9149y+NrUjSOK9HidMkxRub+scxMNtDVZ6oKtV8qg
	hB0zEQqJenPmW73yBnKdS0vSmJQeFWKjo5bbLknq2zZzPg5tO2Roid74pz0E
	9rRyWXbqipBprGCzYIXUz47BlwCtmgJAbjMqcTVVYx39rSW1Js4qk2zUvb41
	XpsCv2cCAqM41fC1YyOX9Y2pLayR/wyygzSeI2W7oX6VHs9Amja9Ptdxs8fl
	rYZ1u0H2TKnGPnt2TnkAMaA6fmOoaOVYWCxhfbNtmdjLpsudjOqubxoXVvUh
	owmvLau/G2BoLLYlky0SJm0nj3T+EVF11Fs2ocFUU2nk1Q9oQRNHSKrgnKNJ
	iYZKhlrNQhEr43x8SAhIpEpPu0ZtBkgaRD/JkMaxq1R7Dcm+qdGt4aNHdwqA
	Pw6dJPu7qr6Fw89Ns3WklWGcytLjVNyOVkNaLF57W7wDJqrmiGrq8jQZog0U
	BKgZq8CIjk7TTvoKp6zJltOY/dEBlbbHoz2tZB+iG3TaCQeWh/PDfX1VFweR
	y1UEwQ1JUe88WZR4oVoEcqrZaKy8v7kx9w39rMDoFIxS76i/czQ2eQYI1Rtt
	t0Tbn8LMcvQTguNxCLouYpTSfjbaUzU+7w6uacq60zykYzWgaNvpKkszbkY4
	VNN32H/EJR8bKmkIpcjN9eWRZVC853gLOckotPJG/dXXChHJvu6Oqu3bZhDo
	zcRB3uzfpc9zc6UcNcWHVGQh1pW+suMLZF1JjDVHQcl0g/uj9MTpMnAYc5lE
	WL54pjbagaoQOW7v04ODcq0ckmLI6AGPFhNqTANwXksVHBGx1gvuv1PqgPpC
	lX3aCSnHWy8VhgCE+mmqeSOW+u6IsxgquGn2YGQtmietPUtzb0+Vp+Sz6dcq
	LFPHP1jQSM12YKKwR0HO2gb2TKzUxFPJFwBw5lth7kGzzXj0SI/89FBGDZCt
	/jfVmpSGHa0YTN5ZJyrrVu5NM3yP+XsGYyCSnFSpj4wxqXxmnMC3tocSlx71
	DgNDMQgSjyjqK5LresH3zNSugFsAFiA3bjJSGFXZUH946uL3i3bmt/3kLwef
	Yeq3VDnsKHnU+cR0atncppiK1Rxyu2oeBqmuOeKXq1In5aP7G7sQjTVHvt3p
	olEdYlesVdhv9GP8WF1X6vKaPAi01NQFdwNIDnp0WLmBGd7d/yjvlPcT0lPP
	wIzNcfoC45dbvQBVFCyRSbU1jTsY4DNjcPsUQ2TT9/Mt3W03btZIU3tx7kTU
	ABMIhqfIZfly1/C8I1GkvFnc1KWqkpuyfUs9qLbOysl11pY7kOvqpv6Qo6uj
	W1ykHW6XVEORa266dCEzLau0vTHE3TU4605dyKflSgMcwe4kbHargvto72Nf
	j8kYW1yJzaIW/TXcleo6vKTx3jO4rYm7Vy/PHo+K0+3DUiV9ML5d31Gx4/h0
	klIPrvMF26ruVKlo6ZCJHL2gUQYxp/jb9cSBWGlD4RkhKJOTkFFyzkXnMU5s
	cdWiR8D5trIfwOyzQ1Uqnx29PNoqk7cHUxs5L1tOYoTNHWY1HYH8rBSVOOCP
	gDwMSBm7Ja1UT4FfnjVX7RLziPr1wCzhzoPqjk0s4wVv9oo2e/9gtJca39t7
	M4oU01dl3uyNGd2aKDDdqd5gkFDctcp+OpsF9Le/XtNwTw7gfMIg+vMaulb0
	8Ol/T68Dra1kiPuDw2HavUE4yLS+MG//3N7eHtIp1ftESA7nnF+0T/gsB3SW
	9qunODwdit+Qob7KSAiWdbVOu8m3E7FY1qUKpLk93ETzspdPjizrYqXbjbu+
	PDGTadnEVniBmlQj3KBJ5G8uXvBclJpB47k0q2/I7Hj6ioPmMA/KtSI2r4GO
	Bkd3PHY+TIWZNAE5fUFzClTh9WNho7kJixudyjv1DLd6i4joIYTaf8F/9iP6
	6QTBoW6egoyka4D1it4HeAynHycn03dkBotjes+mb9eYVznGsxCmMJ/EVtN0
	6P3Usu0dRdwp0iz2zv7qptklJdbd0dBJHlkmf/9FvuDRKUjxyz26IEII3fsK
	W36Rd189o15ExkFBLEq6puA0UCWkdBQ66xdPsPKLPP8KW+Hn3Dz8QsxxdDU/
	8Kh9fO+6U55RM7j6sZUviM2ubq/1+yXs20ib7n3mSb74CkrnIGv/m3rLy0wb
	6+ZjR0PsdKBi3XAE3hYQRfsfvrUfjd8JfKwslOfK1xRSeCWNnV68JB9TVxaq
	P1KNVihl6Jf0LPUipdpg/CKiZR1zcmWy1YUcVtPN1x11fdiFnfqC4dIAjQbQ
	beTFSQjftjFNwTjNf8jbAaz2iNdd2+ypySh9PcXjSXSce9/BtB+B0mP7+x5n
	Roi4grT0GP9kc+qKITL3r0b0d/tThuiFxVK9CGAaewuD9G3/pseAv9QibDV0
	U5b6q/1n7jj/aj8bDfH9CkHSRQJF3l+xht5Em/wfn00uiPD5C04P+w561SeO
	BAfmuunXrcHgEaFd8whYfzXcL+lbmNEUgeno7iK7c2oCK0+msxGG4Y9wdt+w
	wMCd6dJRvFBMDndUuwj/xhTCTsL6eujjhO8ZOvgYp0aGK4D3p7H9SdQ1u7+D
	+g5VTTsS+pb/N6gMWfivKpG85z5JJ+eUod5HR13n2L9uX+SwMZqbnNHQ625a
	1kv49Si/MTvv7YSWwVf5api6OvmSqpzOXOwxgunJRutqHNjtId+hAcWc2t+6
	veZ6IV1lEkoAY/vRUSSHYItDHjyCKrDxxLI1uUZzo1E1Hxlqdym8f99vqHvw
	/XtEcpqI0BjRii9jaYTDpOyUhDIf7ZoGMNTkVK3e9ERqy8lSJbuDZ/R+OCKV
	TiDIwvQoUkWtcXtlsh9LcHkPrh5z8wR4XzLa90riFEpUqlVDzcxckNGmdb6h
	0jRfs0JI5bDHcr3cV2/dmubOos70bdxRZaSwFBtT3qu3XMvqIJcr1JrUO5C3
	bT8qUDbqzuGGbr6vuaWtp6g6GHllK+4RfuumVe+kmdJtYj8cJw7VW8MpKiuq
	dk7UbIUqIIbxPX5bo+WvpheAo+nSfXsoGyczzd1tbZkOw7Tj8Y9//AN7vrx4
	dfLUfvi3h2rA/bbB4bi/AEFRqkkvj//mxJf9N5q4LvwgTpLUz7M0zpJCRm7o
	ZFIUySz3Z4HwkiBK/DSMhCeDJEuTLBNBHiZp4M8SXzhMJJVYGOexm8nA9QKv
	KHw3C/NYhKE7i2eeG8WFl+XRTIoMdGQchXGRyHzmerGX+vFvTYx9Pk69WexG
	SeS5hYicQHqFK6UbhnGcBqkTuEkSRijIxCz0giyfidyJQ9+L4zwD69il+CSZ
	pp5MwUmc5wKceh649mdhBP7STLjS9f3ID5PYwVfRLAjjKI4C6cdJWER5mDuC
	icwSmTlJ7Kae64oo8AvPA0NBKNwii3DG1PMdsC4LJ5dhHkDwsUgLmTiyKFwn
	LT5Jpp+FU+FHhQxyiD5LRIjfPD8JUxcyLMIiFoGTuZlfxLPCFSJJHRxD5kGY
	BcL1HdcPZ/dN8X0+rcsEpwlnaZZGYApHhVqdME68JPfCbOZ7LDZPerkQWJHH
	6czzgzCZucIPMse7b97u83EYFImfha7IXD/xHSfOgyz2nIJkmaf4JgqSoHDC
	WRSk4azIMs/NEgmWvSJxnMgV25Nxn48zx8VW4MiHQOIihq6jbDbLYz9MvchN
	UinT3E9SNwziAsWLmMVR5BVBnCdQcFGIj2r3s9ifTHAsWi9mvpvHkVvMZFbM
	3CTw8zgr0jgG8zTbkRVJFDkuCKWzAvtKx3fyKPmodj8Lh0Xqup6TJq6EXAIH
	JphBuUL4fhw7MooQSmTsZfEsJyjKCweOkqTFzEESAC8Pdmr3s3CWp24RFBBd
	mAC2U9ebwfKyIJKOl/hxCv+FjDJ4QpimwKJE+l6YFG4Gd54JmAPHo9H83zSK
	0UtPt/VkXKG/R+M3KhZS3KhXgYZXQ/etVGZiPb585Xg9TDyr6/jNnZfCpgGY
	KLb6DSKq4Db6RSpTMk2m6P6JsKqLMkbAHHjhJUUm8twPpPSFcCIn8cLY8eKo
	cJJkFsSeL70wj9KZkN4sc/IgitzAnXmATCaSRKKA14cubDbPHOC7F8pZAv8L
	Mg+xIIBbpk6cRtIjOEWczQgx8FkYpyIJQyYycyMZBVC060aZn0mCt1gA0mBW
	eaHU9Xvk5N8ZCBhPx1mjcS01ofV7BDkqIxhpUgIPKUNAXCY9RD0vDGH+5MFw
	n1BEWQ5Jhq7rJDN4MMQSBGlKkZDDuAKDOPZiipyJAzhL/NBHvM8BqylCegKr
	dSBiP3Jh3sHMA3lEVzeMgGtOJqCM0YjZ52OqkE7uOD5wk96WpT8wmNAREklG
	LqDTLM0zP0pzB4mGn3mJQApSOEWeg04+SwI+WeD5MwlccP1AAJIDEKI/rv6T
	hz5cO0SM8DwZBuEsDEPEtDAJsavjfFLmEuN0buyA/yDC33EigmyWIXYAK6Wg
	nC4MgyRHjuRnCZK6DBbsxxRKHJmEQaS8wYUkQl9mgRc5oZOEiYfvEUdjiU+j
	IMfxZrH0oyiH8P3YR9oSBoAgPyNjdz4pc/ksnDrIqVzERi8SiVN4UU7deCdL
	Emgz89IoRwRGwpAjvfEc4QQxcizhwZFnSGfhlh+NbZ+Fw8zzXQeAnUZkYDms
	OxVAZQRY3wdKuEhiBQIb7CnyKYQXYB3sOT7MHpnuxzOXzyPDoEBCmiGqFpEL
	ZylmCBhghvJpxBpKOPB5kkZZmDrSc3yYNrKYIssLFwl4tDO2fRbOUjjpLAfe
	In2K4Zs5Qlso4gyJnQ9vo/xauEFMyUDu+LPUm0FwwMxkJtIMPqPAEmh2lL3V
	k0HcW7DeP1UtaJl/uVeIRWveFdg926n/DaBuaIe8vOJ/XYRGs1SBWlLbprXl
	Tb2gcFjTuxf07zJRpFOv8LW2vh1H4f6Cb8dlrd957ZoSNMxkRanIrPupMDNc
	2PL8J882mpLc3FaaIdSWGDGvUKh/PYSb6Fyflp1qb1PVz1D/f0u+23s/UAAA
			<!-- [rfced] The terms listed below are enclosed in <tt> in this document.
			Some of these terms (e.g., "secret") appear both with and without <tt>.
			Please review to ensure the usage of <tt> is correct and consistent. Let
			us know if any updates are needed.
			application/sslkeylogfile
			client_application_traffic_secret_0
			client_random
			exporter_secret
			secret
			server_application_traffic_secret_0
			shared_secret
			SSLKEYLOGFILE
			-->
			<!-- [rfced] FYI - We have added expansions for the following abbreviations
			per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
			expansion in the document carefully to ensure correctness.
			Key Encapsulation Mechanism (KEM)
			Network Security Services (NSS)
			-->
			<!-- [rfced] Please review the "Inclusive Language" portion of the online
			Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
			and let us know if any changes are needed. Updates of this nature typically
			result in more precise language, which is helpful for readers.
			For example, please consider whether "master" should be updated.
	-->		-->
	</rfc>		</rfc>
End of changes. 77 change blocks.
	849 lines changed or deleted		438 lines changed or added
This html diff was produced by rfcdiff 1.48.