Mohamed Boucadair has entered the following ballot position for draft-ietf-tls-deprecate-obsolete-kex-07: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/ ---------------------------------------------------------------------- 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/ _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
