IETF Logo Mail Archive

[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

Kevin Milner <kamilner@kamilner.ca> Sun, 05 July 2026 19:33 UTC

Return-Path: <kamilner@kamilner.ca>
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 7936310F42FBB for <tls@mail2.ietf.org>; Sun, 5 Jul 2026 12:33:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783279980; bh=vrsNK3jJxCK6Y7ryPt1lLvnICatAggANX+NZReFwprE=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=BwqqoibzkCewE5iIl9Rega9hpatbrGBkENJzVPUiuDzZRDMj4pKcumiBIxFbKiMYz OiRSeDWDYps77EHb/Edzm8mLaW2XPE3VTMjA105pFpmsl2yVsNH7wo7X76q9Ipxgvw DC7BkFdDFp8XhiKXN8QsU/xvco0cZhFChmWECBRc=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=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=kamilner.ca header.b="GMs1h5Dy"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="BT1Qxohp"
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 Gw9awVM2uZfd for <tls@mail2.ietf.org>; Sun, 5 Jul 2026 12:32:59 -0700 (PDT)
Received: from fhigh-b8-smtp.messagingengine.com (fhigh-b8-smtp.messagingengine.com [202.12.124.159]) (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 9804810F42FAE for <tls@ietf.org>; Sun, 5 Jul 2026 12:32:59 -0700 (PDT)
Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfhigh.stl.internal (Postfix) with ESMTP id CA7547A00DD; Sun, 5 Jul 2026 15:32:52 -0400 (EDT)
Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Sun, 05 Jul 2026 15:32:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kamilner.ca; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1783279972; x=1783366372; bh=cMM2qrxL5d SsKKRf+yBQhQjOV0zkH3Z6oAs00SSG93c=; b=GMs1h5DyJ7bKo+K1X3GzTKZHwc Fq7CTMHpd2UY0He55j7/U0F9DS/bSZs4IXDjR4auxFk9CvA889CMjoznHGHiqDcw gQm5wzfg8nL7xHeDW5Q+Fai8xzXbUbY/ireqk8Xk6Gp5YDXFFya0JYT6+7AcaDFv CZ/Xwu7ZuExee0xV0KOLD6Yhnbw45vXME1IXg1kPbx/4yfgP6vIyE+0OiWIFn0hz ERV31ynyW72Ymv4OHCcLNNq1yXPKJBMsDV0JWUUK2HDLID/dK+RFACeHThSXW57f D5fiURxiVZvjEIe/ZVTosFewkF2GHSWkBGlKWHaPoWIgp5E12ZIIpVgy5O2w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1783279972; x=1783366372; bh=cMM2qrxL5dSsKKRf+yBQhQjOV0zkH3Z6oAs 00SSG93c=; b=BT1Qxohpa2Xbxr6QaL09tSjOf6NipRk+ZGylW6tZtgc5L3EzMWd KvthQ3Y9vMwBApLiB9rlvnaQ6gagADe/agLTj5UG2+SC3MEs++Lx2Rg4Y32RyMsn stWVydbEz6fK6+GP39ChOGK1yG49kf7hxLRxq3udoPdKLXIekwZQksB5BelWdAyW dUIk08aq17WWPEaPVuaCqzJS9Ku52fVfSH4vD+1sOCrbxw/ugOTs2s5yUTGJN33U K8fBWM6Tlal6sdKVPZdMB6AkIXrf5r/Xtwny1CkeF3g7RnisDXaxu7tUJdj3Mj5F oAFUcRAW3KbNXLow4kPtsxMHGOmtYgPDweA==
X-ME-Sender: <xms:ZLFKargvJS69JDz5PV8KvT8pc8hRoPV2f5FeLYMW1qYb6Ffja7-yAA> <xme:ZLFKapjL9SFg4qDApExzL1mx5cthjw94EUaJOM5VJr-SGdqUXStomprRXVPOCcOED WVwxUE4AtxYVq5UtouwncyxpPmnB2WWgYypMOlM-19GuNgZsR5bRw>
X-ME-Received: <xmr:ZLFKarL8x_9bbP_PBQGI2bk2lzYizPHtm8IulAM5mxIBXLV857th_A3oa0YjLvAxmEa1dzDgk6e9SnY17Y6hdhM0NTiLpn3tLvheE_F0C9S2oQwGbGVYIYmrFmSg>
X-ME-Proxy-Cause: dmFkZTGa/R3qcpkU9Y0zpphATt3pC8kOr6If/OxDoBpd29/HKdouNFLeeXpamkVLLYrz41 8DwLUDYbuJ47WsTpZ2P9HOPhVuWXgK+70cnUKKesMU9x4XCebsLZE4GL1bRrZ6mBA3zNIf CCySvHT4ESjOnJQ9sPV3IqjWO9HAJMcAhDCfTQdy4OcFMi76mSzb/bvGsPq7zRgVLZNK4Q xx4hmXu/WzMFX8EAqYH9KlCpFjYZIfbag/ts795GOJKSxQmtVW9jnXTX3HobbMqsGYD25s DTueoOfBxoI+kpqYEefl5zhxECvnAVTFACqvaWBTexOqFzScDl+qmRPDf6slS5alZ/nELb MHsM5kxKq74IEbG2gzZfpR/+rOqvu4SqeS1niXTNYTNWXqpbsnKhhZ1CL907ZcLS9e7lfM Ylqi7Jf2LKTgwOc8M2/2drBpdNsTv/uKnv0rJbKG1s9WQEKypOybU2X4peXMF2kWVmlWcE UqAQT4hh/wsGe7w3VA6WqInSJJj+BSvJlp7ORXqy8QKkcfZspuA8kObeEPEUaEJHU/oDHb Oi2XPkFwB/wxgIEKLnD4UTfabxGSUTgNNnFhOcG3kjziw74WORrgenh7MPofKaw7Zu/rPd wDxXn/8U8C8IfnXzOVbjMn11DWTh4dTHUqKNC4GdVBcRRXMbYvJ36NH7QgUQ
X-ME-Proxy: <xmx:ZLFKaoHdQumZPt3A0PaMZgDORI5lGH-fuxBMn8ddVc3vZ_Le-4GpIw> <xmx:ZLFKavR9n8uc3s-M_poxRclA0DD0XGwsZ3uj5-HHtFPEg92mabiUjg> <xmx:ZLFKakcac6rpVn2sVZw4liPD5eitQaVRgWhgrJqG8kYqK68q2p-wnA> <xmx:ZLFKaupU1RCdG4zaZ2GNv8J9-IfrI6TKCT__qKAXbV489UozTk_YiQ> <xmx:ZLFKatHcRIojdRAxAxLrwzN2ELOzv_1Q2QTrqzho6tn46BEEHI9o7W3U>
Feedback-ID: ifa684292:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 5 Jul 2026 15:32:51 -0400 (EDT)
From: Kevin Milner <kamilner@kamilner.ca>
Message-Id: <B4784947-AED4-45AA-9051-9095605E2E7B@kamilner.ca>
Content-Type: multipart/alternative; boundary="Apple-Mail=_35E972EE-50F8-48EA-958F-395272AF6987"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Date: Sun, 05 Jul 2026 20:32:40 +0100
In-Reply-To: <2313FF37-2C20-4FA4-96E8-8F0C0A3BAB70@joseon.com>
To: Andrew Lee <andrew@joseon.com>
References: <178231320760.1520243.5914961961176039994@dt-datatracker-f9b87776f-8pmmg> <LO0P123MB399432655F4343DDCF3991748FF62@LO0P123MB3994.GBRP123.PROD.OUTLOOK.COM> <359785FB-9811-415C-8C62-BD1DF25B85DE@symbolic.software> <FAD9FCF2-217F-4AD2-A065-B633F2F26780@kamilner.ca> <2EA38F5C-9516-465F-9AA5-4413C229673A@joseon.com> <TO1PPF1F9B62E537336C3160522DE4827A1C8F22@TO1PPF1F9B62E53.CANPRD01.PROD.OUTLOOK.COM> <ACB703BD-B515-4852-96EB-7753803DD753@joseon.com> <MN2PR17MB40310236D8AE9AA8C1D9D125CDF22@MN2PR17MB4031.namprd17.prod.outlook.com> <CABcZeBOkiDiAQ6cE_R0DvLUNrEmWa6B6NBjkp+gSRJJaKy+o3g@mail.gmail.com> <2313FF37-2C20-4FA4-96E8-8F0C0A3BAB70@joseon.com>
X-Mailer: Apple Mail (2.3864.600.51.1.1)
Message-ID-Hash: XXXZYXYAQJUZ42GPAC3RKQ4LJE2PSPWT
X-Message-ID-Hash: XXXZYXYAQJUZ42GPAC3RKQ4LJE2PSPWT
X-MailFrom: kamilner@kamilner.ca
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: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, "Hammell, Jonathan F - [he/il]" <Jonathan.Hammell@cyber.gc.ca>, "tls@ietf.org" <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)
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/I7KNZWo27m-2C36Nm5nXzrYlW8E>
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 Andrew,

I think I understand your confusion now, thank you for elaborating. Please correct me if I’m wrong, but I believe you are interpreting the following facts:
1. The Canadian Centre for Cyber Security will recommend pure ML-KEM
2. The Canadian Centre for Cyber Security does not care if an eventual RFC includes Recommended=N
to mean that Recommended=N does not have value.

I think I can clear this up, though. Both 1) and 2) are true because the Canadian Centre for Cyber Security has no reason to particularly care whether the IETF has stated Recommended=N, they set their own recommendations independent of the IETF. Similarly, I am assuming their recommendation would not change if the IETF has no RFC at all (if they are similar to other national bodies). The IETF does not have sovereignty over national agencies, and whether there is an RFC for pure ML-KEM almost certainly has no bearing on their recommendations in the same way the Recommended=N in the RFC has no bearing on their recommendations.

If your argument is that Recommended=N is insufficient to prevent The Canadian Centre from Cyber Security from recommending pure ML-KEM, then the exact argument holds that voting no on this draft is insufficient. This would, I think, indicate this specific argument has no relevance to the current last call.

But, for what it’s worth, the Recommended=N in the draft is not directed at the Canadian Centre for Cyber Security! We have no control over them, after all. It is aimed to be an IETF recommendation, as Eric explained, for everyone else. If you believe that publishing no guidance on usage of pure ML-KEM is better than publishing guidance against the usage of ML-KEM, that is fine, but I think you might be mistaken on the relevance of Jonathan’s comments to the current last call.

Cheers,
Kevin


> On 5 Jul 2026, at 18:58, Andrew Lee <andrew@joseon.com> wrote:
> 
> Dear Eric,
> 
> For starters, the Canadian Centre for Cyber Security is not "some set of entities." It is a Five Eyes government cybersecurity agency who has a massive impact on an entire nation's infrastructure.
> 
> They told this mailing list they will treat N the same as Y which is policy affecting millions of systems and people therewith.
> 
> That said, let me now address a deeper problem for those who support publishing a draft on solo ML-KEM, because I believe a paradox has emerged from the arguments made by yourself and Eliot in defense of the N flag, and I thank you for bringing it to light.
> 
> 
> 1. If there is no consensus to publish, which is the opposition's position and which Eliot appears to lean on as the reason for the N, then the document should not be published at all.
> 
> 2. If the chairs determine there IS consensus and publish the RFC, then it will have gone through 3 WGLCs and also a full IESG review. At that point, "the item has not been evaluated by the IETF" becomes impossible.
> 
> 3. The N can then only derive from the limited applicability or specific use cases booleans.
> 
> To be clear, Canada has told us on this list they will disregard that distinction, even though the flag fails under both outcomes.
> 
> If no consensus, publication is obviously unjustified.
> 
> If consensus, the N cannot mean "not evaluated," leaving only the reasons Canada plans to ignore.
> 
> Chairs, I hope you can understand that publishing this draft will essentially turn the IETF's rulesets into a hodgepodge of contradictions in addition to the other dangers already documented within the IETF by the foremost cryptographic experts.
> 
> I rest my case.
> 
> Best,
> Andrew
> 
>> On Jul 5, 2026, at 10:32 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>> 
>> 
>> 
>> On Sun, Jul 5, 2026 at 9:55 AM Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org <mailto:40akamai.com@dmarc.ietf.org>> wrote:
>>> 
>>> 
>>> On 7/5/26, 12:33 PM, "Andrew Lee" <andrew@joseon.com <mailto:andrew@joseon.com>> wrote:
>>> Thank you for confirming, on the record, that the Canadian government plans to recommend solo ML-KEM for TLS despite the document carrying a RECOMMENDED=N flag. This is the single most important piece of evidence in this entire debate, because it proves that RECOMMENDED=N is meaningless in practice.
>>> 
>>> You misunderstand what RECOMMENDED=N means.  Quoting from an actual registry[1]
>>> 
>>>     If the "Recommended" column is set to "N", it does not necessarily 
>>>     mean that it is flawed; rather, it indicates that the item either 
>>>     has not been through the IETF consensus process, has limited 
>>>     applicability, or is intended only for specific use cases. …
>> 
>> Note that it in 8447-bis this reads:
>> 
>> Indicates that the item has not been evaluated by the IETF and that the IETF has made no statement about the suitability of the associated mechanism. This does not necessarily mean that the mechanism is flawed, only that no consensus exists. The IETF might have consensus to leave an items marked as "N" on the basis of its having limited applicability or usage constraints.
>> 
>> This seems like it would be a fairly accurate description of the situation around this draft.
>> 
>> -Ekr
>> 
>>  
>>> 
>>> This is exactly what Jonathan is saying:
>>>       Therefore, our general guidance is not recommending one over the other, as it may be a use case specific decision.
>>> 
>>> [1] https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
>>> 
>>> _______________________________________________
>>> TLS mailing list -- tls@ietf.org <mailto:tls@ietf.org>
>>> To unsubscribe send an email to tls-leave@ietf.org <mailto:tls-leave@ietf.org>
>

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