Return-Path: 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 17DCA10F36B71 for ; Sun, 5 Jul 2026 10:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783274308; bh=xEZirv+YXDhnszYCSePIrCodnKRuXxjZO1MytRz7KwQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=inMM9uOv16wu6nK6hRtjz+aYrsA9SLB7Z1oReaewFxxED8XYl18t6jwv9AfGLFJu+ 2zcbuFQvN6ykOuwWMQYEdN2qae02g01h7JdGGvtyyo/GiTzmbwzepDw631Mc/dXOQC /MXcUGZ/sK28PnaJbbAwVrEi/1wSgmInP7vLb6iE= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=joseon-com.20251104.gappssmtp.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 Kqfo1A3dXssp for ; Sun, 5 Jul 2026 10:58:25 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 D222510F36B61 for ; Sun, 5 Jul 2026 10:58:25 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id d2e1a72fcca58-8479f1a86ecso1355846b3a.1 for ; Sun, 05 Jul 2026 10:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joseon-com.20251104.gappssmtp.com; s=20251104; t=1783274305; x=1783879105; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type :message-id:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=htfEGXNcmToKzNh6GoMJIOBfp5Ih1t2lHNmlyQg/Li4=; b=RxOzoug2nnEVZEAiBtdGgx91LCONtYGWf5h7lXDyj0mje2xvAbAFRJ8NClEKB4QK8z b2B9Y0Nywwnw2ChdNc++wQli/BWiU4/6GZvJAiuKjVdGeUBeWQiYhLKZ32j3PY5pHf1O Fj2PrXmmttW85Ebvraq9Uwun6PbzmdioAyy73omGl4CLVmhjdH4Ad8YQmg4hWFQpcrII +K+iosAoA9x7peoSqXcQ4e3YTmZEEODJRh3J6MhtA41v7PQ2khgR5KUMmh0FQL9fhUCx 4usJBUWT1hWx5FP9pnA78r+nvzw/L4tPPK75q2b/qkan7SBiKW7BVkkaAyJq3pQtBdgt TW0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783274305; x=1783879105; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type :message-id:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=htfEGXNcmToKzNh6GoMJIOBfp5Ih1t2lHNmlyQg/Li4=; b=K6ZJVPJnvCIsKqBTRp0RGDK6lWRN3BZECnY51rIkB0Skp8VjnNqAdK9s1/L9MZWVn4 KFtomaTnhLn8o7gNNnvCwFmHDzmtkehIF38dPFMxg00GW+uasA68kkLaE90dUmFAr2LR SqfonZr02FRr8J4nXd6w3HVo6lSX/Wtr1vJYsxWsA+2KvYbNUvNJ38RO9iNGsTNrA0Bc qcRF9TxgDvWm1duTc+lqxQ71ARKE644wfYX937Ipc4ZabtBRwyinv9KXN0C1Yk59Nlo1 3zskDIlhhamy5qI9voN9k/cUnhGFudx/i9agsrveCQTsfagSu/E86Ng1VBJFfSo/00pm ClLQ== X-Forwarded-Encrypted: i=1; AHgh+RqYCYsHwXrniITgdc1/Wls+nkf+dpK7kR4mMeq1tN2/t6whTQy4RozXg8Y73m59bANN9sE=@ietf.org X-Gm-Message-State: AOJu0YxeRU/Qucx/Swn2wyatuiBuzkNfag9khVClF1sJRVz7zixbPhOF le3WsxV25QPL0COafkjt+Ne1cAkfTRPlL3G3/84iA9b74/SzwTbTycjnpc5K1zScLlc= X-Gm-Gg: AfdE7ckP8TLBZxLGQlRFM4A4B2nOalbz9GwjcqeGzsNryJv0pWMmGmVTkwMQ0yNi5H1 07p2nCJocwNiqTPoxrUWzpS2yDrcaewJQ2NHoG5bVOYbQ5MFQx2gqtbNfZcf7Ty0ZpJ5R3YCCc8 gdF+uX3sNJSMSBV2cn8HdLttKNazv2Z9JwNgGfX+XMVHSBp6BS3zIjx1VPp32jXskgzGZIo7mfg 4rt8Vn4Z0sYeBTqLhrfEWL0WQqGa/Kj0EDW0lbgA7yPB/Y3ZZHd0i4GuELsh6Nczc7mX3jilMh/ pTJGREB+ijvGpaV6iAnIYXE3cQLHcqPLHiUSGK+jg+80IL0golkuqbY/cInUf1jKEvjnOxbxJ1b SEj/53aYLuExvp4PIQq8p/j6KD3xE275kW1jntcaYRB8DFxoki9axST+YMbRAZOp7dP2D81e5qe L3M/mXBJjhrniIeLbFNswf40NHiptYEQuBgzWiWBhRQdnxIJSq9O59nBA= X-Received: by 2002:a05:6a21:4cc6:b0:3b8:268d:5208 with SMTP id adf61e73a8af0-3c03e50ed03mr7378331637.42.1783274304943; Sun, 05 Jul 2026 10:58:24 -0700 (PDT) Received: from smtpclient.apple ([192.69.242.2]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-13b3c7fa33asm45658187c88.5.2026.07.05.10.58.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Jul 2026 10:58:24 -0700 (PDT) From: Andrew Lee Message-Id: <2313FF37-2C20-4FA4-96E8-8F0C0A3BAB70@joseon.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0AC8DADA-6715-4C72-94E4-103957584B59" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3818.100.11.1.3\)) Date: Sun, 5 Jul 2026 10:58:13 -0700 In-Reply-To: To: Eric Rescorla References: <178231320760.1520243.5914961961176039994@dt-datatracker-f9b87776f-8pmmg> <359785FB-9811-415C-8C62-BD1DF25B85DE@symbolic.software> <2EA38F5C-9516-465F-9AA5-4413C229673A@joseon.com> X-Mailer: Apple Mail (2.3818.100.11.1.3) Message-ID-Hash: 3HAPIMSUQTXWIYFS3WRY5UZMEJQNHERB X-Message-ID-Hash: 3HAPIMSUQTXWIYFS3WRY5UZMEJQNHERB X-MailFrom: andrew@joseon.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: "Salz, Rich" , "Hammell, Jonathan F - [he/il]" , "tls@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BTLS=5D_Re=3A_WG_Last_Call=3A_draft-ietf-tls-mlkem-08_=28Ends_20?= =?utf-8?q?26-07-08=29?= List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_0AC8DADA-6715-4C72-94E4-103957584B59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=E2=80=AFAM, Eric Rescorla = wrote: >=20 >=20 >=20 > On Sun, Jul 5, 2026 at 9:55=E2=80=AFAM Salz, Rich = > wrote: >>=20 >>=20 >> On 7/5/26, 12:33=E2=80=AFPM, "Andrew Lee" > 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=3DN flag. This is the single most important piece of = evidence in this entire debate, because it proves that RECOMMENDED=3DN = is meaningless in practice. >>=20 >> You misunderstand what RECOMMENDED=3DN means. Quoting from an actual = registry[1] >>=20 >> If the "Recommended" column is set to "N", it does not = necessarily=20 >> mean that it is flawed; rather, it indicates that the item either=20= >> has not been through the IETF consensus process, has limited=20 >> applicability, or is intended only for specific use cases. =E2=80=A6= >=20 > Note that it in 8447-bis this reads: >=20 > 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. >=20 > This seems like it would be a fairly accurate description of the = situation around this draft. >=20 > -Ekr >=20 > =20 >>=20 >> This is exactly what Jonathan is saying: >> =E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82Therefore, our = general guidance is not recommending one over the other, as it may be a = use case specific decision. >>=20 >> [1] = https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontyp= e-values.xhtml >>=20 >> _______________________________________________ >> TLS mailing list -- tls@ietf.org >> To unsubscribe send an email to tls-leave@ietf.org = --Apple-Mail=_0AC8DADA-6715-4C72-94E4-103957584B59 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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=E2=80=AFAM, Eric = Rescorla <ekr@rtfm.com> wrote:



On Sun, Jul = 5, 2026 at 9:55=E2=80=AFAM Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org> 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=3DN flag. This is the single most important piece of = evidence in this entire debate, because it proves that RECOMMENDED=3DN is meaningless in practice.

You misunderstand what RECOMMENDED=3DN 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. = =E2=80=A6

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:
=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2= =80=82=E2=80=82Therefore, our general guidance is not recommending one = over the other, as it may be a use case specific decision.


_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-leave@ietf.org

= --Apple-Mail=_0AC8DADA-6715-4C72-94E4-103957584B59--