Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 2) <!-- [rfced] The document header indicates it obsoletes and updates the following RFCs: Obsoletes: 8446 Updates: 5705, 6066, 7627, 8422 In the body of the document, we see the text below. Note that the mentions of updates seem consistent with the document header. However, the text specifies that it obsoletes more than just RFC 8446, likely because RFC 8446 obsoleted those documents. Please review and let us know how/if the header can be consistent with the body of the document. a) Abstract: Note that we removed 8422 from the obsoletes list because this doc seemingly updates it. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. b) Introduction: This document supersedes and obsoletes previous versions of TLS, including version 1.2 [RFC5246]. It also obsoletes the TLS ticket mechanism defined in [RFC5077] and replaces it with the mechanism defined in Section 2.2. Because TLS 1.3 changes the way keys are derived, it updates [RFC5705] as described in Section 7.5. It also changes how Online Certificate Status Protocol (OCSP) messages are carried and therefore updates [RFC6066] and obsoletes [RFC6961] as described in Section 4.4.2.1. --> 3) <!--[rfced] The following RFCs have been obsoleted as follows. May they be replaced with the obsoleting RFC? RFC 6347 has been obsoleted by RFC 9147 RFC 6962 has been obsoleted by RFC 9162 RFC 7507 has been obsoleted by RFC 8996 --> 4) <!-- [rfced] This reference appears to match the information for the following Internet-Draft: https://datatracker.ietf.org/doc/draft-hickman-netscape-ssl/ May we update this reference to point to this I-D? Current: [SSL2] Hickman, K., "The SSL Protocol", 9 February 1995. Perhaps: [SSL2] Elgamal, T. and K. E. Hickman, "The SSL Protocol", Work in Progress, Internet-Draft, draft-hickman-netscape-ssl-00, 19 April 1995, <https://datatracker.ietf.org/doc/html/ draft-hickman-netscape-ssl-00>. --> 5) <!-- [rfced] We updated [I-D.ietf-tls-esni] to [PRE-RFC9849] for now. We will make the final updates in RFCXML. --> 6) <!--[rfced] As "requiring" and "should" seem to contradict in this statement, may we remove "should" from the text below? Original: * Clarify behavior around "user_canceled", requiring that "close_notify" be sent and that "user_canceled" should be ignored. Perhaps: * Clarify behavior around "user_canceled", requiring that "close_notify" be sent and that "user_canceled" be ignored. --> 7) <!--[rfced] FYI - We have updated Figure 1 to fit the 72-character limit. Please review and let us know if any further updates are needed. --> 8) <!--[rfced] The SVG in Figures 1 and 4 are outputting a solid circle for this text, while the figure displays *. Please review. One possible fix would be to move the legend outside of the figure. Please review and let us know how this may be updated. Original: * Indicates optional or situation-dependent messages/extensions that are not always sent. --> 9) <!--[rfced] Table 1 a) FYI - We have updated the citation for "record_size_limit" from [RFC8849] to [RFC8449], as [RFC8449] defines the extension and [RFC8849] does not have any mention of it. Original: record_size_limit [RFC8849] Current: record_size_limit [RFC8449] b) We note that RFC 9345 uses "delegated_credential" rather than "delegated_credentials" (no "s"). May we update the extension to reflect RFC 9345? Current: delegated_credentials {{RFC9345}} --> 10) <!-- [rfced] Table 2 extends one character line beyond the width limit. We will play with this in the RFCXML file, but please let us know if you see a good way to break the lines differently. --> 11) <!--[rfced] We believe the intention of this line to note that the asterisk has a specific meaning when present. Please note that we will update the XML to treat this as <dl>. Currently, kramdown treats this as a bulleted list item, and definition list yields the following: *: Only included if present. --> 12) <!--[rfced] May we rephrase the definition of this error alert to improve readability and provide clarity? Original: unrecognized_name: Sent by servers when no server exists identified by the name provided by the client via the "server_name" extension (see [RFC6066]). Perhaps: unrecognized_name: Sent by servers when no server that can be identified by the name provided by the client via the "server_name" extension (see [RFC6066]) exists. --> 13) <!--[rfced] In Section 9.1, may we format these two items into an unordered list? Original: In the absence of an application profile standard specifying otherwise: A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see Appendix B.4). A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748]. Perhaps: In the absence of an application profile standard specifying otherwise: * A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see Appendix B.4). * A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748]. --> 14) <!--[rfced] FYI, we have updated the parenthetical text as follows to better describe the "TLS Supported Groups" registry. Please review and let us know of any objections. Original: This document updates two entries in the TLS Supported Groups registry (created under a different name by [RFC4492]; now maintained by [RFC8422]) and updated by [RFC7919] and [RFC8447]. Current: This document updates two entries in the "TLS Supported Groups" registry (created under a different name by [RFC4492]; now maintained by [RFC8422] and updated by [RFC7919] and [RFC8447]). --> 15) <!--[rfced] We note that some author comments are present in the markdown file. Please confirm that no updates related to these comments are outstanding. Note that the comments will be deleted prior to publication. {::comment}Cite IND-CPA?{:/comment} {::comment}Cite INT-CTXT?{:/comment} --> 16) <!--[rfced] FYI - We have updated some artwork to sourcecode. Please review and let us know if further updates are necessary. --> 17) <!-- [rfced] Please review whether any of the notes in this document should be in the <aside> element. It is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). --> 18) <!-- [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. Elliptic Curve Cryptography (ECC) Finite Field DHE (FFDHE) Internet of Things (IoT) --> 19) <!-- [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 the following should be updated: dummy man-in-the-middle In addition, please consider whether "traditionally" should be updated for clarity. While the NIST website <https://web.archive.org/web/20250203031433/https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8366.pdf> indicates that this term is potentially biased, it is also ambiguous. "Tradition" is a subjective term, as it is not the same for everyone. --> 20) <!-- [rfced] FYI - we will convert the list of Contributors contained within <artwork> to be listed with the <contact> element once the file is converted to RFCXML. In addition, we will update the following reference entries that were a challenge to update in markdown. [BBFGKZ16] [BBK17] [CCG16] [CHECKOWAY] [CHSV16] [JSS15] [LXZFH16] [SLOTH] [CK01] [CLINIC] [DH76] [DOW92] [HCJC16] [RSA] [SIGMA] [FETCH] [SHS] [DSS] [ECDP] [KEYAGREEMENT] --> Thank you. Alanna Paloma and Sandy Ginoza RFC Production Center On Dec 15, 2025, at 8:57 PM, [email protected] wrote: *****IMPORTANT***** Updated 2025/12/15 RFC Author(s): Your document has now entered AUTH48. The document was edited in kramdown-rfc as part of the RPC pilot test (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc). Please review the procedures for AUTH48 using kramdown-rfc: https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_instructions_completing_auth48_using_kramdown Once your document has completed AUTH48, it will be published as an RFC. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9846.md https://www.rfc-editor.org/authors/rfc9846.html https://www.rfc-editor.org/authors/rfc9846.pdf https://www.rfc-editor.org/authors/rfc9846.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9846-diff.html https://www.rfc-editor.org/authors/rfc9846-rfcdiff.html (side by side) Diff of the kramdown: https://www.rfc-editor.org/authors/rfc9846-md-diff.html https://www.rfc-editor.org/authors/rfc9846-md-rfcdiff.html (side by side) Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9846 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC 9846 (draft-ietf-tls-rfc8446bis-14) Title : The Transport Layer Security (TLS) Protocol Version 1.3 Author(s) : E. Rescorla 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]
