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]
