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]
