Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
1) <!-- [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. --> 2) <!--[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. --> 3) <!-- [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. --> 4) <!--[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. --> 5) <!-- [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. --> 6) <!--[rfced] This document contains an informative reference to [RFC8792], but the only mentions of RFC 8792 are in notes within <artwork> in Appendix A. Where may we cite [RFC8792] in the text? We suggest adding a sentence at the beginning of Appendix A as follows. Perhaps: The examples below use line wrapping per [RFC8792]. --> 7) <!-- [rfced] Please review the artwork elements used in Appendix A. Should these be tagged as sourcecode instead? If these should be sourcecode, please let us whether the "type" attribute should be set. If the current list of preferred values for "type" (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) does not contain an applicable type, then feel free to suggest a new one. Also, it is acceptable to leave the "type" attribute not set. --> 8) <!-- [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 --> 9) <!-- [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) --> 10) <!-- [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. --> Thank you. Alanna Paloma and Rebecca VanRheenen RFC Production Center On Dec 16, 2025, at 10:29 AM, [email protected] wrote: *****IMPORTANT***** Updated 2025/12/16 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * [email protected] (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * [email protected], which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, [email protected] will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9850.xml https://www.rfc-editor.org/authors/rfc9850.html https://www.rfc-editor.org/authors/rfc9850.pdf https://www.rfc-editor.org/authors/rfc9850.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9850-diff.html https://www.rfc-editor.org/authors/rfc9850-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9850-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9850 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9850 (draft-ietf-tls-keylogfile-05) Title : The SSLKEYLOGFILE Format for TLS Author(s) : M. Thomson, Y. Rosomakho, H. Tschofenig WG Chair(s) : Joseph A. Salowey, Sean Turner, Deirdre Connolly Area Director(s) : Deb Cooley, Paul Wouters -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
