[TLS] Re: [New-wg-docs] I-D Action: draft-ietf-tls-ecdhe-mlkem-00.txt

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 27 March 2025 12:33 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 59CFC1324B44 for <tls@mail2.ietf.org>; Thu, 27 Mar 2025 05:33:53 -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 1zPsyhWaxVov for <tls@mail2.ietf.org>; Thu, 27 Mar 2025 05:33:52 -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 B40131324B3C for <tls@ietf.org>; Thu, 27 Mar 2025 05:33:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dukhovni.org; i=@dukhovni.org; q=dns/txt; s=f8320d6e; t=1743078829; h=date : from : to : subject : message-id : reply-to : references : mime-version : content-type : in-reply-to : from; bh=Uh3gRTcHmf39JCavHEP3pZmPCgDn3p09PZ9KQ9wpHSo=; b=D9sY9ALvm/iX2LLUfk3jhubDjo260Dt7uDde7RduMfhvsyo8b5j0ywao0fv2vs5aiyBKf LyJts66TmOx2D8cZE6JdCxIUyOk2UfbvgjQNYqLsrFxNie9SLM4ylWXBIxR+eVpbj1lyjOp Ihbjhe02WC5VGJDVp0Ucj7w5UfT3Cvo=
Received: by chardros.imrryr.org (Postfix, from userid 1000) id 9F84986950B; Thu, 27 Mar 2025 23:33:49 +1100 (AEDT)
Date: Thu, 27 Mar 2025 23:33:49 +1100
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <Z-VFrZaKoyU-CRiN@chardros.imrryr.org>
References: <040b446d9acd4aa5a5ebf3af1b931a05@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <040b446d9acd4aa5a5ebf3af1b931a05@huawei.com>
Mail-Followup-To: <tls@ietf.org>
Message-ID-Hash: B7MB43BC2KASPV2YWKXDKFNBGGMMW6BZ
X-Message-ID-Hash: B7MB43BC2KASPV2YWKXDKFNBGGMMW6BZ
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: [New-wg-docs] I-D Action: draft-ietf-tls-ecdhe-mlkem-00.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/FRjQbs2t7APDz4MoO6GcnSlu5E4>
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 Thu, Mar 27, 2025 at 10:10:49AM +0000, Sun Shuzhou wrote:

> I have read this draft and have two questions.
> 
> 1. X25519MLKEM768 is the concatenation of ML-KEM and X25519.  Why
> SecP256r1MLKEM768/SecP384r1MLKEM1024 use a different order? ML-KEM
> part comes after the EC share.

Inconsequential historical detail.  The names are now in the IANA
registry and already supported in multiple deployed systems, so
not worth fixing.  FWIW, the historical motivation is tangentially
related to the point in time validation status of various FIPS
algorithms, but this is no longer relevant.

> 2. In Section 3.1.3. Server share:
> 
> When the SecP256r1MLKEM768 group is negotiated, ... The size of the
> server share is 1153 bytes (1088 bytes for the ML-KEM part and 65
> bytes for secp256r1).
> 
> When the SecP384r1MLKEM1024 group is negotiated, ... The size of the
> server share is 1665 bytes (1568 bytes for the ML-KEM part and 97
> bytes for secp384r1)

Noting the sizes in an order that is different from the wire order is
not IMHO a significant issue, given explicit language defining the wire
order elsewhere, ... though of course switching the order of exposition,
just in case someone might somehow miss the definitive text, would be fine.

-- 
    Viktor.