[TLS] Mohamed Boucadair's No Objection on draft-ietf-tls-deprecate-obsolete-kex-07: (with COMMENT)

Mohamed Boucadair via Datatracker <noreply@ietf.org> Fri, 14 November 2025 14:47 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Mohamed Boucadair via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <176313162428.105009.2963929103372038038@dt-datatracker-5bd94c585b-wk4l4>
Date: Fri, 14 Nov 2025 06:47:04 -0800
Message-ID-Hash: NPNADVHVXBNW42RWI6XQKPQGXBHNKETI
CC: draft-ietf-tls-deprecate-obsolete-kex@ietf.org, tls-chairs@ietf.org, tls@ietf.org
Reply-To: Mohamed Boucadair <mohamed.boucadair@orange.com>
Subject: [TLS] Mohamed Boucadair's No Objection on draft-ietf-tls-deprecate-obsolete-kex-07: (with COMMENT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/62K4AfISpgLMUDa1J2lvem5PsGQ>

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] Mohamed Boucadair's No Objection on draft-i… Mohamed Boucadair via Datatracker