Hi Amanda, The updates look great, thank you.
All best, Kaelin Foody RFC Production Center > On Jun 30, 2026, at 8:34 PM, Amanda Baber via RT <[email protected]> wrote: > > Hi, > > These missing updates are now complete: > > https://www.iana.org/assignments/tls-parameters > > thanks/apologies, > Amanda > > On Tue Jun 30 15:28:36 2026, [email protected] wrote: >> Hi IANA, >> >> Please make the following changes in the “TLS Cipher Suites” registry >> at <https://www.iana.org/assignments/tls-parameters/tls- >> parameters.xhtml#tls-parameters-4>. >> >> Please set the “Recommended” column to “D” and add this document as a >> reference for the four entries below. (These entries appear in the >> tables in Sections 5.1 and 5.2 of <https://auth48-transition.rfc- >> editor.org/authors/rfc10015-diff.html> but were not updated.) >> >> TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA >> TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA >> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA >> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA >> >> Thanks, >> >> Kaelin Foody >> RFC Production Center >> >>> On Jun 24, 2026, at 11:50 AM, Paul Wouters >>> <[email protected]> wrote: >>> >>> ah, >>> >>> You right, since the document has these, a note to TLS is not needed. >>> >>> I find the table at https://github.com/rfc-editor-drafts/FinalReview- >>> rfc10015/blob/RPC-edits/rfc10015.md#updates-to-rfc-9325-update-9325 >>> to be clear, I would prefer it over https://auth48-transition.rfc- >>> editor.org/authors/rfc10015-TEST.html#name-updates-to-rfc-9325 >>> Paul >>> >>> On Tue, Jun 23, 2026 at 6:20 PM Rebecca VanRheenen >>> <[email protected]> wrote: >>> 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]
