Hi Paul, Thanks for the input!
a) We will not make any changes to the term “premaster”. Nimrod (author) agrees with your assessment of this. We closed issue #15 (https://github.com/rfc-editor-drafts/FinalReview-rfc10015/issues/15). b) Regarding: > 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. To clarify, are you referring to the following, which are mentioned in Issue #13 (https://github.com/rfc-editor-drafts/FinalReview-rfc10015/issues/13)? 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 If so, note that these do appear in the tables in Section 5.1 and 5.2 in the document, but it looks like perhaps IANA didn’t update the registry for them. I see similar ones that did get updated (e.g., TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256), but it seems these slipped through the cracks. I can email IANA prior to publication to request these updates (i.e., set to “D” and add this document as a reference). Based on this, is a note to the TLS WG needed? Or are you referring to something else? c) Do you have any thoughts on issue #11 (https://github.com/rfc-editor-drafts/FinalReview-rfc10015/issues/11)? Thank you, Rebecca VanRheenen RFC Production Center > On Jun 23, 2026, at 6:26 AM, 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]
