[TLS] Re: FW: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt

Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 09 March 2025 13:39 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 7A3DE9565B3 for <tls@mail2.ietf.org>; Sun, 9 Mar 2025 06:39:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Level:
X-Spam-Status: No, score=-4.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=dukhovni.org
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWCkXT8liyvT for <tls@mail2.ietf.org>; Sun, 9 Mar 2025 06:39:16 -0700 (PDT)
Received: from chardros.imrryr.org (chardros.imrryr.org [144.6.86.210]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 2C78E95659F for <tls@ietf.org>; Sun, 9 Mar 2025 06:39:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dukhovni.org; i=@dukhovni.org; q=dns/txt; s=f8320d6e; t=1741527554; h=date : from : to : subject : message-id : reply-to : references : mime-version : content-type : in-reply-to : from; bh=pilUv6EBxL24bE6i0/PpHOMprelokuINwpl8SjSdVeo=; b=jUjKBFgTgY+2Ks7nrdsAtyAC6ez1r54IVEm9vHhIxqyyXUb/5/j4Tn6eEgs+dSOeZVyCX rNAMe2kURCzqhdKFM5p/AF9rp3VlKbX/ZnkdbJjlWtkNdTe6dqj8xVZPbP0EWW7EP6pQyzG 1LT0FAElLWaiVCZFZ/624uAleBFCJKg=
Received: by chardros.imrryr.org (Postfix, from userid 1000) id 1745093558C; Mon, 10 Mar 2025 00:39:14 +1100 (AEDT)
Date: Mon, 10 Mar 2025 00:39:14 +1100
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <Z82aAuvLY1tiDxbQ@chardros.imrryr.org>
References: <GVXPR07MB9678E29CF1D00E59164EB89089D72@GVXPR07MB9678.eurprd07.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <GVXPR07MB9678E29CF1D00E59164EB89089D72@GVXPR07MB9678.eurprd07.prod.outlook.com>
Mail-Followup-To: <tls@ietf.org>
Message-ID-Hash: OZHKLH5EI6QT5ABLOLHRKG625LCE5RDS
X-Message-ID-Hash: OZHKLH5EI6QT5ABLOLHRKG625LCE5RDS
X-MailFrom: ietf-dane@dukhovni.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Reply-To: tls@ietf.org
Subject: [TLS] Re: FW: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/zX1NrZT0jcrd_HaP9h2l--zIReg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

On Sun, Mar 09, 2025 at 12:33:38PM +0000, John Mattsson wrote:

> I find the current situation of key shares being reused without the
> other peer knowing inacceptable and frankly the worst possible option.

In general terms, your expectations are unrealistic, the best you can
do, if you think you're in a position to influence remote server
behaviour, rather than just take an ineffective principled stand, is
detect a duplicate keyshare from a previous connection and abort.

However, you'll be thrilled to learn that it is not possible for a TLS
server to reuse its ML-KEM keyshare when a client uses a fresh ephemeral
ML-KEM keyshare.  TLS servers don't have ML-KEM keys, they just perform
encapsulation against the client's public key, so there's nothing for
the server to reuse (KEMs aren't (EC)DH key exchange).

So while the X25519 portion of the server's key could be reused, the
ML-KEM portion will not be.

-- 
    Viktor.