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]
