Hi, Responses to questions inline.
If you want to see the concrete recommendations, I have a pull request that I'm using to track changes. (The diff isn't immaculate, mostly due to differences in the references, but it includes the important changes.) https://github.com/tlswg/sslkeylogfile/pull/32 in case you want to follow along. On Wed, Dec 17, 2025, at 05:32, [email protected] wrote: > 1) <!-- [rfced] > 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. Sold. Thanks. > 2) <!--[rfced] Is "the Random" correct here, or should this be updated to "the > Random field" or "the value of the Random field"? I've changed to the latter, as in: > these labels MUST be followed by the value of the Random field from the Inner > ClientHello. > Otherwise, the Random field from the Outer ClientHello MUST be used. > 3) <!-- [rfced] Would updating "(e.g., [RFC8471])" and "(e.g., [RFC9261])" as > follows be more precise and clear? Please review. I don't think that this is necessary. I don't consider these examples important (both are essentially dead protocols to some degree). > 4) <!--[rfced] We have some questions about the citations > > a) RFC-to-be 9846 (draft-ietf-tls-rfc8446bis), which uses the citation [TLS13] > in this document, obsoletes RFC 8446. [...] > b) RFC 4492 has been obsoleted by RFC 8422. The updated documents should be used, yes. And your section reference updates are correct: > 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. Please go ahead. It's a good change. > b) Section 4.2: Please review the suggestions below for the description of > EARLY_EXPORTER_SECRET and let us know which is preferred. [...] > Or: > Early exporter secret I prefer this. If you could nudge IANA, that would be appreciated. > 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. Good catch. This was a little sloppy. I'll suggest a bigger edit below to catch both changes to that paragraph... > d) Is "location" the best word choice here? Would "organization", "group", or > something else be an improvement? Your suggestion is good. I'll include the entire paragraph, including my edit from above and your other edits, so that we are clear on where this ends up: > 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. Here is where I ended up: +New assignments in the "TLS SSLKEYLOGFILE Labels" registry will be administered by IANA through the +Specification Required procedure {{?RFC8126}}. The role of designated experts for TLS registries is described +in {{Section 17 of ?RFC8447}}. Designated experts for this registry are advised to ensure that the specification is +publicly available. In the Reference column, 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. +Designated experts may provide more in-depth reviews, but their approval should not be taken as an endorsement +of the SSLKEYLOGFILE label. Or, in text: New assignments in the "TLS SSLKEYLOGFILE Labels" registry will be administered by IANA through the Specification Required procedure [RFC8126]. The role of designated experts for TLS registries is described in Section 17 of [RFC8447]. Designated experts for this registry are advised to ensure that the specification is publicly available. In the Reference column, 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. Designated experts may provide more in-depth reviews, but their approval should not be taken as an endorsement of the SSLKEYLOGFILE label. > 6) <!--[rfced] This document contains an informative reference to [RFC8792], > but [...] > Perhaps: > The examples below use line wrapping per [RFC8792]. I'm going to suggest that we include that line, then remove the "comment" that cites 8792 in each of the three examples. With the added text, there is no need to add three copies of the comment. > 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. I think that sourcecode isn't right, but neither is artwork. I've changed to <sourcecode type="application/sslkeylogfile"> on my end, which seems like the best of a bunch of bad choices. (This is really just plaintext output, for which the HTML <pre> or <xmp> would be a better fit.) > 8) <!-- [rfced] The terms listed below are enclosed in <tt> in this document. I've updated the definition list <dt> usage of `secret`, `label`, and `client_random` to include <tt>, plus the first instance of `label` in the corresponding definition/<dd>. All other uses are correct from my review. > 9) <!-- [rfced] FYI - We have added expansions for the following abbreviations Perfect, thanks. > 10) <!-- [rfced] Please review the "Inclusive Language" Acknowledged. I'll note that this document uses "master" according to its definition in TLS 1.2. This is necessary, but the only instance of language that is likely to cause issues. -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
