Oh, I noticed I missed responding to some questions about replacing references. One of these is right and the others are wrong. See.
https://github.com/tlswg/tls13-spec/issues/1430 -Ekr On Mon, May 18, 2026 at 8:21 AM Eric Rescorla <[email protected]> wrote: > I went through the [rfced] questions and comments. Here is a copy of the > markdown with > most removed as no action required and a few responses. I think the only > indicated change > is updating the SSL2 reference. If you want to update this, I can merge > in the other > (AD/chair approved) auth48 changes and provide a return copy. > > -Ekr > > > > > On Mon, May 11, 2026 at 11:42 AM Sandy Ginoza < > [email protected]> wrote: > >> Hi Eric, >> >> Thanks for the ping, and my apologies for the delay! We have removed the >> use of aasvg and the question below from the set of open questions in the >> markdown file. Please let us know if any changes are needed. >> >> >> <!--[rfced] The SVG in Figures 1 and 4 are outputting a solid circle >> 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. >> --> >> >> The current files are available here: >> https://www.rfc-editor.org/authors/rfc9846.txt >> https://www.rfc-editor.org/authors/rfc9846.pdf >> https://www.rfc-editor.org/authors/rfc9846.html >> https://www.rfc-editor.org/authors/rfc9846.md >> >> Thanks, >> Sandy Ginoza >> RFC Production Center >> >> >> >> On May 11, 2026, at 6:54 AM, Eric Rescorla <[email protected]> wrote: >> >> Ping? >> >> On Tue, May 5, 2026 at 3:33 PM Eric Rescorla <[email protected]> wrote: >> There are other updates being worked on. However, in reviewing it I found >> the following >> glitch. Consider the following diagram in the ASCII art: >> >> <image.png> >> >> In your rendered HTML it is:<image.png> >> >> Note how the * in the second bullet below turns into a large bullet. >> This is >> not correct. This is an AASVG glitch [0], but I don't think the answer is >> to change the input as MT's PR suggests but rather to fix the toolchain, >> or alternately, to render this in ASCII art as was done in 8446. >> >> Note that this is also a glitch: >> >> <image.png> >> >> >> -Ekr >> >> [0] https://github.com/tlswg/tls13-spec/pull/1406 >> >> On Fri, Apr 24, 2026 at 10:11 AM Sandy Ginoza < >> [email protected]> wrote: >> Hi Eric, >> >> We’re checking to see if there is any movement with RFC-to-be 9846. It >> looks like there was consensus to "prohibit key share reuse between >> connections” and a PR was merged (April 9). Are all of the relevant >> updates in <https://github.com/tlswg/tls13-spec/pull/1410/changes> or >> are there other updates being discussed? >> >> 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]
