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

I have no objection to the publication of this document as an RFC. Many thanks to Valery Smyslov for the ARTART review.

Thanks to Dan Harkins for their secdir review.

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 ?

Thanks for preparing a new I-D that addresses my concerns.

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/

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.

Thanks to Menachem Dodge for the OPSDIR review.

I also support the DISCUSS positions put forth by Gorry Fairhurst and Mohamed Boucadair.

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/

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/

Thank you to Mallory Knodel for the GENART.

I support the DISCUSS positions of Gorry Fairhurst and Mohamed Boucadair.

Thanks to Valery Smyslov for the ARTART review.