[auth48] Re: AUTH48: RFC-to-be 9846 <draft-ietf-tls-rfc8446bis-14> for your review

[Sandy Ginoza <[e-mail]>]

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 <[e-mail]> wrote:
> 
> There isn't anything you can do at this time.
> 
> On Fri, Jan 30, 2026 at 2:32 PM Sandy Ginoza <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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, [e-mail] 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
> >>> 
> >>> 
> >>> 
> >> 
> > 
>