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.

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.