Deprecating Obsolete Key Exchange Methods in (D)TLS 1.2
draft-ietf-tls-deprecate-obsolete-kex-08

[Ballot comment]
Hi Nimrud,

Thank you for the new version -07. The new version is a real enhancement compared to the previous version I reviewed [1].

I'm afraid the following points are still applicable from my previous ballot [2]:

# Why are we repeating recommendations that are already in RFC9325?

CURRENT:
  Clients SHOULD NOT offer and servers SHOULD NOT select non-ephemeral
  ECDH cipher suites in (D)TLS 1.2 connections.

# Overlapping/interference with 9325

CURRENT:
  Therefore, clients and
  servers MAY offer FFDHE cipher suites in (D)TLS 1.3 connections.

To what extent is this redundant with the considerations already in RFC9325?

More importantly, the risk I see with isolating this recommendation is that we decouple it from other recommendations that impose some constraints on their use: 

(Section 7.4 of RFC9325)
  *  TLS implementations SHOULD NOT use static finite-field DH keys and
      SHOULD NOT reuse ephemeral finite-field DH keys across multiple
      connections.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-deprecate-obsolete-kex-07

[2] https://mailarchive.ietf.org/arch/msg/tls/zuBej7aWFjQuSHSKeIlr8FS-6N8/

[Ballot comment]
Thanks for the work done in this document, even if, like Gorry, I am little puzzled by the form of this RFC (notably because there is no per-RFC specific update sections). As draft-ietf-tls-rfc8447bis will soon be published, wouldn't it be easier to just update the IANA registries ? I.e., perhaps not updating RFCs ?

[Ballot comment]
Thanks for the work put into this document for updating the recommendations for (D)TLS 1.2.

I support the DISCUSS positions from Gorry and Med.

While the IANA registries would provide the recommendations for implementers, I am not sure if it does provide the proper view for (D)TLS 1.2. My concern is whether this document is easy to consume for the target audience. However, I am not a SEC expert and not conversant with the way these recommendations are being maintained.

[Ballot discuss]
Thank you for making this document and the detailed research that likely underpins this proposed update to many RFCs. I am very supportive of this work, however, as this proceeds I have some things that I’d like to see clarified.  I would have just passed comments to the editors, but I am not entirely sure how a reader of this document is to now interpret the set of published RFCs I think readers (who may have even less experience than me) ought to clearly understand what has changed.

## DISCUSS 1: I am unsure what is actually required to be updated in the list of RFCs in para 1. I see sentences like: “This includes all cipher suites listed in the table in Appendix A.” My question is what does “includes” mean here?  Could this be as simple as a statement something like: “This  updates the set of RFCs listed in this document in XXX to deprecate the use of non-ephemeral FFDH cipher suites in (D)TLS 1.2 connections.” Or is there more needed?

## DISCUSS 2: If there is a change to clarify the update would it be possible to make a similar change for all other statements in paras 2,3, and sections 3 and 4. (See Med’s DISCUSS of how this can reflected in some of the specific IANA registries).

## DISCUSS 3: I  see this updates a BCP, RFC9325, but I am unsure in what way this is formally updated. I see the text: “ [RFC9325] contains the latest IETF recommendations for users of the (D)TLS protocol (and specifically, (D)TLS 1.2) and this document supersedes it in several points.” - I was expecting text in a section of the document that specifically stated what sections/text was to be changed in that document, but I could not work that out for certain, and hence this list of points is not clear. Can these changes to RFC9325 be made explicit in this specific I-D?

I have raised these as DISCUSS items, because I could not clearly understand the intention of the requested changes to the published RFCs. I expect this to be very easy to resolve some way, but would like to understand how. I plan to clear my discuss with support for this document.

Best, Gorry.

[Ballot comment]
I see the lists of RFCs to be updated have been placed in appendices. I would have expected these to appear in subsections within the body of the published RFC - reasoning that this is not supplementary material, but is the core contribution.  However, if that style is acceptable for this WG, then that would of course be fine for me also. My comment is that I would strongly encourage that each appendix add a sentence or a change to the title that explains that is the normative list of RFCs to be changed.

[Ballot discuss]
Hi Nimrod,

Thank you for the effort put into this document.

Thanks to Menachem for the OPSDIR review.

Maybe I wasn’t looking at the right places, but it is unfortunate the absence of follow-ups with directorate reviews (part of IETF LC).

I’m supportive of the maintenance effort made here. However, I think a discussion on known (or lack of) uses of the schemes (if any) and associated operational implications is worth to be documented.

# Update a BCP

CURRENT:
  [RFC9325] contains the latest IETF recommendations for users of the
  (D)TLS protocol (and specifically, (D)TLS 1.2) and this document
  supersedes it in several points.  Appendix F details the exact
  differences.  All other recommendations of the BCP document remain
  valid.

…


        +============================+=============+============+
        |                            | RFC 9325    |    RFC XXX |
        +============================+=============+============+
        | Non-ephemeral FFDH        | SHOULD NOT  |  MUST NOT |
        +----------------------------+-------------+------------+
        | Non-ephemeral ECDH        | SHOULD NOT  |  No change |
        +----------------------------+-------------+------------+
        | Fixed DH certificate types | Unspecified | SHOULD NOT |
        +----------------------------+-------------+------------+
        | Ephemeral FFDH            | SHOULD NOT  |  MUST NOT |
        +----------------------------+-------------+------------+
        | Static RSA                | SHOULD NOT  |  MUST NOT |
        +----------------------------+-------------+------------+

## Is this document the right place to update a BCP?

## Rather than approaching this with the items discussed in this specific document, wouldn’t be sustainable to make a short update to RFC9325 that basically says: "Any scheme that is marked as Deprecated in the authoritative registry MUST NOT be offered/used"?

## Why are we listing ECDH in a table that is supposed to list changes?

## Why are we repeating recommendations that are already in RFC9325?

CURRENT:
  Clients SHOULD NOT offer and servers SHOULD NOT select non-ephemeral
  ECDH cipher suites in (D)TLS 1.2 connections.

## Overlapping/interference with 9325

CURRENT:
  Therefore, clients and
  servers MAY offer FFDHE cipher suites in (D)TLS 1.3 connections.

To what extent is this redundant with the considerations already in RFC9325?

More importantly, the risk I see with isolating this recommendation is that we decouple it from other recommendations that impose some constraints on their use: 

(Section 7.4 of RFC9325)
  *  TLS implementations SHOULD NOT use static finite-field DH keys and
      SHOULD NOT reuse ephemeral finite-field DH keys across multiple
      connections.

[Ballot comment]
# Lack of Operational Considerations

Valery (artart review) raised a valid point that I’m grabbing from his review:

  “1. Perhaps some text should be added about potential interoperability problems
  (or, as we hope, the lack of such) caused by deprecation of the mentioned key
  exchnage methods. If this could be backed up by some figures from real word, it
  would be great.”

# RFC9325, Again

* “[RFC9325] contains the latest IETF recommendations” won’t age well. However, “[BCP195] contains the latest IETF recommendations” is likely to be valid independent of future revisions of RFC9325.)

* I don’t quite understand why normative changes are listed in an appendix: “Appendix F.  Updating RFC 9325”

# IANA Actions

## Please indicate where to find the registry

OLD:
  This document requests IANA to mark the cipher suites from the "TLS
  Cipher Suites" registry listed in Appendix A, Appendix B, Appendix C,

NEW:
  This document requests IANA to mark the cipher suites from the "TLS
  Cipher Suites" registry, under “Transport Layer Security (TLS) Parameters”
  registry group, listed in Appendix A, Appendix B, Appendix C,

## nit

s/ refer to the this document/refer to this document

# Appendix A.  DH Cipher Suites Deprecated by This Document

Can we use the format used in the IANA registry? Or at least, if we want to keep this consistent with the registry, can we please be explicit that we are asking for “recommended” to be set to “D” for these entries?

# Appendix B.  ECDH Cipher Suites Whose Use Is Discouraged by This Document

These are already marked as “N” in the registry. What concrete changes will be captured in the registry? Please clarify.

Cheers,
Med

[Ballot comment]
Thanks for this write-up. I only have two minor observations:

1) Some messages are seen when idnits are checked.
2) potentially add s/Diffie-Helman/Diffie-Hellman (DH)/ so it is clear at first instance that DH = Diffie-Hellman. I realize that a single further the abbreviation ECDH is used and maybe the WG finds that correlation good enough?

Thanks,
G/

[Ballot comment]
I don't see that this document explicitly states the updates made to RFCs 4346, 5246, 4162, 6347, 5932, 5288, 6209, 6367, 8422, 5289, 5469, 4785, 4279, 5487, 6655, and 7905 "to remediate the above problems." Presumably the cipher suites in question are removed from some list or requirements on acceptable cipher suites are amended; please state the changes explicitly.

===NITS FOLLOW===
- Section 5, s/registry/registry/

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-tls-deprecate-obsolete-kex-05. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are four actions which we must complete.

First, in the TLS Cipher Suites registry in the Transport Layer Security (TLS) Parameters registry group located at:

https://www.iana.org/assignments/tls-parameters/

the following list of cipher suites will have the value in the recommended column changed from the existing value to D:

TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_DSS_WITH_DES_CBC_SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_RSA_WITH_DES_CBC_SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_WITH_DES_CBC_SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA
TLS_DH_RSA_WITH_AES_128_CBC_SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA256
TLS_DH_RSA_WITH_AES_128_CBC_SHA256
TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA256
TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS_DH_anon_WITH_AES_128_CBC_SHA256
TLS_DH_anon_WITH_AES_256_CBC_SHA256
TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA
TLS_DH_DSS_WITH_SEED_CBC_SHA
TLS_DH_RSA_WITH_SEED_CBC_SHA
TLS_DH_anon_WITH_SEED_CBC_SHA
TLS_DH_RSA_WITH_AES_128_GCM_SHA256
TLS_DH_RSA_WITH_AES_256_GCM_SHA384
TLS_DH_DSS_WITH_AES_128_GCM_SHA256
TLS_DH_DSS_WITH_AES_256_GCM_SHA384
TLS_DH_anon_WITH_AES_128_GCM_SHA256
TLS_DH_anon_WITH_AES_256_GCM_SHA384
TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256
TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256
TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256
TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256
TLS_DH_DSS_WITH_ARIA_128_CBC_SHA256
TLS_DH_DSS_WITH_ARIA_256_CBC_SHA384
TLS_DH_RSA_WITH_ARIA_128_CBC_SHA256
TLS_DH_RSA_WITH_ARIA_256_CBC_SHA384
TLS_DH_anon_WITH_ARIA_128_CBC_SHA256
TLS_DH_anon_WITH_ARIA_256_CBC_SHA384
TLS_DH_RSA_WITH_ARIA_128_GCM_SHA256
TLS_DH_RSA_WITH_ARIA_256_GCM_SHA384
TLS_DH_DSS_WITH_ARIA_128_GCM_SHA256
TLS_DH_DSS_WITH_ARIA_256_GCM_SHA384
TLS_DH_anon_WITH_ARIA_128_GCM_SHA256
TLS_DH_anon_WITH_ARIA_256_GCM_SHA384
TLS_DH_RSA_WITH_CAMELLIA_128_GCM_SHA256
TLS_DH_RSA_WITH_CAMELLIA_256_GCM_SHA384
TLS_DH_DSS_WITH_CAMELLIA_128_GCM_SHA256
TLS_DH_DSS_WITH_CAMELLIA_256_GCM_SHA384
TLS_DH_anon_WITH_CAMELLIA_128_GCM_SHA256
TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384

For all of these changed registrations, [ RFC-to-be ] will be added in the Reference column.

Second, also in the TLS Cipher Suites registry in the Transport Layer Security (TLS) Parameters registry group located at:

https://www.iana.org/assignments/tls-parameters/

the following list of cipher suites will have the value in the recommended column changed from the existing value to D:

TLS_ECDH_ECDSA_WITH_NULL_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_NULL_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_anon_WITH_NULL_SHA
TLS_ECDH_anon_WITH_RC4_128_SHA
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_anon_WITH_AES_128_CBC_SHA
TLS_ECDH_anon_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_ARIA_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_ARIA_256_CBC_SHA384
TLS_ECDH_RSA_WITH_ARIA_128_CBC_SHA256
TLS_ECDH_RSA_WITH_ARIA_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_ARIA_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_ARIA_256_GCM_SHA384
TLS_ECDH_RSA_WITH_ARIA_128_GCM_SHA256
TLS_ECDH_RSA_WITH_ARIA_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384
TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256
TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_CAMELLIA_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_CAMELLIA_256_GCM_SHA384
TLS_ECDH_RSA_WITH_CAMELLIA_128_GCM_SHA256
TLS_ECDH_RSA_WITH_CAMELLIA_256_GCM_SHA384

Once again, for all of these changed registrations, [ RFC-to-be ] will be added in the Reference column.

Third, also in the TLS Cipher Suites registry in the Transport Layer Security (TLS) Parameters registry group located at:

https://www.iana.org/assignments/tls-parameters/

the following list of cipher suites will have the value in the recommended column changed from the existing value to D:

TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_PSK_WITH_NULL_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_PSK_WITH_RC4_128_SHA
TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA
TLS_DHE_PSK_WITH_AES_128_CBC_SHA
TLS_DHE_PSK_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_SEED_CBC_SHA
TLS_DHE_RSA_WITH_SEED_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_DHE_PSK_WITH_AES_128_GCM_SHA256
TLS_DHE_PSK_WITH_AES_256_GCM_SHA384
TLS_DHE_PSK_WITH_AES_128_CBC_SHA256
TLS_DHE_PSK_WITH_AES_256_CBC_SHA384
TLS_DHE_PSK_WITH_NULL_SHA256
TLS_DHE_PSK_WITH_NULL_SHA384
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256
TLS_DHE_DSS_WITH_ARIA_128_CBC_SHA256
TLS_DHE_DSS_WITH_ARIA_256_CBC_SHA384
TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256
TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384
TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256
TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384
TLS_DHE_DSS_WITH_ARIA_128_GCM_SHA256
TLS_DHE_DSS_WITH_ARIA_256_GCM_SHA384
TLS_DHE_PSK_WITH_ARIA_128_CBC_SHA256
TLS_DHE_PSK_WITH_ARIA_256_CBC_SHA384
TLS_DHE_PSK_WITH_ARIA_128_GCM_SHA256
TLS_DHE_PSK_WITH_ARIA_256_GCM_SHA384
TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256
TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384
TLS_DHE_DSS_WITH_CAMELLIA_128_GCM_SHA256
TLS_DHE_DSS_WITH_CAMELLIA_256_GCM_SHA384
TLS_DHE_PSK_WITH_CAMELLIA_128_GCM_SHA256
TLS_DHE_PSK_WITH_CAMELLIA_256_GCM_SHA384
TLS_DHE_PSK_WITH_CAMELLIA_128_CBC_SHA256
TLS_DHE_PSK_WITH_CAMELLIA_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_128_CCM
TLS_DHE_RSA_WITH_AES_256_CCM
TLS_DHE_RSA_WITH_AES_128_CCM_8
TLS_DHE_RSA_WITH_AES_256_CCM_8
TLS_DHE_PSK_WITH_AES_128_CCM
TLS_DHE_PSK_WITH_AES_256_CCM
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256
TLS_PSK_DHE_WITH_AES_128_CCM_8
TLS_PSK_DHE_WITH_AES_256_CCM_8

Once again, for all of these changed registrations, [ RFC-to-be ] will be added in the Reference column.

Fourth, also in the TLS Cipher Suites registry in the Transport Layer Security (TLS) Parameters registry group located at:

https://www.iana.org/assignments/tls-parameters/

the following list of cipher suites will have the value in the recommended column changed from the existing value to D:

TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_WITH_IDEA_CBC_SHA
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_PSK_WITH_NULL_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_PSK_WITH_RC4_128_SHA
TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA
TLS_RSA_PSK_WITH_AES_128_CBC_SHA
TLS_RSA_PSK_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_SEED_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_PSK_WITH_AES_128_GCM_SHA256
TLS_RSA_PSK_WITH_AES_256_GCM_SHA384
TLS_RSA_PSK_WITH_AES_128_CBC_SHA256
TLS_RSA_PSK_WITH_AES_256_CBC_SHA384
TLS_RSA_PSK_WITH_NULL_SHA256
TLS_RSA_PSK_WITH_NULL_SHA384
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256
TLS_RSA_WITH_ARIA_128_CBC_SHA256
TLS_RSA_WITH_ARIA_256_CBC_SHA384
TLS_RSA_WITH_ARIA_128_GCM_SHA256
TLS_RSA_WITH_ARIA_256_GCM_SHA384
TLS_RSA_PSK_WITH_ARIA_128_CBC_SHA256
TLS_RSA_PSK_WITH_ARIA_256_CBC_SHA384
TLS_RSA_PSK_WITH_ARIA_128_GCM_SHA256
TLS_RSA_PSK_WITH_ARIA_256_GCM_SHA384
TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256
TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384
TLS_RSA_PSK_WITH_CAMELLIA_128_GCM_SHA256
TLS_RSA_PSK_WITH_CAMELLIA_256_GCM_SHA384
TLS_RSA_PSK_WITH_CAMELLIA_128_CBC_SHA256
TLS_RSA_PSK_WITH_CAMELLIA_256_CBC_SHA384
TLS_RSA_WITH_AES_128_CCM
TLS_RSA_WITH_AES_256_CCM
TLS_RSA_WITH_AES_128_CCM_8
TLS_RSA_WITH_AES_256_CCM_8
TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256

Once again, for all of these changed registrations, [ RFC-to-be ] will be added in the Reference column.

Fifth, there is not yet a "Recommended" column for the registry at TLS ClientCertificateType Identifiers in the Transport Layer Security (TLS) Parameters registry group located at:

https://www.iana.org/assignments/tls-parameters/

The reason for this is that draft-ietf-tls-rfc8447bis-12 is awaiting IESG action. When that draft is approved and the TLS ClientCertificateType Identifiers registry is modified, this [ RFC-to-be ] will act on following list of ClientCertificateTypes and will have the value in the recommended column changed from the existing value to D:

rsa_fixed_dh (3)
dss_fixed_dh (4)
rsa_fixed_ecdh (65)
ecdsa_fixed_ecdh (66)

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-04-28):

From: The IESG
To: IETF-Announce
CC: draft-ietf-tls-deprecate-obsolete-kex@ietf.org, joe@salowey.net, paul.wouters@aiven.io, tls-chairs@ietf.org, tls@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Deprecating Obsolete Key Exchange Methods in TLS 1.2) to Proposed Standard


The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Deprecating Obsolete Key Exchange Methods
in TLS 1.2'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-04-28. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document deprecates the use of RSA key exchange and Diffie
  Hellman over a finite field in TLS 1.2, and discourages the use of
  static elliptic curve Diffie Hellman cipher suites.

  Note that these prescriptions apply only to TLS 1.2 since TLS 1.0 and
  1.1 are deprecated by RFC 8996 and TLS 1.3 either does not use the
  affected algorithm or does not share the relevant configuration
  options.

  This document updates RFCs 9325, 4346, 5246, 4162, 6347, 5932, 5288,
  6209, 6367, 8422, 5289, 5469, 4785, 4279, 5487, 6655, and 7905.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc6209: Addition of the ARIA Cipher Suites to Transport Layer Security (TLS) (Informational - Internet Engineering Task Force (IETF) stream)
    rfc6367: Addition of the Camellia Cipher Suites to Transport Layer Security (TLS) (Informational - Internet Engineering Task Force (IETF) stream)

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is broad WG consensus to support moving this document forward.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

The general topic of deprecation is somewhat controversial, however the working group reached consensus to move forward with deprecation.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Some vendors and service providers have already removed some of these algorithms from the default set
of configured algorithms or removed support for them. 

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

NA

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

NA

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document Shepherd believes the document is ready

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Document has been review against criteria.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards track because the document deprecates code points that require standards action. 
Datatracker state is updated.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

To my knowledge and the authors knowledge no disclosures are needed.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

I-D nits have been reviewed. The tool erroneously indicates missing updates header and a line too long.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

References to the technology being deprecated are listed as normative.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

"Addition of the ARIA Cipher Suites to Transport Layer Security (TLS)", RFC 6209
"Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)", RFC 6367

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

There is a dependency on RFC 8447 which is ready for WGLC in the TLS working group

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document updates several RFS that are listed in the abstract, title page and introduction.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA registries that need to be modified are clearly indicated.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

NA.  No New registries.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is broad WG consensus to support moving this document forward.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

The general topic of deprecation is somewhat controversial, however the working group reached consensus to move forward with deprecation.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Some vendors and service providers have already removed some of these algorithms from the default set
of configured algorithms or removed support for them. 

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

NA

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

NA

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document Shepherd believes the document is ready

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Document has been review against criteria.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards track because the document deprecates code points that require standards action. 
Datatracker state is updated.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

To my knowledge and the authors knowledge no disclosures are needed.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

I-D nits have been reviewed. The tool erroneously indicates missing updates header and a line too long.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

References to the technology being deprecated are listed as normative.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

"Addition of the ARIA Cipher Suites to Transport Layer Security (TLS)", RFC 6209
"Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)", RFC 6367

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

There is a dependency on RFC 8447 which is ready for WGLC in the TLS working group

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document updates several RFS that are listed in the abstract, title page and introduction.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA registries that need to be modified are clearly indicated.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

NA.  No New registries.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is broad WG consensus to support moving this document forward.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

The general topic of deprecation is somewhat controversial,

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Some vendors and service providers have already removed some of these algorithms from the default set
of configured algorithms or removed support for them. 

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

NA

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

NA

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document Shepherd believes the document is ready

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Document has been review against criteria.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards track because the document deprecates code points that require standards action. 
Datatracker state is updated.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

To my knowledge all disclosures have been filed.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

References to the technology being deprecated are listed as normative.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

"Addition of the ARIA Cipher Suites to Transport Layer Security (TLS)", RFC 6209
"Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)", RFC 6367

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

There is a dependency on RFC 8447 which is ready for WGLC in the TLS working group

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.



20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).



21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

NA

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/