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]
