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]
