IETF Logo Mail Archive

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

"D. J. Bernstein" <djb@cr.yp.to> Mon, 10 March 2025 11:15 UTC

Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
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 EFD519889CE for <tls@mail2.ietf.org>; Mon, 10 Mar 2025 04:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 DLnXxAoX-WLN for <tls@mail2.ietf.org>; Mon, 10 Mar 2025 04:15:17 -0700 (PDT)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by mail2.ietf.org (Postfix) with SMTP id 379789889C9 for <tls@ietf.org>; Mon, 10 Mar 2025 04:15:16 -0700 (PDT)
Received: (qmail 7211 invoked by uid 1010); 10 Mar 2025 11:15:16 -0000
Received: from unknown (unknown) by unknown with QMTP; 10 Mar 2025 11:15:16 -0000
Received: (qmail 370602 invoked by uid 1000); 10 Mar 2025 11:15:07 -0000
Date: Mon, 10 Mar 2025 11:15:07 -0000
Message-ID: <20250310111507.370600.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: tls@ietf.org
Mail-Followup-To: tls@ietf.org
In-Reply-To: <Z842c12hY9LNOd8J@chardros.imrryr.org>
Message-ID-Hash: JHEV3NIAOKBIRX37TAFESVAGZBJAGQNX
X-Message-ID-Hash: JHEV3NIAOKBIRX37TAFESVAGZBJAGQNX
X-MailFrom: djb-dsn2-1406711340.7506@cr.yp.to
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
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/qI7Sxx3eXWVIKkylBKd5NFV0CWY>
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>

Viktor Dukhovni writes:
> I'd expect such designs to be quite unlikely

That's different from "not possible". :-)

I agree with your API comments: one can't build this by simply calling
the FIPS 203 standard keygen-enc-dec functions for ML-KEM. However, if
that were the end of the story then we wouldn't see things like

    https://csrc.nist.gov/csrc/media/Presentations/2024/how-multi-recipient-kems-help-deploy-pqc/images-media/prest-how-multi-recipient-kems-pqc2024.pdf

or some people saying that they're storing ML-KEM private keys as seeds.
It also wouldn't be surprising to see reuse of what I labeled as G (even
when A is changing), which in turn would increase the speed incentives
to reuse b. Again, I'm not saying any of this is safe.

---D. J. Bernstein

v2.29.0 | Report a Bug | By Email | System Status