Hi Nick, Rich, Yoav (cc: rfc8446bis AUTH48 list), As the designated experts for TLS ExtensionType Values, can you approve these registry changes? I understand that we need two approvals for this registry.
From the RFC Editor's message below: > 5) IANA - please note the following additions to the IANA > Considerations section and let us know when the updates are complete. > > See section 11.1 <https://auth48-transition.rfc- > editor.org/authors/rfc9846.html#section-11.1>: > > - IANA has added references to this document for the status_request > and > supported_groups entries in the "TLS ExtensionType Values" registry. > > - IANA has updated the TLS ExtensionType value in the "TLS 1.3" column > for cached_info to "CH, EE”. You can see the registry here: https://www.iana.org/assignments/tls-extensiontype-values/ See below for links to the updated document. thanks, Amanda On Fri Jun 26 05:31:26 2026, [email protected] wrote: > Hi Eric, Deb* (as AD), IANA, > > Thanks for sending the markdown file along. We have updated it a bit > so that we could get output files. We have a few questions below. > > IANA, please see item 5 below. > > *Deb, please review and confirm that these updates are acceptable. We > recommend reviewing the following diffs: > > Diffs highlighting the most recent updates only: > https://www.rfc-editor.org/authors/rfc9846-lastdiff.html > https://www.rfc-editor.org/authors/rfc9846-lastrfcdiff.html (side by > side) > > The current files are available as follows: > https://www.rfc-editor.org/authors/rfc9846.md > https://www.rfc-editor.org/authors/rfc9846.txt > https://www.rfc-editor.org/authors/rfc9846.pdf > https://www.rfc-editor.org/authors/rfc9846.html > > AUTH48 diffs: > https://www.rfc-editor.org/authors/rfc9846-auth48diff.html > https://www.rfc-editor.org/authors/rfc9846-auth48rfcdiff.html (side > by side) > > Comprehensive diffs: > https://www.rfc-editor.org/authors/rfc9846-diff.html > https://www.rfc-editor.org/authors/rfc9846-rfcdiff.html (side by > side) > > > Eric, please review the items below. > > 1) We updated "The Transcript Hash” to be Section 4.1 — please confirm > that this is correct. > > Previously, Section 4 was nested as follows: > > 4. Handshake Protocol > 4.1. Key Exchange Messages > 4.1.1. Cryptographic Negotiation > 4.1.2. Client Hello > 4.1.3. Server Hello > 4.1.4. Hello Retry Request > … > 4.4. Authentication Messages > 4.4.1. The Transcript Hash > … > > In the updated file, kramdown-rfc complained about the nesting, which > appeared as follows: > # Handshake Protocol > ### The Transcript Hash > > > 2) Confirm "non-DHE key key establishment algorithms” is correct > (occurs 2x) > > > 3) Should this be “as 0-RTT data on connection 1”? > > … as an attacker may be able to cause the data to be > processed as 0-RTT data as connection 1 and as 1-RTT data on > connection 2. > > > 4) To get the outputs, we updated the references to RFC 9846 to be > included as “PRE-RFC9846” - it will be updated in the XML file prior > to publication. Would you be open to not including a self-reference > to RFC 9846, and including the references in the IANA tables as plain > text "[RFC9846]” instead - this would be normal handling to avoid > self-references. > > > 5) IANA - please note the following additions to the IANA > Considerations section and let us know when the updates are complete. > > See section 11.1 <https://auth48-transition.rfc- > editor.org/authors/rfc9846.html#section-11.1>: > > - IANA has added references to this document for the status_request > and > supported_groups entries in the "TLS ExtensionType Values" registry. > > - IANA has updated the TLS ExtensionType value in the "TLS 1.3" column > for cached_info to "CH, EE”. > > > Thanks, > Sandy Ginoza > RFC Production Center > > > > > On Jun 24, 2026, at 9:23 AM, Eric Rescorla <[email protected]> wrote: > > > > Thanks for your patience. > > > > I have merged the last set of proposed changes and the correct MD > > file can be found at: > > https://raw.githubusercontent.com/tlswg/tls13- > > spec/30a8dfda0148e1bd45d6196ee3a0ad9e23537167/rfc9846.md > > > > IMPORTANT: We updated a number of references to RFC 8446 to point to > > RFC 9846. I added a placeholder reference for RFC 9846 to the MD, but > > you'll need to fix this. > > > > -Ekr > > > > > > On Tue, May 19, 2026 at 9:22 AM Sandy Ginoza <[email protected] > > editor.org> wrote: > > Hi Eric, > > > > I haven’t found a way to force a line break in the markdown, but I > > can do it using zwsp in the XML so I’ll update once the file is > > converted. > > > > Thanks, > > Sandy Ginoza > > RFC Production Center > > > > > > > > > On May 18, 2026, at 3:26 PM, Eric Rescorla <[email protected]> wrote: > > > > > > In 8446 we just broke it after traffic_ > > > > > > | Post- | ClientHello ... client | > > > | client_application_traffic_ | > > > | Handshake | Finished + | secret_N > > > | | > > > | | CertificateRequest | > > > | | | > > > +-----------+------------------------- > > > +-----------------------------+ > > > > > > > > > On Mon, May 18, 2026 at 1:09 PM Sandy Ginoza <[email protected] > > > editor.org> wrote: > > > Hi Eric, > > > > > > Thanks for your explanations. The document has been updated, > > > including the updates related to <https://github.com/tlswg/tls13- > > > spec/issues/1430>. Please see the updated files here: > > > https://www.rfc-editor.org/authors/rfc9846.md > > > https://www.rfc-editor.org/authors/rfc9846.txt > > > https://www.rfc-editor.org/authors/rfc9846.pdf > > > https://www.rfc-editor.org/authors/rfc9846.html > > > > > > Diffs of the recent updates: > > > https://www.rfc-editor.org/authors/rfc9846-lastdiff.html > > > https://www.rfc-editor.org/authors/rfc9846-lastrfcdiff.html > > > > > > Comprehensive diffs: > > > https://www.rfc-editor.org/authors/rfc9846-diff.html > > > https://www.rfc-editor.org/authors/rfc9846-rfcdiff.html > > > > > > Is there any good way to break this table row? It appears to be 1 > > > character over the 69-character limit and we are unaware of any way > > > to outdent the table as a whole. > > > > > > +---------+-------------------- > > > +-------------------------------------+ > > > |Post- |ClientHello ... > > > |[sender]_application_traffic_secret_N| > > > |Handshake|client Finished + | > > > | > > > | |CertificateRequest | | > > > +---------+-------------------- > > > +-------------------------------------+ > > > > > > Thanks, > > > Sandy Ginoza > > > RFC Production Center > > > > > > > > > > > > > On May 18, 2026, at 10:14 AM, Eric Rescorla <[email protected]> wrote: > > > > > > > > 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] > > > > editor.org> 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 <rfc-editor@rfc- > > > >> > >>> editor.org> 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]
