IETF Logo Mail Archive

[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448

Loganaden Velvindron <loganaden@gmail.com> Tue, 07 January 2025 14:12 UTC

Return-Path: <loganaden@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE57AC14F694 for <tls@ietfa.amsl.com>; Tue, 7 Jan 2025 06:12:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KvbLifLKMnB for <tls@ietfa.amsl.com>; Tue, 7 Jan 2025 06:12:51 -0800 (PST)
Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46644C14F5EF for <tls@ietf.org>; Tue, 7 Jan 2025 06:12:51 -0800 (PST)
Received: by mail-ot1-x32e.google.com with SMTP id 46e09a7af769-71e1158fe3eso9409799a34.1 for <tls@ietf.org>; Tue, 07 Jan 2025 06:12:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736259170; x=1736863970; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=TMtXDvbb3G+653WvjIx+jtoqFUm/Y9C87F2VHrLxWXQ=; b=WfWnfTt07EPSuEzT0cN81jGJnFcqIhmHWtlks5awIF+bSJpoz6Pn4uUsBUno/5ExYv YVTQX2mx3QK39wGCdXoa90EC2xga2KxkIGFpVQ1y4jhs8cBcXU6eO/8VBuuVen7Vt+PJ kRaltMS033wUQ6koDhMLigqyOBdfSUQ8/SQ3gqjro0Mj7wJNKT8Ysz9c7g/5syR8jGVG Rh4WwgcG9cECUg11gWaMZwYiAbxTT2e4VFEJqDJPx+yzauwuwo8Ed/4T96/m73SgeLbb E5S8AfFClj0MBKMQ5IkjEYd0aTbyrso2za29kBFHF6SY6dLsVsPIlbW1FWo22DZu9SKw QjwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736259170; x=1736863970; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TMtXDvbb3G+653WvjIx+jtoqFUm/Y9C87F2VHrLxWXQ=; b=uH7nye7WDeD7bnDaXMLGpJpdXpmtvNB21GIrIFSRIM4OTGN4c2yuyoyLYXv96t3NO1 kKQ5R/v1qY5A+T2ZpnxCwgHnHxehpABw8iUuCNZjV08DWqGKQQ9TXbTxyZXpkE30ZuxA gnodH/okcTgCEcIQCtT4tc3wgjz6vBE3U732BDYzqEWQqhjaXpr32HyzOZl4sITRWP4Z jpVBqPu8JrdKv4sLo2MSNqIGuvvMzNCX/kad2BtijPZnOzAoZ38R2ENU1KYqr6vhH9Xn Po2B6BLe5w1l9MtLBAWdXx3CBKhpWGjNhcafACIVC82csWS5givQOl52i8Rq/tseEDEm t9iA==
X-Forwarded-Encrypted: i=1; AJvYcCVAHrhtRqqeGpEiHV66k7eiXdpFm5MqdNDkEapYC4HikT5yKP0tog/51QEemFb1asJgSnI=@ietf.org
X-Gm-Message-State: AOJu0Ywcma6nq1FngCPonKDj+XtkXzV3sXHRMMZuKNX1pJZ5HHP60kaf MHaGIx032KBbuZCohfoFAL4/NNr5mxDsgoyOxlF3QFqN5tUlGtAOKUIXGD28mPJbUxJsh26t4I/ u9a15JAMJ3bFFfcwBRORNV8EzV2s=
X-Gm-Gg: ASbGncurROvEPYymI1C+4V05h1DPUDaHvNUHMMcn3oQYUt+2Jt8OS0/E+Op4yRb8hYR 7upLMKDnoWMkocQH6pqFG/FaR8ZCfOOcGKG3sRg==
X-Google-Smtp-Source: AGHT+IFx+aXGPQntedpz0bCbWaioZoLP2ufc06/Nf79BswzOvaqYvGgzbh+9ui+u06R42Ygnqmfh+yx1n2cFe4BTsuE=
X-Received: by 2002:a05:6830:6506:b0:71e:171c:ddb9 with SMTP id 46e09a7af769-720ff692334mr41578667a34.2.1736259170478; Tue, 07 Jan 2025 06:12:50 -0800 (PST)
MIME-Version: 1.0
References: <CAOp4FwQE_xnYEL2i4srzmefXS_2CWY-TvbstiZZ5tUguoJ=q4Q@mail.gmail.com> <Z3t1u_stW0tEw9fV@chardros.imrryr.org> <ae0ea712-a49a-48c2-9d0f-f3ee2288457b@amongbytes.com> <Z3uZH9bKuugXVm8m@chardros.imrryr.org> <CAOp4FwR4CG-ieL=4SUOq5EZAfDHVG_f9O3g84_p1sDg_R63bmQ@mail.gmail.com> <9df071cf-aeb0-45df-b1b5-0560d148f571@redhat.com> <GVXPR07MB9678AB14211CFDEE5B76D4FD89112@GVXPR07MB9678.eurprd07.prod.outlook.com> <0cb16fd4-5234-450b-90d1-8afffee3cc01@app.fastmail.com>
In-Reply-To: <0cb16fd4-5234-450b-90d1-8afffee3cc01@app.fastmail.com>
From: Loganaden Velvindron <loganaden@gmail.com>
Date: Tue, 07 Jan 2025 18:12:38 +0400
Message-ID: <CAOp4FwQyHj3ApLfdHceDLe6ABB3y4QL4ntudmrQLQGD9OnMELw@mail.gmail.com>
To: Filippo Valsorda <filippo@ml.filippo.io>
Content-Type: text/plain; charset="UTF-8"
Message-ID-Hash: O2RDJWQMQIMRNVQAUHZR5UEOCNNJWFEE
X-Message-ID-Hash: O2RDJWQMQIMRNVQAUHZR5UEOCNNJWFEE
X-MailFrom: loganaden@gmail.com
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
CC: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, "tls@ietf.org" <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448
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/_jTcuIlXQmL8fGrKiz-9tB46Pzo>
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 Tue, 7 Jan 2025 at 17:35, Filippo Valsorda <filippo@ml.filippo.io> wrote:
>
> 2025-01-07 14:16 GMT+01:00 John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>:
>
> Alicja Kario wrote:
> >Can you point to examples of people actually using x448 (TLS group ID 30) in practice?
>
>
>
> I think that is the wrong question.
>
>
> If no one deployed X448 I don't see why they would deploy X448MLKEM1024, so I see no reason to standardize it.
>
> The reason to deploy SecP384r1MLKEM1024 is compliance. Like it or hate it.
>
> The obvious set of hybrids to standardize and implement is:
>
> the one everyone should use;
> one that everyone who can't use (1) can use.
>
> I personally liked SecP256r1MLKEM768 for (1) because I need to carry an optimized P-256 implementation for WebPKI certificates anyway, but X25519MLKEM768 is fine, too.
>
> SecP384r1MLKEM1024 fits the bill for (2) while X448MLKEM1024 does not, both for compliance transition reasons, and for "many libraries don't offer a X448 implementation" reasons.

There are a list of hybrids here:
https://www.ibm.com/docs/en/datapower-gateway/10.6.x?topic=commands-kem-alg-technology-preview

One of them is X448mlkem768.
Anybody from IBM can comment ?

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