[TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM Post-Q uantum Key Agreement for TLS 1.3

S Moonesamy <sm+ietf@elandsys.com> Sat, 19 April 2025 05:49 UTC

Return-Path: <sm@elandsys.com>
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 2372C1E61AA3 for <tls@mail2.ietf.org>; Fri, 18 Apr 2025 22:49:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com
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 MKPzYKKbyhlL for <tls@mail2.ietf.org>; Fri, 18 Apr 2025 22:49:16 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by mail2.ietf.org (Postfix) with ESMTP id 34A721E61AA0 for <tls@ietf.org>; Fri, 18 Apr 2025 22:49:16 -0700 (PDT)
Received: from DESKTOP-K6V9C2L.elandsys.com ([197.225.105.252]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 53J5mghC025285 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Apr 2025 22:49:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=elandsys.com; s=mail; t=1745041753; x=1745128153; i=@elandsys.com; bh=cp5b/jN92UEM/quUPtX7XdOIB75IAn2/HsBF/dMXpi8=; h=Date:To:From:Subject:In-Reply-To:References; b=u0U0wBfeeGeGdXXkV2totlmH68RNYax/8aaKrgzr6E2aLchM3YdTzXNw73AN8iYdF x1xNP+3ox8v8ibFB5tikmD7n5Wh3jJNI71XMgq0bSiAXQA9g0KYCS70MCVL+e8ZuQu pw8aMn7a+EWriZsx77CiOsk70N4bwowVQ/r2Ya9E=
Message-Id: <6.2.5.6.2.20250418211210.0c152140@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 18 Apr 2025 22:45:31 -0700
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>, tls@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <BN0P110MB1419E8DB9B38B33F41A6234590BCA@BN0P110MB1419.NAMP1 10.PROD.OUTLOOK.COM>
References: <5dd1e81a-c37a-ceff-b89e-b4335fca07b6@nohats.ca> <56e646395f67e27ff11a092d5989c1c85eba2563.camel@aisec.fraunhofer.de> <CAOp4FwSJpvn6f=3utd4yBE=ftkXQ4h38FT3VQ1XOhrubqgu0ng@mail.gmail.com> <BN0P110MB1419E8DB9B38B33F41A6234590BCA@BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: D4IQGULPXAOSRXD5XB5YXL5QHO2H2VN4
X-Message-ID-Hash: D4IQGULPXAOSRXD5XB5YXL5QHO2H2VN4
X-MailFrom: sm@elandsys.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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM Post-Q uantum Key Agreement for TLS 1.3
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/mfSHT90jg-8cvVPUoZnJQt6Pui4>
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>

Hi Uri,
At 10:23 AM 17-04-2025, Blumenthal, Uri - 0553 - MITLL wrote:
>You consider pure-PQ risks – then don't usee it. 
>I consider risks associated with hybrids, so my 
>deployment will not use them. To each his own.

According to a draft authored by Reddy and 
Tschofenig, "Pure PQC Key Exchange may be 
required for specific deployments with regulatory 
or compliance mandates".  The authors then go on 
to list "high-security environments" as an 
example of where Pure PQC Key Exchange is 
required.   An assessment of risks would be different in such environments.

The web browser vendors decide which algorithm(s) 
to deploy at my location.  That's usually how it 
works for everyday use.  I doubt that the 
everyday user would be asking for compliance with 
the (U.S.) FIPS 203 standard (please see Section 
1.1 of 
draft-connolly-tls-mlkem-key-agreement-05);  It's 
unlikely that the user would have heard of 
"FIPS".  It could be different in other parts of the world.

>Don't try to stuff your perception of risks and 
>correctness into everybody else's throat.

The above sentence seems a bit strong.

Regards,
S. Moonesamy