Hi, These missing updates are now complete:
https://www.iana.org/assignments/tls-parameters thanks/apologies, Amanda On Tue Jun 30 15:28:36 2026, [email protected] wrote: > Hi IANA, > > Please make the following changes in the “TLS Cipher Suites” registry > at <https://www.iana.org/assignments/tls-parameters/tls- > parameters.xhtml#tls-parameters-4>. > > Please set the “Recommended” column to “D” and add this document as a > reference for the four entries below. (These entries appear in the > tables in Sections 5.1 and 5.2 of <https://auth48-transition.rfc- > editor.org/authors/rfc10015-diff.html> but were not updated.) > > TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA > TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA > > Thanks, > > Kaelin Foody > RFC Production Center > > > On Jun 24, 2026, at 11:50 AM, Paul Wouters > > <[email protected]> wrote: > > > > ah, > > > > You right, since the document has these, a note to TLS is not needed. > > > > I find the table at https://github.com/rfc-editor-drafts/FinalReview- > > rfc10015/blob/RPC-edits/rfc10015.md#updates-to-rfc-9325-update-9325 > > to be clear, I would prefer it over https://auth48-transition.rfc- > > editor.org/authors/rfc10015-TEST.html#name-updates-to-rfc-9325 > > Paul > > > > On Tue, Jun 23, 2026 at 6:20 PM Rebecca VanRheenen > > <[email protected]> wrote: > > Hi Nimrod, > > > > We sent you an invite; once you accept, you should be able to open > > pull requests if needed. > > > > Thanks for reviewing the issues and for your comments. I’ve updated > > the RPC-edits PR accordingly. We now have two open issues — I have > > requested input from Paul Wouters on these. > > > > Thanks! > > > > Rebecca VanRheenen > > RFC Production Center > > > > > > > > > On Jun 23, 2026, at 7:57 AM, Nimrod Aviram > > > <[email protected]> wrote: > > > > > > Hi! :-) > > > > > > a. My github username is: > > > nimia > > > > > > c. I spotted a few minor issues and left comments, other than those > > > - LGTM. > > > > > > I reviewed the issues, most of which LGTM, and left comments. > > > > > > thanks, > > > Nimrod > > > > > > > > > On Tue, 23 Jun 2026 at 16:26, Paul Wouters <[email protected]> > > > wrote: > > > I believe all corrections and suggestions are correct, with the > > > exception of the "Inclusive Language" suggestion for the term > > > "premaster" term to be changed to something else. I believe it is > > > an unfortunate legacy term we need to keep for that reference (but > > > has been replaced in TLS 1.3 already) > > > > > > The Q12 CAMELLIA ones, I think should be added to the Recommended D > > > change set, as it is using the same KEX methods we are obsoleting > > > in this document. Perhaps that technically requires a quick note to > > > the TLS WG to formally confirm, but I'm sure no one would mind. > > > > > > Paul > > > > > > On Tue, Jun 23, 2026 at 6:29 AM Deb Cooley <[email protected]> > > > wrote: > > > I'm adding Paul Wouters to this chain. He was AD at the time this > > > draft entered the queue. > > > > > > Deb > > > > > > On Mon, Jun 22, 2026 at 8:10 PM <[email protected]> wrote: > > > Authors, > > > > > > While reviewing this document during Final Review, please resolve > > > (as necessary) > > > the following questions, which are also in GitHub issues > > > (see https://github.com/rfc-editor-drafts/FinalReview- > > > rfc10015/issues). > > > > > > > > > 1) <!-- [rfced] Please note that we updated "(D)TLS 1.2" in the > > > title of the document as follows. We retained "(D)TLS 1.2" in the > > > rest of the document. > > > > > > Original: > > > Deprecating Obsolete Key Exchange Methods in (D)TLS 1.2 > > > > > > Updated: > > > Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2 > > > > > > We also updated the abbreviated title as follows to more closely > > > align with the document title. Note that the abbreviated title > > > appears in the running header at the top of each page in the PDF > > > output. > > > > > > Original: > > > Deprecating RSA and FFDH(E) > > > > > > Updated: > > > Deprecating Obsolete Key Exchanges in (D)TLS 1.2 > > > --> > > > > > > > > > 2) <!-- [rfced] Please review the following questions and changes > > > regarding the > > > references in this document: > > > > > > a) [ICA] The URL for this reference entry appears to be broken: > > > > > > https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.704.7932&rep=rep1&type=pdf > > > > > > We found the following URL which appears to match the information > > > for this reference. May we update to use this URL? > > > https://link.springer.com/content/pdf/10.1007/978-3-319-24174- > > > 6_21.pdf. > > > > > > Current: > > > [ICA] Jager, T., Schwenk, J., and J. Somorovsky, "Practical > > > invalid curve attacks on TLS-ECDH", 21 September 2015, > > > <https://citeseerx.ist.psu.edu/viewdoc/ > > > download?doi=10.1.1.704.7932&rep=rep1&type=pdf>.] > > > > > > Perhaps: > > > [ICA] Jager, T., Schwenk, J., and J. Somorovsky, "Practical > > > invalid curve attacks on TLS-ECDH", SORICS 2015, Part I, > > > Lecture Notes in Computer Science, vol. 9326, pp. 407- > > > 425, > > > DOI 10.1007/978-3-319-24174-6_21, 21 September 2015, > > > <https://link.springer.com/content/ > > > pdf/10.1007/978-3-319-24174-6_21.pdf>. > > > > > > b) We have reformatted some of the reference entries to match the > > > information provided at the URLs for those entries. Please review > > > and let us > > > know if you have any objections. > > > > > > c) We have also added URLs to the following references and > > > formatted their > > > entries accordingly. Please review and let us know any objections. > > > > > > [BLEI] > > > [ROBOT] > > > [XPROT] > > > --> > > > > > > > > > 3) <!-- [rfced] Normative reference [I-D.ietf-tls-rfc8446bis] is > > > currently in Final Review as RFC 9846. We updated [I-D.ietf-tls- > > > rfc8446bis] to [PRE-RFC9846] for now. We will make the final > > > updates in RFCXML (i.e., remove "PRE-" in "PRE-RFC9846" and"PRE- > > > 9846"). This document will be published at the same time as or > > > after RFC 9846. > > > --> > > > > > > > > > 4) <!-- [rfced] Abstract: The abstract should be self-contained, so > > > we have removed the "i.e." phrase that contains section pointers. > > > > > > Original: > > > This document updates RFCs 9325, 4346, 5246, 4162, 6347, 5932, > > > 5288, > > > 6209, 6367, 8422, 5289, 5469, 4785, 4279, 5487, 6655, and 7905, > > > to > > > deprecate or discourage - i.e., change to MUST NOT or SHOULD > > > NOT, as > > > listed in Section 5.3, Section 5.2, Section 5.3, Section 5.4, > > > and > > > Section 5.5 - the use of cipher suites using the above key > > > exchange > > > methods in (D)TLS 1.2 connections. > > > > > > Current (removed parenthetical): > > > This document updates RFCs 4162, 4279, 4346, 4785, 5246, 5288, > > > 5289, > > > 5469, 5487, 5932, 6209, 6347, 6367, 6655, 7905, 8422, and 9325 > > > to > > > either deprecate or discourage the use of cipher suites using > > > the > > > above key exchange methods in (D)TLS 1.2 connections. > > > --> > > > > > > > > > 5) <!-- [rfced] We updated the RFCs listed in the "Updates:" field > > > in the first-page header to appear in ascending order (per Section > > > 4.1.4 of RFC 7322). We also updated the following text to remove > > > the duplicate "Section 5.3" and to list the RFCs in ascending > > > order. Please review and let us know any concerns. > > > > > > Original: > > > Updates: 9325, 4346, 5246, 4162, > > > 6347, 5932, > > > 5288, 6209, 6367, 8422, > > > 5289, 5469, > > > 4785, 4279, 5487, 6655, > > > 7905 (if > > > approved) > > > ... > > > This document updates RFCs 9325, 4346, 5246, 4162, 6347, 5932, > > > 5288, > > > 6209, 6367, 8422, 5289, 5469, 4785, 4279, 5487, 6655, and 7905, > > > to > > > deprecate or discourage - i.e., change to MUST NOT or SHOULD > > > NOT, as > > > listed in Section 5.3, Section 5.2, Section 5.3, Section 5.4, > > > and > > > Section 5.5 - the use of cipher suites using the above key > > > exchange > > > methods in (D)TLS 1.2 connections. > > > ... > > > This document updates [RFC9325], [RFC4346], [RFC5246], > > > [RFC4162], > > > [RFC6347], [RFC5932], [RFC5288], [RFC6209], [RFC6367], > > > [RFC8422], > > > [RFC5289], [RFC4785], [RFC4279], [RFC5487], [RFC6655], [RFC7905] > > > and > > > [RFC5469] to remediate the above problems, by deprecating and > > > discouraging the use of affected cipher suites, as listed in > > > Section 5.3 Section 5.2 Section 5.3 Section 5.4 Section 5.5. > > > > > > Current: > > > Updates: 4162, 4279, 4346, 4785, > > > 5246, 5288, > > > 5289, 5469, 5487, 5932, > > > 6209, 6347, > > > 6367, 6655, 7905, 8422, 9325 > > > ... > > > This document updates RFCs 4162, 4279, 4346, 4785, 5246, 5288, > > > 5289, > > > 5469, 5487, 5932, 6209, 6347, 6367, 6655, 7905, 8422, and 9325 > > > to > > > either deprecate or discourage the use of cipher suites > > > using the above key exchange methods in (D)TLS 1.2 connections. > > > ... > > > This document updates [RFC4162], [RFC4279], [RFC4346], > > > [RFC4785], > > > [RFC5246], [RFC5288], [RFC5289], [RFC5469], [RFC5487], > > > [RFC5932], > > > [RFC6209], [RFC6347], [RFC6367], [RFC6655], [RFC7905], > > > [RFC8422], and > > > [RFC9325] to remediate the above problems, by deprecating and > > > discouraging the use of affected cipher suites, as listed in > > > Sections > > > 5.2, 5.3, 5.4, and 5.5. > > > --> > > > > > > > > > 6) <!-- [rfced] Will readers know what "D" in the "Recommended" > > > column means? Would adding a short explanation of "D" be helpful? > > > > > > The following sentence currently appears in Section 7 (IANA > > > Considerations), but "D" is first mentioned in Section 5: > > > > > > Current (IANA Considerations): > > > For information about > > > the use of "D" in the "Recommended" column, see [RFC9847]. > > > > > > Perhaps similar text could be placed at the beginning of Section 5 > > > as shown below. Let us know your thoughts. > > > > > > Perhaps: > > > 5. Updates to Cipher Suites and TLS ClientCertificateType > > > Identifiers > > > > > > The following subsections mention the use of "D" in the > > > "Recommended" > > > column of the "TLS Cipher Suites" and "TLS ClientCertificateType > > > Identifiers" registries [TLS-REGISTRY]. See [RFC9847] for > > > information > > > on the use of the "D". > > > --> > > > > > > > > > 7) <!-- [rfced] Please insert any keywords (beyond those that > > > appear in > > > the title) for use on https://www.rfc-editor.org/search. > > > --> > > > > > > > > > 8) <!-- [rfced] Should "are already marked" be updated to "were > > > previously marked"? > > > > > > Original: > > > Note that these cipher suites > > > are already marked as not recommended in the "TLS Cipher Suites" > > > registry [tls-registry]. > > > > > > Perhaps: > > > Note that these cipher suites were previously > > > marked as not recommended in the "TLS Cipher Suites" registry > > > [TLS-REGISTRY]. > > > --> > > > > > > > > > 9) <!-- [rfced] Would adding a section pointer be helpful in the > > > second sentence below to indicate where the document "records the > > > rationale" and "cites prior analyses"?" If so, is "Section 7" > > > correct? > > > > > > Original: > > > This document updates them to "Recommended: D" to > > > align with [I-D.ietf-tls-rfc8447bis]. It also records the > > > rationale > > > for discouraging use of these cipher suites, and cites prior > > > analyses > > > and attacks that demonstrate the associated risks. > > > > > > Perhaps: > > > This document updates them to have "D" in the "Recommended" > > > column to > > > align with [RFC9847]. This document also records the rationale > > > for discouraging use of these cipher suites, and it cites prior > > > analyses > > > and attacks that demonstrate the associated risks (see Section > > > 7). > > > --> > > > > > > > > > 10) <!-- [rfced] Table 6 in Section 6 > > > > > > To apply the updates in Table 6 while looking at https://www.rfc- > > > editor.org/rfc/rfc9325.html#section-4.1, the reader may have > > > difficulty determining exactly what text is being updated/added. > > > For clarity, we suggest replacing Table 6 with OLD/NEW text. > > > > > > We created the following test file to illustrate the use of OLD/NEW > > > text in Section 6 (but please review closely for accuracy if you > > > choose to go with this as we are not certain we captured the > > > intent): > > > > > > https://www.rfc-editor.org/authors/rfc10015-TEST.html#name-updates- > > > to-rfc-9325 > > > https://www.rfc-editor.org/authors/rfc10015-TEST.txt > > > --> > > > > > > > > > 11) <!-- [rfced] We have updated the text in the IANA > > > Considerations section as follows. Let us know any objections. > > > > > > Original: > > > This document requests IANA to mark the cipher suites from the > > > "TLS > > > Cipher Suites" registry [tls-registry], under "Transport La<yer > > > Security (TLS) Parameters" registry group, listed in Section > > > 5.1, > > > Section 5.2, Section 5.3, Section 5.4, and the certificate types > > > from > > > the "TLS ClientCertificateType Identifiers" registry listed in > > > Section 5.5 as "D" in the "Recommended" column, see > > > [I-D.ietf-tls-rfc8447bis]. > > > > > > For each registry entry in Section 5.1, Section 5.2, Section 5.3, > > > Section 5.4, and Section 5.5, IANA is also requested to update the > > > registry entry's Reference column to refer to this document. > > > > > > Updated: > > > The "TLS Cipher Suites" and "TLS ClientCertificateType > > > Identifiers" > > > registries both appear within the "Transport Layer Security > > > (TLS) > > > Parameters" registry group [TLS-REGISTRY]. IANA has updated > > > entries > > > in the "TLS Cipher Suites" registry [TLS-REGISTRY] as indicated > > > in > > > Sections 5.1, 5.2, 5.3, and 5.4. IANA has also updated entries > > > in > > > the "TLS ClientCertificateType Identifiers" registry as > > > indicated in > > > Section 5.5. > > > > > > For each entry listed in Sections 5.1, 5.2, 5.3, 5.4, and 5.5, IANA > > > has set the "Recommended" column to "D" and updated the entry's > > > Reference column to refer to this document. For information about > > > the use of "D" in the "Recommended" column, see [RFC9847]. > > > --> > > > > > > > > > 12) <!-- [rfced] Mismatch between document and IANA registries > > > > > > a) We note that the following values are listed in the document > > > (first two in Section 5.1 and last two in Section 5.2): > > > > > > TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA > > > TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA > > > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA > > > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA > > > > > > However, in the "TLS Cipher Suites" registry (see > > > https://www.iana.org/assignments/tls-parameters/tls- > > > parameters.xhtml#tls-parameters-4), the entries for these do not > > > have the "Recommended" column set to "D" and do not include this > > > document as a reference. Should the entries in the registry be > > > updated? If so, we will request that IANA update the registry prior > > > to publication. > > > > > > > > > b) We also see discrepancies in the references for the following > > > entries in the tables in Sections 5.1, 5.3, and 5.4 when compared > > > to the references listed in the "TLS Cipher Suites" registry. > > > Should the references listed in the document be updated to match > > > the "TLS Cipher Suites" registry? > > > > > > TLS_DH_DSS_WITH_DES_CBC_SHA > > > Document: [RFC5469] > > > IANA registry: [RFC8996] > > > > > > TLS_DH_RSA_WITH_DES_CBC_SHA > > > Document: [RFC5469] > > > IANA registry: [RFC8996] > > > > > > TLS_DH_anon_WITH_DES_CBC_SHA > > > Document: [RFC5469] > > > IANA registry: [RFC8996] > > > > > > TLS_DHE_DSS_WITH_DES_CBC_SHA > > > Document: [RFC5469] [RFC8996] > > > IANA registry: [RFC8996] > > > > > > TLS_DHE_RSA_WITH_DES_CBC_SHA > > > Document: [RFC5469] [RFC8996] > > > IANA registry: [RFC8996] > > > > > > TLS_RSA_WITH_DES_CBC_SHA > > > Document: [RFC5469] [RFC8996] > > > IANA registry: [RFC8996] > > > > > > TLS_RSA_WITH_IDEA_CBC_SHA > > > Document: [RFC5469] [RFC8996] > > > IANA registry: [RFC8996] > > > > > > > > > c) We see a similar discrepancies with references for the entries > > > in the table in Section 5.5 when compared to the "TLS > > > ClientCertificateType Identifiers" registry" > > > (https://www.iana.org/assignments/tls-parameters/tls- > > > parameters.xhtml#tls-parameters-2). It seems that "[RFC9847]" has > > > been added in the registry but not in the document. Should the > > > references listed in the document be updated to match the "TLS > > > Cipher Suites" registry? > > > > > > rsa_fixed_dh (3) > > > Document: [RFC5246] > > > IANA registry: [RFC5246][RFC9847] > > > > > > dss_fixed_dh (4) > > > Document: [RFC5246] > > > IANA registry: [RFC5246][RFC9847] > > > > > > rsa_fixed_ecdh (65) > > > Document: [RFC8422] > > > IANA registry: [RFC8422][RFC9847] > > > > > > ecdsa_fixed_ecdh (66) > > > Document: [RFC8422] > > > IANA registry: [RFC8422][RFC9847] > > > --> > > > > > > > > > 13) <!-- [rfced] We see both "cipher suite" (open) and > > > "ciphersuite" (closed) used in the document. We updated to the use > > > the open form (except in a couple of reference entries) as that is > > > most common in the document. Let us know any concerns. > > > --> > > > > > > > > > 14) <!-- [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 "premaster" should be updated > > > in the text below: > > > > > > Original: > > > However, Raccoon revealed that timing side channels in processing > > > TLS > > > premaster secrets may be exploited to reveal the encrypted > > > premaster > > > secret. > > > --> > > > > > > Thank you. > > > > > > Kaelin Foody and Rebecca VanRheenen > > > RFC Production Center > > > > > > > > > > > > On Jun 22, 2026, at 5:07 PM, [email protected] wrote: > > > > > > *****IMPORTANT***** > > > > > > RFC Author(s): > > > -------------- > > > > > > Your document has now entered Final Review (previously 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). > > > > > > Final Review is being handled in GitHub as part of the GitHub pilot > > > test > > > (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github- > > > phase-0-pilot-test). > > > > > > Your document is available for review at: > > > https://github.com/rfc-editor-drafts/FinalReview-rfc10015 > > > > > > Please do the following: > > > > > > a) provide your GitHub username so that we can send you an invite > > > to join the repo > > > as a collaborator. At minimum, we need a GitHub username for Nimrod > > > Aviram (author). > > > We can also send invites to Joseph Salowey (document shepherd), > > > Deirdre Connolly > > > (WG chair), and Sean Turner (WG chair). We have already sent one to > > > Deb Cooley (AD). > > > > > > b) see the README for details on the Final Review process: > > > https://github.com/rfc-editor-drafts/FinalReview- > > > rfc10015/blob/Approved/README.md > > > > > > c) review the edits in the RPC-edits pull request: > > > https://github.com/rfc-editor-drafts/FinalReview-rfc10015/pulls > > > > > > d) address the issues: > > > https://github.com/rfc-editor-drafts/FinalReview-rfc10015/issues > > > > > > Once the content of the .md file is stable, we will convert it to > > > .xml > > > and provide the .html, .pdf, .txt, and .xml files for review. > > > > > > You and your coauthors are responsible for engaging other parties > > > (e.g., Contributors or Working Group) as necessary before providing > > > your approval. > > > > > > Once the document has been reviewed and approved by all of the > > > authors, > > > it will be published as an RFC. If an author is no longer > > > available, > > > there are several remedies; see the Unavailable Authors section > > > (https://authors.ietf.org/rfc-publication-process#unavailable- > > > authors). > > > > > > Details on the status of your Final Review are here: > > > https://queue.rfc-editor.org/final-review/rfc10015/ > > > > > > Please let us know if you have any questions. > > > > > > Thank you for your cooperation, > > > > > > RFC Production Center > > > > > > -------------------------------------- > > > RFC 10015 (draft-ietf-tls-deprecate-obsolete-kex) > > > > > > Title : Deprecating Obsolete Key Exchange Methods in > > > (D)TLS 1.2 > > > Author(s) : N. Aviram > > > WG Chair(s) : Joseph Salowey, Sean Turner, Deirdre Connolly > > > Area Director(s) : Deb Cooley, Christopher Inacio > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
