Done - thanks! Sandy Ginoza RFC Production Center
> On Mar 9, 2026, at 2:43 PM, Eric Rescorla <[email protected]> wrote: > > Yes, thank you > > On Mon, Mar 9, 2026 at 2:01 PM Sandy Ginoza <[email protected]> > wrote: > Hi Eric, > > In Section 4.2.8, may we update “KeyshareClienthello” (lowercase “h”) to > “KeyshareClientHello”? > > Thanks, > Sandy > > > > > > On Jan 30, 2026, at 2:33 PM, Eric Rescorla <[email protected]> wrote: > > > > There isn't anything you can do at this time. > > > > On Fri, Jan 30, 2026 at 2:32 PM Sandy Ginoza <[email protected]> > > wrote: > > Greetings, > > > > Please let us know how we can help advance this document to publication. > > > > Thanks, > > Sandy Ginoza > > RFC Production Center > > > > > > > > > On Jan 14, 2026, at 5:03 PM, Sandy Ginoza <[email protected]> > > > wrote: > > > > > > Hi Eric, > > > > > > This is a friendly reminder that we await your review. Please let us > > > know if there are any further issues that need to be addressed before you > > > continue with your review. > > > > > > Please note that we updated the date to reflect January 2026 but have > > > made no other changes since the update described below. > > > > > > Thanks, > > > Sandy Ginoza > > > RFC Production Center > > > > > > > > > > > >> On Dec 22, 2025, at 3:38 PM, Sandy Ginoza <[email protected]> > > >> wrote: > > >> > > >> Hi Eric, > > >> > > >> As requested, we have re-reviewed the updates to text that was untouched > > >> from RFC 8446. In keeping with that style, we reverted many of the > > >> updates that were introduced in the new text as well. Corrections > > >> remain in place. The entries for ACM Proceedings have also been > > >> reverted, but other updates remain. > > >> > > >> Please review the files and reply to the questions sent previously (they > > >> are still relevant). And, please provide the update "related to PKCS > > >> v1.5” that Paul mentioned. > > >> > > >> > > >> The current set of file are available here: > > >> https://www.rfc-editor.org/authors/rfc9846.md > > >> https://www.rfc-editor.org/authors/rfc9846.txt > > >> https://www.rfc-editor.org/authors/rfc9846.html > > >> https://www.rfc-editor.org/authors/rfc9846.pdf > > >> > > >> > > >> Comprehensive diffs: > > >> https://www.rfc-editor.org/authors/rfc9846-diff.html > > >> https://www.rfc-editor.org/authors/rfc9846-rfcdiff.html > > >> > > >> Markdown diffs: > > >> https://www.rfc-editor.org/authors/rfc9846-md-diff.html > > >> https://www.rfc-editor.org/authors/rfc9846-md-rfcdiff.html > > >> > > >> > > >> Thank you, > > >> Sandy Ginoza > > >> RFC Production Center > > >> > > >> > > >> > > >>> On Dec 16, 2025, at 5:16 PM, Eric Rescorla <[email protected]> wrote: > > >>> > > >>> Hi, > > >>> > > >>> I've taken an initial look at this version of the document and I see > > >>> that in a number > > >>> of cases references which were present in RFC 8446 have been changed. > > >>> For example: > > >>> > > >>> RFC8446: > > >>> > > >>> [Kraw16] Krawczyk, H., "A Unilateral-to-Mutual Authentication > > >>> Compiler for Key Exchange (with Applications to Client > > >>> Authentication in TLS 1.3", Proceedings of ACM CCS 2016, > > >>> October 2016, <https://eprint.iacr.org/2016/711>. > > >>> > > >>> RFC9846-to-be: > > >>> [Kraw10] Krawczyk, H., "Cryptographic Extraction and Key > > >>> Derivation: The HKDF Scheme", Cryptology ePrint Archive, > > >>> Paper 2010/264, 2010, <https://eprint.iacr.org/2010/264>. > > >>> > > >>> This is a regression. The situation here is that this paper was > > >>> published in > > >>> ACM CCS (a top 4 conference) but the proceedings aren't public, and so > > >>> the link is to ePrint, which is public. It's misleading to have the > > >>> citation > > >>> be to ePrint as if this wasn't peer reviewed published work. It's of > > >>> course > > >>> possible that this isn't exactly the paper that was presented at > > >>> CCS, but I think this is generally the right practice. There are quite > > >>> a few of these > > >>> and I think we should reverse them to match RFC 8446. > > >>> > > >>> In addition, some spot-checking finds other places where there are > > >>> minor edits in > > >>> this document to text which is otherwise unchanged from RFC 8446, > > >>> especially > > >>> around commas. I think there should be a fairly strong presumption that > > >>> the > > >>> text in 8446 is correct and shouldn't be changed unless there is a real > > >>> error, > > >>> as opposed to just that upon repeated copy-edit someone thinks it reads > > >>> better. > > >>> > > >>> Can the RPC please go through its proposed changes to identify variances > > >>> from RFC 8446 in text that is otherwise unchanged and reconsider whether > > >>> those changes are in fact necessary? > > >>> > > >>> Thanks, > > >>> -Ekr > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> On Tue, Dec 16, 2025 at 6:17 AM Paul Wouters <[email protected]> > > >>> wrote: > > >>> This document requires a small change applied to it related to PKCS > > >>> v1.5 Eric has the change for this. > > >>> > > >>> Paul > > >>> > > >>> > > >>> > > >>> On Tue, Dec 16, 2025 at 12:06 AM <[email protected]> wrote: > > >>> 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]
