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]
