IETF Logo Mail Archive

[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)

Dan Wing <danwing@gmail.com> Thu, 19 February 2026 23:51 UTC

Return-Path: <danwing@gmail.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 ADF91BA2979F for <tls@mail2.ietf.org>; Thu, 19 Feb 2026 15:51:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 syYlFJvbkF4Q for <tls@mail2.ietf.org>; Thu, 19 Feb 2026 15:51:33 -0800 (PST)
Received: from mail-dy1-x132b.google.com (mail-dy1-x132b.google.com [IPv6:2607:f8b0:4864:20::132b]) (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 mail2.ietf.org (Postfix) with ESMTPS id 17B63BA2979A for <tls@ietf.org>; Thu, 19 Feb 2026 15:51:33 -0800 (PST)
Received: by mail-dy1-x132b.google.com with SMTP id 5a478bee46e88-2ba6aa57d5fso1579783eec.1 for <tls@ietf.org>; Thu, 19 Feb 2026 15:51:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771545092; x=1772149892; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5SywJh1aHMLR0+LRwf81ICG/3r9JMatqYsX+EYOidNY=; b=hwziEemF+UEG7Mz4vkQMeKMJUooTjS1Gz2oSQBmIiyA2R5jvHMw7IuwjNw2ye/iWb9 laZSKoaa3oufD/8VzlTrMqxcen1BoE0cDnYOUgySWmbT9Hc2LaOt7MnAtKKXTHOG44bB j7VeTluEWiMREq15u8usvgR1924KHFrFItTaHh8qdKnpWZOPWytOQAM6QDXEh8YhGnNc A4iHx63yWiYlS8GePziTHqGLTXhWavv5qeO3clfXPd/34jDovi6OJuFS2DiNmmvUUxFQ TcN5kty9SsbPeWC9aIAsLzrAfa5KerPvqV2px34PX9umS3s2dLO/ytwxXv5Tb4cVkHwf fl9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771545092; x=1772149892; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=5SywJh1aHMLR0+LRwf81ICG/3r9JMatqYsX+EYOidNY=; b=IoZM0BV6mUJ25CWUyv++laRoTAOCnoGkf5lrcYHfr0a9Tazr2jURB7yG/wp+eHSkB2 zLnbGnQCMSuijc0Pht3qd6IWI6VnWU6u6LLZyXTRy6ED+yAM76CRbCU+aWDYbzh8tAGs 11xdZTcO3OVO+1mUVKIP90eVLR4E8hN9OmhfVLukEuipCQlOighARaJyFrCBNcgLmdW9 GQkx2NZkvmVCBdWZOzi9zXA9SpBFTgUALLpTNjcgFsGvbAv54tlKDUqJ/3odFzACIdph 8wc62zQMcM/9N/arXMaigzu0GbTUQI0x1Gl0dZWt4HqW/sbGBY1S6TDbES3UekAY10NO EkAA==
X-Forwarded-Encrypted: i=1; AJvYcCXm1k0U1wcFuTJpFpy60d9pHzQf2FO1r3P4ImhDc4TqB1VPRFLP86Emuk+NbkHia9SNZdg=@ietf.org
X-Gm-Message-State: AOJu0Yz4HMRqkRVCe2y8CccCMi8EwO66g5aW3brmuyHIglTrRoCKmmuN Uo1Z+l0Q+M1dERILXBx4vjE2zohJPsXiMkLTH+oB9W9zl3wuc11j9zQ8
X-Gm-Gg: AZuq6aKk8OgrEmIB4eL01oxiLQ2a57yDmjZEnKkd+2p6i0vAYfGIPbIDH3v3wGHS7X1 Y5OPN6Mgv9GDGOKPFMVP2F8RjArZy8DgSVn3tlfogI/wfDXrSHh4AHdnvsFMr+q8fn4xHK5edQ0 dxF3Br1lDqOV3LYFpOg1qJnJNXDP/mvdFbWxHXx4rZ3RUKFOvzo8no67xPjeFl51rFiTVsuj0fk j17N/bsdKJCxJ+/owC6vBRRl0yGsrbK7iDn8/smR5d2U2gSvLbGe40kr8AQ6p9vHiMeG+k3Ptzp gdo59J+r55f5FILsL1lUnqUfo3JYZXPoMiarGlMrVziUUDwuQpYP2m+X59UXjiIIV9CDJfq2OPw TX3luFU/1Qb0Okt1t78vHYwoR8bvQgSrb5T5AtP0LCY4JSWOwJgjOBI50V6rm7fVcsLU74bBVKU QeJfU4cwbvXdu8AZsO4puuvROTrSzc0ta+h//F8iARWQ==
X-Received: by 2002:a05:7300:a984:b0:2b8:6ad3:804e with SMTP id 5a478bee46e88-2bac97a0923mr9429639eec.22.1771545091816; Thu, 19 Feb 2026 15:51:31 -0800 (PST)
Received: from smtpclient.apple ([47.208.124.206]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2bacb658521sm21199314eec.16.2026.02.19.15.51.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Feb 2026 15:51:31 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
From: Dan Wing <danwing@gmail.com>
In-Reply-To: <CAFR824xEk-3RBd4TNvZOJg2OkfL4yoOs3Z7a7nsMoqXja740dA@mail.gmail.com>
Date: Thu, 19 Feb 2026 15:51:30 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <43D261A2-91B7-4D40-8FA0-8F2639C2993F@gmail.com>
References: <CAOgPGoDLVqAVesWjrrD9ZR8HMkqQVLMp69vOkXPkk87MzcsOSw@mail.gmail.com> <AS5PR07MB10596FC9D182E975AA0E11F8E8960A@AS5PR07MB10596.eurprd07.prod.outlook.com> <1050A0B9-9F8D-4762-BAF6-1BD290249F90@vigilsec.com> <CAFR824wWeM-0XYYc2XbLHBZFwCUZY4G-uoPTt6X0H23QgNcpUQ@mail.gmail.com> <DS0PR15MB5674C55563A2FA4A0ADE7FC2B360A@DS0PR15MB5674.namprd15.prod.outlook.com> <CAFR824xEk-3RBd4TNvZOJg2OkfL4yoOs3Z7a7nsMoqXja740dA@mail.gmail.com>
To: Deirdre Connolly <durumcrustulum@gmail.com>
X-Mailer: Apple Mail (2.3864.400.21)
Message-ID-Hash: QNEVSB364W2QYADGKUBYFQOVRL43GR7M
X-Message-ID-Hash: QNEVSB364W2QYADGKUBYFQOVRL43GR7M
X-MailFrom: danwing@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: Ben Schwartz <bemasc@meta.com>, "<tls@ietf.org>" <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)
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/vkyrSfR_zZDZNZsPsoIZ1Nwh4Z0>
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>

Thanks for the citations and text simplification.  

However, the citation to CNSSP15 fails -- it returns a 'not found' error (specifically, "CNSS.GOV ERROR MESSAGE We're sorry, but we're having trouble opening this document because we did not recognize your session variable. This may have been caused by: Using a bookmark to access a specific part of this site. Not all pages in this site can be bookmarked. [...]"), this from the main branch of the github repository for the I-D (https://github.com/tlswg/draft-ietf-tls-mlkem/tree/main)  Considering the cited URL is approximately two miles long, I suspect the problem is it's a bookmarked URL as that error page warns.

https://www.cnss.gov/CNSS/openDoc.cfm?a=kryrfZb9nS00l4L2shjYcQ%3D%3D&b=C944BD2E7ABAA37851D7A7EF71743C3ACE8393115D7588CD4423DD2B918812A86F060A05C2E0D4DEF8456CC75B2D39F4


The www.cnss.gov server is providing a US DoD-specific certificate after I dismiss the untrusted certificate warning (!) and it encourages:

  "ATTENTION - As of 24 February 2022, all users must install a DoD Root Certificate in their browser in order to access the CNSS website. 
Please select the following link for more information: DoD Root Certificate Help"


I attempted to find a citation and bumped into https://www.cnss.gov/CNSS/issuances/Policies.cfm which shows "CNSSP 15" (with a space, 10/20/2016) and "CNSSP-15" (with a dash, 03/04/2025).  It looks like the version with a dash is the intended citation.  I can't tell for sure.  But I could not find the strings admonishing/warning against hybrid schemes (I searched for 'hybrid' and 'curve' and 'pure' and 'sole' and 'only' and 'traditional').

-d

> On Feb 12, 2026, at 2:21 PM, Deirdre Connolly <durumcrustulum@gmail.com> wrote:
> 
> I've simplified the respective language there to 'requirements' on the GitHub:
> 
> https://github.com/tlswg/draft-ietf-tls-mlkem/commit/17e815cc847b231125b65c2523bc5535e4034c14
> 
> <image.png>
> 
> 
> On Thu, Feb 12, 2026 at 4:57 PM Ben Schwartz <bemasc@meta.com> wrote:
> Thanks for the updates!  Is ITSP.40.111 really a regulation?  Like CNSA 2.0, it seems to be an internal rulemaking within a government, rather than a regulation that binds the private sector generally.
> 
> --Ben
> From: Deirdre Connolly <durumcrustulum@gmail.com>
> Sent: Thursday, February 12, 2026 4:51 PM
> To: Russ Housley <housley@vigilsec.com>
> Cc: <tls@ietf.org> <tls@ietf.org>
> Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)   Thank you all for reading and replying. I have pushed some changes to the GitHub repo based on the discussions so far (not to datatracker yet): https: //github. com/tlswg/draft-ietf-tls-mlkem/compare/draft-ietf-tls-mlkem-05. . main (the tlswg. org
> Thank you all for reading and replying. I have pushed some changes to the GitHub repo based on the discussions so far (not to datatracker yet):
> 
> https://github.com/tlswg/draft-ietf-tls-mlkem/compare/draft-ietf-tls-mlkem-05..main
> 
> (the tlswg.org domain is messed up otherwise i would link the diff based on the Editor's draft)
> 
> On Thu, Feb 12, 2026 at 4:39 PM Russ Housley <housley@vigilsec.com> wrote:
> I support the publication of this document as an RFC.  I would prefer to have the clarity about ephemeral vs. static ML-KEM keys as posted by John Mattsson, but I can live with it as-is.
> 
> Russ
> 
> 
>> On Feb 12, 2026, at 3:08 PM, John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org> wrote:
>> 
>> Hi,
>> 
>> I support publication iff all text related to “key reuse” is removed. In its current form, I do not believe -07 should be published.
>> 
>> Major Comments:
>> 
>> - FIPS 203 states that:
>> 
>> “the licensed patents be freely available to be practiced by any implementer of the ML-KEM algorithm as published by NIST.”
>> 
>> “requirements for the secure use of KEMs in applications, see SP 800-227.”
>> 
>> A reused key is, by definition, a static key. SP 800-227 imposes additional requirements for static keys compared to ephemeral keys. The draft does not explain how an implementer can satisfy these requirements. This creates potential non-conformance with NIST specifications.
>> 
>> -  The draft does not describe the significant security and privacy problems associated with key reuse. IND-CCA is a theoretical property of the algorithm. However, the security and privacy problems are related to the reuse of keys in the TLS 1.3 protocol in deployments.
>> 
>> Minor Comments:
>> 
>> - The discussion of randomness reuse in ciphertexts and references to SP 800-227 do not belong in a “key reuse” section. Ciphertexts are not keys, and SP 800-227 contains broader guidelines and requirements beyond static keys.
>> 
>> - “The client's shares are listed in descending order of client preference; the server selects one algorithm and sends its corresponding share.”
>> 
>> The server may also select no share and respond with a handshake_failure or a HelloRetryRequest (HRR). Since this is already specified in RFC 8446, it would be better to remove this text and simply reference RFC 8446.
>> 
>> - Section 5.1 appears to ​mix different concepts: hybrids, PQ/T hybrids, and lattice-based PQ/T hybrids. I assume the person asking for this section wanted a comparison with [ECDHE-MLKEM]. I suggest doing that. In the future, PQ/T hybrids will likely become less common, but it is unclear whether other hybrids (e.g., ML-KEM + HQC-KEM) will gain adoption.
>> 
>> Cheers,
>> John
>> 
>> From: Joseph Salowey <joe@salowey.net>
>> Date: Thursday, 12 February 2026 at 20:06
>> To: <tls@ietf.org>
>> Subject: [TLS] WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)
>> 
>> This message starts the second Working Group Last Call for the pure ML-KEM document (draft-ietf-tls-mlkem-07).
>> 
>> The file can be retrieved from:
>> https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/
>> 
>> The diff with the previous WGLC draft (-05) is here:
>> 
>> https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-07&difftype=--html
>> 
>> The main focus of this WGLC is to review new text providing more context around the use of pure ML-KEM.  For those who indicated they wanted this text, please let us know if the new text satisfies you and if you support publication. This working group last call will end on February 27, 2026. 
>> 
>> Thank You.
>> _______________________________________________
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-leave@ietf.org
> 
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org

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