<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4.4) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-tls-keylogfile-05" number="9850" updates="" obsoletes="" xml:lang="en" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3"><!-- xml2rfc v2v3 conversion 3.28.1 --><front> <title abbrev="SSLKEYLOGFILE">The SSLKEYLOGFILE Format for TLS</title> <seriesInfoname="Internet-Draft" value="draft-ietf-tls-keylogfile-05"/>name="RFC" value="9850"/> <author fullname="Martin Thomson"> <organization>Mozilla</organization> <address> <email>mt@lowentropy.net</email> </address> </author> <author fullname="Yaroslav Rosomakho"> <organization>Zscaler</organization> <address> <email>yrosomakho@zscaler.com</email> </address> </author> <author fullname="Hannes Tschofenig"> <organization abbrev="H-BRS">University of Applied Sciences Bonn-Rhein-Sieg</organization> <address> <email>Hannes.Tschofenig@gmx.net</email> </address> </author> <date year="2025"month="June" day="09"/> <area>Security</area> <workgroup>Transport Layer Security</workgroup>month="December"/> <area>SEC</area> <workgroup>tls</workgroup> <keyword>network transparency</keyword> <keyword>tls</keyword> <keyword>blockchain</keyword> <abstract><?line 47?> <t>A<t>This document describes a format that supports logging information about the secrets used in a TLSconnection is described.connection. Recording secrets to a file in SSLKEYLOGFILE format 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 TLS only protects test data.</t> </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="mailto:tls@ietf.org"/>), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/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> <middle><?line 56?><section anchor="introduction"> <name>Introduction</name> <t>Debugging or analyzing protocols can be challenging when TLS <xreftarget="TLS13"/>target="RFC9846"/> is used to protect the content of communications. Inspecting the content of encrypted messages in diagnostic tools can enable more thorough analysis.</t> <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 implementations, the file that the secrets are logged to is specified in an environment variable named "SSLKEYLOGFILE", hence the name of SSLKEYLOGFILE format. Note the use of "SSL" as this convention originally predates the adoption of TLS as the name of the protocol.</t> <t>This document describes the SSLKEYLOGFILE format. This format can be used for TLS 1.2 <xreftarget="TLS12"/>target="RFC5246"/> and TLS 1.3 <xreftarget="TLS13"/>.target="RFC9846"/>. The format also supports earlier TLS versions, though use of earlier versions is strongly discouraged <xreftarget="RFC8996"/><xreftarget="RFC8996"/> <xref target="RFC9325"/>. This format can also be used with DTLS <xreftarget="DTLS13"/>,target="RFC9147"/>, QUIC <xreftarget="RFC9000"/><xreftarget="RFC9000"/> <xref target="RFC9001"/>, and other protocols thatalsouse the TLS key schedule. Use of this format could complement other protocol-specific logging such asQLOGqlog <xreftarget="QLOG"/>.</t>target="I-D.ietf-quic-qlog-main-schema"/>.</t> <t>This document also defines labels that can be used to log information about exchanges that use Encrypted Client Hello (ECH) <xreftarget="ECH"/>.</t>target="RFC9849"/>.</t> <section anchor="applicability-statement"> <name>Applicability Statement</name> <t>The artifact that this document describes--- if made available to entities other than endpoints--- completely undermines the core guarantees that TLS provides. 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 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 compilation is the best way to ensure that deployed binaries cannot be configured to enable key logging.</t> <t><xref target="security"/> addresses a number of additional concerns that arise from the use of key logging.</t> </section> <section anchor="conventions-and-definitions"><name>Conventions and Definitions</name> <t>The<name>Conventions</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 inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> </section> </section> <section anchor="the-sslkeylogfile-format"> <name>The SSLKEYLOGFILE Format</name> <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 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> contain a Unicode byte order mark (U+FEFF).</t> <t>Lines are terminated using theline endingline-ending convention of the platform on which the file is generated. Tools that process these files <bcp14>MUST</bcp14> accept CRLF (U+13 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 ('#', 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 those secrets are generated.</t> <t>Each secret is described using a single line composed of three values that are 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 defined in this document. --> <dl spacing="normal" newline="true"> <dt>label:</dt> <dd> <t>The label identifies the type of secret that is being conveyed; see <xref target="labels"/> fora descriptiondescriptions of the labels that are defined in this document.</t> </dd> <dt>client_random:</dt> <dd> <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 characters. In a log that can include secrets from multiple connections, this field can be used to identify a connection.</t> </dd> <dt>secret:</dt> <dd> <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 secret.</t> </dd> </dl> <t>For the hexadecimal values ofthe<tt>client_random</tt> or <tt>secret</tt>, no convention exists for the case of characters'a'"a" through'f'"f" (or'A'"A" through'F')."F"). Files can be generated with either, so either form <bcp14>MUST</bcp14> be accepted when processing a file.</t> <t>Diagnostic tools that accept files in this format might choose to ignore lines that do not conform to this format in the interest of ensuring that secrets can be obtained from corrupted files.</t> <t>Logged secret values are not annotated with the cipher suite or other connection parameters.ATherefore, a record of the TLS handshake mightthereforebe needed to use the logged secrets.</t> <section anchor="labels"> <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 the key schedule (see <xref section="7.1" sectionFormat="of"target="TLS13"/>).target="RFC9846"/>). If ECH was successfully negotiated for a given connection, these labels <bcp14>MUST</bcp14> be followed by the Random from the Inner ClientHello. Otherwise, the Random from the Outer ClientHello <bcp14>MUST</bcp14> be used.</t> <t>Each of the following labels correspond to the equivalent secret produced by the key schedule:</t> <dl spacing="normal" newline="true"> <dt>CLIENT_EARLY_TRAFFIC_SECRET:</dt> <dd> <t>This secret is used to protect records sent by the client as early data, if 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 so unconditionally.</t> </dd> <dt>EARLY_EXPORTER_SECRET:</dt> <dd> <t>This secret is used for early exporters. LiketheCLIENT_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> </dd> <dt>CLIENT_HANDSHAKE_TRAFFIC_SECRET:</dt> <dd> <t>This secret is used to protect handshake records sent by the client.</t> </dd> <dt>SERVER_HANDSHAKE_TRAFFIC_SECRET:</dt> <dd> <t>This secret is used to protect handshake records sent by the server.</t> </dd> <dt>CLIENT_TRAFFIC_SECRET_0:</dt> <dd> <t>This secret is used to protect application_data records sent by the client immediately after the handshake completes. This secret is identified as <tt>client_application_traffic_secret_0</tt> in the TLS 1.3 key schedule.</t> </dd> <dt>SERVER_TRAFFIC_SECRET_0:</dt> <dd> <t>This secret is used to protect application_data records sent by the server 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> </dd> <dt>EXPORTER_SECRET:</dt> <dd> <t>This secret is used in generating exporters<xref(<xref section="7.5" sectionFormat="of"target="TLS13"/>.</t>target="RFC9846"/>).</t> </dd> </dl> <t>These labels all appear in uppercase in the key log, but they correspond to lowercase labels in the TLS key schedule (<xref section="7.1" sectionFormat="of"target="TLS13"/>),target="RFC9846"/>), except for the application data secrets as noted. For example, "EXPORTER_SECRET" in the 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 they are presented in <xreftarget="TLS13"/>,target="RFC9846"/>, but there is no guarantee that implementations will log secrets strictly in this order.</t> </section> <section anchor="secret-labels-for-tls-12"> <name>Secret Labels for TLS 1.2</name> <t>Implementations of TLS 1.2 <xreftarget="TLS12"/>target="RFC5246"/> (and also earlier versions) use the label "CLIENT_RANDOM" to identify the "master" secret for the connection.</t> </section> <section anchor="secret-labels-for-ech"> <name>Secret Labels for ECH</name> <t>With ECH <xreftarget="ECH"/>,target="RFC9849"/>, additional secrets are derived during the handshake to encrypt the Inner ClientHello message using Hybrid Public Key Encryption (HPKE) <xreftarget="HPKE"/>.target="RFC9180"/>. A client can log the ECH labels described below if it offeredECHECH, regardless of server acceptance. The server can log the labels only if it successfully decrypted the ECH offered by the client, though it could choose to do so only when it accepts ECH.</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> <dd> <t>This label corresponds to theKEMKey Encapsulation Mechanism (KEM) shared secret used by HPKE (<tt>shared_secret</tt> in the algorithms in <xref section="5.1.1" sectionFormat="of"target="HPKE"/>). Lengthtarget="RFC9180"/>). The length of the secret is defined by the KEM negotiated for use with ECH.</t> </dd> <dt>ECH_CONFIG:</dt> <dd> <t>The ECHConfig used to construct the ECH extension. The value is logged in hexadecimal representation.</t> </dd> </dl> </section> </section> <section anchor="security"> <name>Security Considerations</name> <t>Access to the content of a file in SSLKEYLOGFILE format allows an attacker to break the confidentiality and integrity protection on any TLS connections that are included in the file. This includes both active connections and connections for which encrypted records were previously stored.EnsuringTherefore, ensuring adequate access control on these filesthereforebecomes very important.</t> <t>Implementations that support logging this data need to ensure that logging can 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 of connections for which secrets are logged could represent a privilege escalation attack. Implementations that enable logging also need to ensure that access to logged secrets is limited, using appropriate file permissions or equivalent access control mechanisms.</t> <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 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 modification of application data on a connection that would otherwise be 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 SSLKEYLOGFILE format includes keys that identify the secret used in TLS exporters or early exporters (<xref section="7.5" sectionFormat="of"target="TLS13"/>).target="RFC9846"/>). Knowledge of these secrets can enable more than inspection or modification of encrypted data, depending on how an application protocol uses exporters. For instance, exporters might be used for session bindings (e.g., <xref target="RFC8471"/>), authentication (e.g., <xref target="RFC9261"/>), or 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 applications. A TLS implementation might either choose to omit these secrets in contexts where the information might be abused or require separate authorization to enable logging of exporter secrets.</t> <t>Using an environment variable, such as <tt>SSLKEYLOGFILE</tt>, to enable logging implies that access to the launch context for the application is needed to authorize logging. On systems that supportspecially-namedspecially named files, logs might be directed to these names so that logging does not result instorage,storage butenableenables consumption by other programs. In both cases, applications might require special authorization ortheymight rely on system-level access control to limit 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 target="RFC8446" section="1.2" sectionFormat="bare"/> and Appendix <xref target="RFC8446" 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. Access to key material allows an attacker to decrypt data exchanged in any previously logged TLS connections.</t> <t>Logging the TLS 1.2 "master" secret provides the recipient of that secret far greater access to an active connection than TLS 1.3secrets.secrets provide. In addition to reading and altering protected messages, the TLS 1.2 "master" secret confers the ability to resume the connection and impersonate either endpoint, insert records that result in renegotiation, and forge Finished messages. Implementations can avoid the risks associated with these capabilities by not logging this secret value.</t> <t>Access to the ECH_SECRET record intheSSLKEYLOGFILE allows the attacker to decrypt the ECH extension and thereby reveal the content of the Inner ClientHello message, including the payload of the Server Name Indication (SNI) extension.</t> <t>Access to the HPKE-established shared secret used in ECH introduces a potential attack surface against the HPKE library since access to this keying material is normally not available otherwise.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <t>This document registers a media type (<xref target="iana-media"/>) and creates a registry for labels (<xref target="iana-labels-registry"/>).</t> <!-- [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-sslkeylogfile-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> <t>The "<tt>application/sslkeylogfile</tt>" media type can be used to describe content in the SSLKEYLOGFILE format. IANA[has added/is requested to add]has added the following information to the "Media Types" registry at <ereftarget="https://www.iana.org/assignments/media-types">https://www.iana.org/assignments/media-types</eref>:</t>brackets="angle" target="https://www.iana.org/assignments/media-types"/>:</t> <dlspacing="compact">spacing="normal" newline="false"> <dt>Typename:</dt> <dd> <t>application</t> </dd>name:</dt><dd>application</dd> <dt>Subtype name:</dt><dd> <t>sslkeylogfile</t> </dd><dd>sslkeylogfile</dd> <dt>Required parameters:</dt><dd> <t>N/A</t> </dd><dd>N/A</dd> <dt>Optional parameters:</dt><dd> <t>N/A</t> </dd><dd>N/A</dd> <dt>Encoding considerations:</dt><dd> <t>UTF-8<dd>UTF-8 without BOM, or ASCIIonly</t> </dd>only</dd> <dt>Security considerations:</dt><dd> <t>See<dd>See <xreftarget="security"/>.</t> </dd>target="security"/>.</dd> <dt>Interoperability considerations:</dt><dd> <t>Line<dd>Line endings might differ from platformconvention</t> </dd>convention.</dd> <dt>Published specification:</dt><dd> <t>RFC XXXX (RFC Editor: please update)</t> </dd><dd>RFC 9850</dd> <dt>Applications that use this media type:</dt><dd> <t>Diagnostic<dd>Diagnostic and analysis tools that need to decrypt data that is otherwise protected byTLS.</t> </dd>TLS.</dd> <dt>Fragment identifier considerations:</dt><dd> <t>N/A</t> </dd><dd>N/A</dd> <dt>Additional information:</dt><dd><dd><t><br/></t> <dl spacing="compact"> <dt>Deprecated alias names for this type:</dt> <dd>N/A</dd> <dt>Magic number(s):</dt> <dd>N/A</dd> <dt>File extension(s):</dt> <dd>N/A</dd> <dt>Macintosh file type code(s):</dt> <dd>N/A</dd> </dl> </dd> <dt>Person & email address to contact for further information:</dt><dd> <t>TLS<dd><br/>TLS WG(tls@ietf.org)</t> </dd>(tls@ietf.org)</dd> <dt>Intended usage:</dt><dd> <t>COMMON</t> </dd><dd>COMMON</dd> <dt>Restrictions on usage:</dt><dd> <t>N/A</t> </dd><dd>N/A</dd> <dt>Author:</dt><dd> <t>IETF<dd>IETF TLS WorkingGroup</t> </dd>Group</dd> <dt>Change controller:</dt><dd> <t>IETF</t> </dd><dd>IETF</dd> </dl> </section> <section anchor="iana-labels-registry"><name>SSLKEYLOGFILE<name>TLS SSLKEYLOGFILE Labels Registry</name> <t>IANAis requested to createhas created a new registry named "TLS SSLKEYLOGFILELabels",Labels" within the existing "Transport Layer Security (TLS) Parameters" registrypage.group. This new registry reserves labels used for SSLKEYLOGFILE entries. The initial contents of this registry are asfollows.</t>follows:</t> <table> <thead> <tr> <th align="left">Value</th> <th align="left">Description</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">CLIENT_RANDOM</td> <td align="left">Master secret in TLS 1.2 and earlier</td> <tdalign="left">This document</td>align="left">RFC 9850</td> </tr> <tr> <td align="left">CLIENT_EARLY_TRAFFIC_SECRET</td> <td align="left">Secret for client early data records</td> <tdalign="left">This document</td>align="left">RFC 9850</td> </tr> <tr> <td align="left">EARLY_EXPORTER_SECRET</td> <td align="left">Early exporters secret</td> <tdalign="left">This document</td>align="left">RFC 9850</td> </tr> <tr> <td align="left">CLIENT_HANDSHAKE_TRAFFIC_SECRET</td> <td align="left">Secret protecting client handshake</td> <tdalign="left">This document</td>align="left">RFC 9850</td> </tr> <tr> <td align="left">SERVER_HANDSHAKE_TRAFFIC_SECRET</td> <td align="left">Secret protecting server handshake</td> <tdalign="left">This document</td>align="left">RFC 9850</td> </tr> <tr> <td align="left">CLIENT_TRAFFIC_SECRET_0</td> <td align="left">Secret protecting client records post handshake</td> <tdalign="left">This document</td>align="left">RFC 9850</td> </tr> <tr> <td align="left">SERVER_TRAFFIC_SECRET_0</td> <td align="left">Secret protecting server records post handshake</td> <tdalign="left">This document</td>align="left">RFC 9850</td> </tr> <tr> <td align="left">EXPORTER_SECRET</td> <td align="left">Exporter secret after handshake</td> <tdalign="left">This document</td>align="left">RFC 9850</td> </tr> <tr> <td align="left">ECH_SECRET</td> <td align="left">HPKE KEM shared secret used in the ECH</td> <tdalign="left">This document</td>align="left">RFC 9850</td> </tr> <tr> <td align="left">ECH_CONFIG</td> <td align="left">ECHConfig used for construction of the ECH</td> <tdalign="left">This document</td>align="left">RFC 9850</td> </tr> </tbody> </table> <t>New assignments in the"SSLKEYLOGFILE"TLS SSLKEYLOGFILE Labels" registry will be administered by IANA through the Specification Required procedure <xref target="RFC8126"/>. The role of the designated expert is described in <xref section="17" sectionFormat="of" target="RFC8447"/>. The designated expert <xref target="RFC8126"/> ensures that the specification is publicly available.ItIn the Reference column, it is sufficient tohavecite an Internet-Draft (that is postedand neverbut not published as an RFC) orto citea document from another standards body, an industry consortium, or any other location.AnThe designated expert may provide more in-depth reviews, but their approval should not be taken as an endorsement of the SSLKEYLOGFILE label.</t> </section> </section> </middle> <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"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name> <!-- [RFC9846 / TLS] draft-ietf-tls-rfc8446bis-14 companion doc in RFC-EDITOR as of 12/12/25 --> <referenceanchor="TLS13">anchor="RFC9846" target="https://www.rfc-editor.org/info/rfc9846"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <authorfullname="Eric Rescorla"initials="E."surname="Rescorla">surname="Rescorla" fullname="Eric Rescorla"> <organization>Independent</organization> </author> <dateday="17" month="February" year="2025"/> <abstract> <t> This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and 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</title> <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 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>month='December' year='2025'/> </front> <seriesInfo name="RFC"value="5246"/>value="9846"/> <seriesInfo name="DOI"value="10.17487/RFC5246"/>value="10.17487/RFC9846"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/> <!-- [RFC9849 / ECH] draft-ietf-tls-esni-25 companion doc in AUTH48 as of 11/14/25 --> <referenceanchor="ECH">anchor="RFC9849" target="https://www.rfc-editor.org/info/rfc9849"> <front> <title>TLS Encrypted Client Hello</title> <authorfullname="Eric Rescorla"initials="E."surname="Rescorla">surname="Rescorla" fullname="Eric Rescorla"> <organization>Independent</organization> </author> <authorfullname="Kazuho Oku"initials="K."surname="Oku">surname="Oku" fullname="Kazuho Oku"> <organization>Fastly</organization> </author> <authorfullname="Nick Sullivan"initials="N."surname="Sullivan">surname="Sullivan" fullname="Nick Sullivan"> <organization>Cryptography Consulting LLC</organization> </author> <authorfullname="Christopher A. Wood"initials="C. A."surname="Wood">surname="Wood" fullname="Christopher A. Wood"> <organization>Cloudflare</organization> </author> <dateday="20" month="March" year="2025"/> <abstract> <t> This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni). </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-24"/> </reference> <reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <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 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> <reference anchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <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 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> <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 Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full 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>month='December' year='2025'/> </front> <seriesInfoname="STD" value="63"/> <seriesInfoname="RFC"value="3629"/>value="9849"/> <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 encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated 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 derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key 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"/>value="10.17487/RFC9849"/> </reference> <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.3629.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9180.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name><reference anchor="RFC8792"> <front> <title>Handling Long Lines in Content of Internet-Drafts and RFCs</title> <author fullname="K. Watsen" initials="K." surname="Watsen"/> <author fullname="E. Auerswald" initials="E." surname="Auerswald"/> <author fullname="A. Farrel" initials="A." surname="Farrel"/> <author fullname="Q. Wu" initials="Q." surname="Wu"/> <date month="June" year="2020"/> <abstract> <t>This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.</t> </abstract> </front> <seriesInfo name="RFC" value="8792"/> <seriesInfo name="DOI" value="10.17487/RFC8792"/> </reference> <reference anchor="RFC8996"> <front> <title>Deprecating TLS 1.0 and TLS 1.1</title> <author fullname="K. Moriarty" initials="K." surname="Moriarty"/> <author fullname="S. Farrell" initials="S." surname="Farrell"/> <date month="March" year="2021"/> <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 that normatively refer to TLS version 1.0 or TLS version 1.1,<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8792.xml"/> <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"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9001.xml"/> <!-- [QLOG] draft-ietf-quic-qlog-main-schema-13 IESG State: I-D Exists asdescribed herein. This document also updates the best practices for TLS usage 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"> <front> <title>Recommendations for Secure UseofTransport 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, 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> <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 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> <reference anchor="RFC9000"> <front> <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/> <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/> <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 communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration 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="Thomson"/> <author fullname="S. Turner" initials="S." role="editor" surname="Turner"/> <date month="May" year="2021"/> <abstract> <t>This document describes how Transport Layer Security (TLS) is used to secure QUIC.</t> </abstract> </front> <seriesInfo name="RFC" value="9001"/> <seriesInfo name="DOI" value="10.17487/RFC9001"/> </reference>09/30/25 --> <referenceanchor="QLOG">anchor="I-D.ietf-quic-qlog-main-schema" target="https://datatracker.ietf.org/doc/html/draft-ietf-quic-qlog-main-schema-13"> <front> <title>qlog: Structured Logging for Network Protocols</title> <author initials="R." surname="Marx" fullname="Robin Marx"initials="R." surname="Marx">role="editor"> <organization>Akamai</organization> </author> <author initials="L." surname="Niccolini" fullname="Luca Niccolini"initials="L." surname="Niccolini">role="editor"> <organization>Meta</organization> </author> <author initials="M." surname="Seemann" fullname="Marten Seemann"initials="M." surname="Seemann">role="editor"> </author> <author initials="L." surname="Pardue" fullname="Lucas Pardue"initials="L." surname="Pardue">role="editor"> <organization>Cloudflare</organization> </author> <dateday="17" month="March"month="October" day="20" year="2025"/><abstract> <t> qlog provides extensible structured logging for network protocols, 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. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. Concrete examples of integrations of this schema in various programming languages can be found at https://github.com/quiclog/ qlog/ (https://github.com/quiclog/qlog/). </t> </abstract></front> <seriesInfo name="Internet-Draft"value="draft-ietf-quic-qlog-main-schema-11"/>value="draft-ietf-quic-qlog-main-schema-13"/> </reference><reference anchor="RFC0020"> <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="Popov"/> <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<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0020.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8471.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9261.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.4492.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8447.xml"/> </references> </references> <section anchor="example"> <name>Example</name> <t>The following is a sample ofthe Token Binding protocol. The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections. Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks. To protect privacy, 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 Authenticatorsa file inTLS</title> <author fullname="N. Sullivan" initials="N." surname="Sullivan"/> <date month="July" year="2022"/> <abstract> <t>ThisSSLKEYLOGFILE format, including secrets from two TLS 1.3 connections.</t> <!--[rfced] This documentdescribes a mechanism that builds on Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) and enables peers to provide proof of ownership ofcontains anidentity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out of bandinformative reference to [RFC8792], but theother 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</title> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> <date month="August" year="2018"/> <abstract> <t>This document specifies version 1.3only mentions ofthe Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the InternetRFC 8792 are ina way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t> </abstract> </front> <seriesInfo name="RFC" value="8446"/> <seriesInfo name="DOI" value="10.17487/RFC8446"/> </reference> <reference anchor="RFC4492"> <front> <title>Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)</title> <author fullname="S. Blake-Wilson" initials="S." surname="Blake-Wilson"/> <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 Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreementnotes within <artwork> in Appendix A. Where may we cite [RFC8792] ina TLS handshake andtheuse of Elliptic Curve Digital Signature Algorithm (ECDSA) astext? We suggest adding anew authentication mechanism. This memo provides information forsentence at theInternet 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 usebeginning ofpoints of extensibility thatAppendix A as follows. Perhaps: The examples below useconstants to identify various protocol parameters. To ensure thatline wrapping per [RFC8792]. --> <!-- [rfced] Please review thevaluesartwork elements used in Appendix A. Should thesefields do not have conflicting uses and to promote interoperability, their allocations 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 describing the conditions under which new values shouldbeassigned,tagged aswell as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation ofsourcecode instead? If theseguidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely inshould be sourcecode, please let us whether theoperation of a registry.</t> <t>This is"type" attribute should be set. If thethird editioncurrent list ofthis document; it obsoletes RFC 5226.</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 Updatespreferred values forTLS 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 IANA registries that range from adding notes"type" (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) does not contain an applicable type, then feel free tothe registry all the waysuggest a new one. Also, it is acceptable tochangingleave theregistration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process.</t> <t>This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.</t> </abstract> </front> <seriesInfo name="RFC" value="8447"/> <seriesInfo name="DOI" value="10.17487/RFC8447"/> </reference> </references> </references> <?line 436?> <section anchor="example"> <name>Example</name> <t>The following is a sample of a file in this format, including secrets from two TLS 1.3 connections.</t>"type" attribute not set. --> <artwork><![CDATA[ # NOTE: '\' line wrapping per RFC 8792 CLIENT_HANDSHAKE_TRAFFIC_SECRET \ cf34899b3dcb8c9fe7160ceaf95d354a294793b67a2e49cb9cca4d69b43593a0 \ be4a28d81ce41242ff31c6d8a6615852178f2cd75eaca2ee8768f9ed51282b38 SERVER_HANDSHAKE_TRAFFIC_SECRET \ cf34899b3dcb8c9fe7160ceaf95d354a294793b67a2e49cb9cca4d69b43593a0 \ 258179721fa704e2f1ee16688b4b0419967ddea5624cd5ad0863288dc5ead35f CLIENT_HANDSHAKE_TRAFFIC_SECRET \ b2eb93b8ddab8c228993567947bca1e133736980c22754687874e3896f7d6d0a \ 59ec0981b211a743f22d5a46a1fc77a2b230e16ef0de6d4e418abfe90eff10bf SERVER_HANDSHAKE_TRAFFIC_SECRET \ b2eb93b8ddab8c228993567947bca1e133736980c22754687874e3896f7d6d0a \ a37fe4d3b6c9a6a372396b1562f6f8a40c1c3f85f1aa9b02d5ed46c4a1301365 CLIENT_TRAFFIC_SECRET_0 \ cf34899b3dcb8c9fe7160ceaf95d354a294793b67a2e49cb9cca4d69b43593a0 \ e9ca165bcb762fab8086068929d26c532e90ef2e2daa762d8b52346951a34c02 SERVER_TRAFFIC_SECRET_0 \ cf34899b3dcb8c9fe7160ceaf95d354a294793b67a2e49cb9cca4d69b43593a0 \ 4f93c61ac1393008d4c820f3723db3c67494f06574b65fcc21c9eef22f90071a EXPORTER_SECRET \ cf34899b3dcb8c9fe7160ceaf95d354a294793b67a2e49cb9cca4d69b43593a0 \ 011c900833468f837f7c55d836b2719beebd39b1648fdeda58772f48d94a1ffa CLIENT_TRAFFIC_SECRET_0 \ b2eb93b8ddab8c228993567947bca1e133736980c22754687874e3896f7d6d0a \ e9160bca1a531d871f5ecf51943d8cfb88833adeccf97701546b5fb93e030d79 SERVER_TRAFFIC_SECRET_0 \ b2eb93b8ddab8c228993567947bca1e133736980c22754687874e3896f7d6d0a \ fb1120b91e48d402fac20faa33880e77bace82c85d6688df0aa99bf5084430e4 EXPORTER_SECRET \ b2eb93b8ddab8c228993567947bca1e133736980c22754687874e3896f7d6d0a \ db1f4fa1a6942fb125d4cc47e02938b6f8030c6956bb81b9e3269f1cf855a8f8 ]]></artwork> <t>Note that secrets from the two connections might be interleaved as shown here, because secrets could be logged as they are generated.</t> <t>The following shows a log entry for a TLS 1.2 connection.</t> <artwork><![CDATA[ # NOTE: '\' line wrapping per RFC 8792 CLIENT_RANDOM \ ad52329fcadd34ee3aa07092680287f09954823e26d7b5ae25c0d47714152a6a \ 97af4c8618cfdc0b2326e590114c2ec04b43b08b7e2c3f8124cc61a3b068ba966\ 9517e744e3117c3ce6c538a2d88dfdf ]]></artwork> <t>The following shows a log entry for a TLS 1.3 connection that successfully negotiated ECH.</t> <artwork><![CDATA[ # NOTE: '\' line wrapping per RFC 8792 ECH_SECRET \ 0ba587ee6b65ce21a726630efb881206a7cd995611095b5f4c244bb2b23f1ee1 \ e8828ec09909cc9363179dc13b62498550c8637129345263011a1678370ca52a ECH_CONFIG \ 0ba587ee6b65ce21a726630efb881206a7cd995611095b5f4c244bb2b23f1ee1 \ fe0d003c5500200020d5260ae4cdda08bcbdc37bd0dc53c29aea5f0fdd2b2d594\ e4235e99b134ac904000400010001000d636f7665722e6465666f2e69650000 CLIENT_HANDSHAKE_TRAFFIC_SECRET \ 8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \ a195b63ec4270609692a204c08e63e74d9ae58e377d11a383bfe641a63c01140 SERVER_HANDSHAKE_TRAFFIC_SECRET \ 8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \ 022d1cb827a90f27dadde0c99110c2b7d0f362fdfe420a04818aa223e5f2c14c CLIENT_TRAFFIC_SECRET_0 \ 8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \ c2310f7db71109de88bab6f2f433fdc1704aecc0d57349cbf9113e5033178172 SERVER_TRAFFIC_SECRET_0 \ 8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \ 04ffc7c154f71ba5f530c7344b0496f60ce71b9b7c6b0e203ea574bfcdf14e27 EXPORTER_SECRET \ 8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \ befb5db5ac6785b5dd4c6a8c4693c379ec0a1486b5fd035b25e50c3c95abc500 ]]></artwork> </section> <section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>The SSLKEYLOGFILE format originated in theNSSNetwork Security Services (NSS) project, but it has evolved over time as TLS has changed. Many people contributed to this evolution. The authors are only documenting the format as it is used while extending it to cover ECH.</t> </section> </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>