[TLS] Re: Complaint to ADs and IESG regarding TLS WG chairs falsely claiming WG consensus to issue an RFC for draft-ietf-tls-mldsa
Daniel Apon <dapon.crypto@gmail.com> Mon, 01 June 2026 19:45 UTC
Return-Path: <dapon.crypto@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 45FD2F8DA66B for <tls@mail2.ietf.org>; Mon, 1 Jun 2026 12:45:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1780343156; bh=+D4kkmvxLsanUV/Nw4J9zhR6sWh09zgp1JuFh0yVtTI=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=Lr7aoS9lajNz755XwHpf/cuyVzkxmaXMDkiRNeGWpeaTfuz2fedDveRnGzUJ6Rflp bu5veyRf81ccrPhgnCFWISacE30L8BJpFSjS2bC03Wo+EPzKtoFRhA7foB2yJVvEJ+ S1K752MnBB8o3Yyvk0mdrgO7aiHvzLxDBiJu+1+E=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=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 qgg20QXLnyAo for <tls@mail2.ietf.org>; Mon, 1 Jun 2026 12:45:55 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 6C7C1F8DA5A4 for <tls@ietf.org>; Mon, 1 Jun 2026 12:45:36 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-5aa6792e7b8so1642226e87.1 for <tls@ietf.org>; Mon, 01 Jun 2026 12:45:36 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1780343129; cv=none; d=google.com; s=arc-20240605; b=CRtcEuljqCQFmo9c55JB+8deThZ5vXl0BdxAbrYZ8Uhe5CdQGqsdLvTLm5a18GPxSz cMdBPnPZ3X0vIe58Xupx2xX0l0YUI6eKEgaj0ZKA6XbeDdPMUM0SOK1PxfQnmNSZ3u3d 3QhjvYunbnu7OP+5fNnKaVcMRuXCkLYcdQisBb4Q75skT0D95gIv7i2ktlzpHtJjJrSb ZIbkuJq28obxyn4tjCIx98i9trOaVRz/F01dR/OXU3SH+IJ13P79TrUCp4JvJILajK5L 8jOIN9023NItAZ9SYkcvcR+zAQoVPLNBkLcUQVcxbcdAqMbaZvyrSXeLWZkvyvCtRUj9 bX6w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=TPHHw9QSN/Jn0gkIkqA8zZLn7MoX78HgAkVlCQp0aNk=; fh=L+uK1KOs+wP9MHDHWSHZ51SwXkM9ARvek1+Dk20szJg=; b=H61Et5piG7D6q4IIWXRPSLqHiT7UoRwEtImRtrwmKbKbikM8DUNcf2MV9lRnsjRVIo y6ZhL7+SnXbu0IesgHfEw/T0giQzUtnRDcekYZy1kFIzUS/sIpLgrTt13XqHz35B1slw xaheFAEhdi1KwHM5K6Em2OBsvlCL8pUrVOyqapxe37ZCpNAm3v164trbs+ojxuNwKslB Jg5g0CnvNxgxjWw7rsijIblhw4HhYgq7g3rON0U+u2rWk3NEjkfGHC7YyuYxb/uLXYVB TnbHy5iNQorlZtR/2wBbvu4eo1Z9hsePuf5yo+tneCqjtdHh83xv4V856BwYpmFDlzQU 2fxw==; darn=ietf.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780343129; x=1780947929; 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=TPHHw9QSN/Jn0gkIkqA8zZLn7MoX78HgAkVlCQp0aNk=; b=jDd/DE+l0G/daoDnknzh8TOz4jEOYOxHC+ajgmP2IRK+/E+nQBsoRD7tW+C/iLCegD 0DdiAGhDPxKTZLq99BEsW+W7qHk1/1lmbhIZlxIXTd2sqJmzeg9ihd747hiz+HHf2SH+ iT9TmxG+HY4s66LJh5RU80ahAqCpJwq1t2+InbEVZ61wvb9Ub35Hp1X3aCERDWuRuG8e NriTcLtiyHKnbGzr8jB1NByY+prKpXr0k1q/FAzxIkUcB9hIfp6n/2c3mp3SJSfhnUS6 qix2nQGDRRzGWR2XecoEZdAIJpZpwDr/Adudls0dtDnh2BxhW5fUgbvOgSxP8c45v6dZ v9FQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780343129; x=1780947929; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=TPHHw9QSN/Jn0gkIkqA8zZLn7MoX78HgAkVlCQp0aNk=; b=YwcRZR6kDWL69JIVqtBYMHM4PsCnLNcJ5jC8ZGuZ3D7FOy8S3jcsz0KNmmQ9yXjdz/ yNokCMo5MrXY4hNTvKtBMzuOqizaypi+kjU1VkNSt3I5c5Gj22DLFuxrUgcXMKxbJj0H RMAbFpdUxlmgLyN6Ew68HBXrd+YIqH8LeQqhET4qcExPNQj5yA+I+Kj/cb4HK3UDP9NL O4HNC1B6m3p+p/5+piuI86F0mSdwAILUH34Ai1m/pk2+BhkMicQOeXsJf1mtBG9wQ0Jr Z3vGWCoeyR/IEYU6e7UiJ0yCCLP8A3h8kLBx1z3gVcUBnlRITQfwjaJJX4tOEcZFn/Y6 NaNg==
X-Forwarded-Encrypted: i=1; AFNElJ8ZBAMj8gebMpuxxmIBBvY/ih2Ql8qaAnJcN656tnty42hH8fS+CDRpDLKZ7sZIdHmvhK8=@ietf.org
X-Gm-Message-State: AOJu0Yzh8LsLQfMmxzuQpP8HPenQD6k/PoJPCXL2qiiYVb348LP0hiul CypTrDa4wpw0PJuj35EoEFv/ymfa/0UFEehvUAvdaVe2MoZpaYVxgnQxO8KHS8nmmYb5IGf6tv6 RCl6Pp1Aa5HAbFHLl/YyT6soxIoaAxfw=
X-Gm-Gg: Acq92OEJsAzCvr9DWzhmd0p2mCQbxBHSXxWCfy8BHG8lAT+RFPnIbY3BC+ye0mQqnPS HuZyNUGPF/s3zSzpGG1wy9yRGzeqlfGnB0QMSonqava5RjCHE9RxYv9PfpsVA7C6yXzSb2fNvEJ jsj4VPE6poIq/J4hxLno9g29WSB5Pn5S04zbOBbcJ3eOc24aCaWvfk8AAbdpzD3aT36FNApmyY0 aYeQWM25wiY+//i01zC/cV4gcX8IZ00NOgwpaoRo8xSMy2W2EmfnqD786dnEn0LCoPsDIyxdoTL MvUYGdKF9y/Nl9YjntkQVQ8Bzz304vDKDOBAPAx8JfY8Vy5L7IMl91SoE23rhHk3nOqL4GbhntG LlacTVtFZ0Q7sDlDof0WNYbm6I5tHyEieBX6xIbl4VFTRLtdk6eqa4ztEqM0fsM1g2IzB
X-Received: by 2002:a05:6512:3d91:b0:5aa:6585:1b99 with SMTP id 2adb3069b0e04-5aa65851d1amr3439744e87.23.1780343128335; Mon, 01 Jun 2026 12:45:28 -0700 (PDT)
MIME-Version: 1.0
References: <20260519112813.1254795.qmail@cr.yp.to> <CAGgd1Ocy8f4HeQy-qWauAJAxizznXdXA53kWVp_FV1QUVGuxWw@mail.gmail.com> <5DFBF81F-4A98-4C5E-A060-580DC6960021@symbolic.software> <87v7c8lgt8.fsf@josefsson.org> <CACsn0cmaOdG4vCdeOVSxAPnJtPRH8rBJ3sfAY3o0f1fm-ouceg@mail.gmail.com> <ahddRzOIvQDXcvaG@ubby> <CACsn0cnStbBw8Szq+McPumjExnbL=3wmwESYEMWczJJZbJXRgw@mail.gmail.com> <ahdflj/Xy8VoOfH5@ubby> <CABcZeBO3hPa2PXNBzfBHLRAGdc3LzcpJGMQwo8f8ufwfhxy1Zw@mail.gmail.com> <87ldd4j7fm.fsf@josefsson.org> <ahgzW1SQNUS8OhUA@LK-Perkele-VII2.locald> <CACaGApmvARUhMiMegHp+Q0O5KuYwW66qOYxQcV9DdKRfHu24EQ@mail.gmail.com> <AS4PR07MB8825B332ED2BFEA91BED403589172@AS4PR07MB8825.eurprd07.prod.outlook.com> <85e8b5d6-3ad2-4722-bc8c-32b48b83b3ce@uni-wuppertal.de> <CAPxHsSLSpYHyMvpHNnoqMsLgzb-ATSutn7kc0wEUoxD-9PvjoA@mail.gmail.com>
In-Reply-To: <CAPxHsSLSpYHyMvpHNnoqMsLgzb-ATSutn7kc0wEUoxD-9PvjoA@mail.gmail.com>
From: Daniel Apon <dapon.crypto@gmail.com>
Date: Mon, 01 Jun 2026 15:45:16 -0400
X-Gm-Features: AVHnY4LQgLLbkul7rTAP2wIPNapNhRQ2TPzzNs5Fy7qrpwejFv2Ywgo7FPgdJHQ
Message-ID: <CAPxHsSJeTCpP4vyULO0VCnme6HH9YU5fD5KO_ZBFKMqgPTatLQ@mail.gmail.com>
To: Tibor Jager <jager@uni-wuppertal.de>
Content-Type: multipart/alternative; boundary="000000000000be27cc0653366f80"
Message-ID-Hash: FBYGYGWYD4IHRGVBE7EZDJEULSL6MXVT
X-Message-ID-Hash: FBYGYGWYD4IHRGVBE7EZDJEULSL6MXVT
X-MailFrom: dapon.crypto@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: tls@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: Complaint to ADs and IESG regarding TLS WG chairs falsely claiming WG consensus to issue an RFC for draft-ietf-tls-mldsa
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/xyG4Ee3XuFtFBvb_ixE46vxzzqM>
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>
P.S. in full disclosure, I maintain my position of Recommended=Y for hybrid solutions, as well as supporting pure-PQC solutions being obviously standardized as well. On Mon, Jun 1, 2026 at 3:40 PM Daniel Apon <dapon.crypto@gmail.com> wrote: > " This statement might of course be outdated, but I recently asked one of > the members of the CRYSTALS team whether this is still his view, and the > response was: "Yes, of course." " > > I also recently asked *TWO* members of the CRYSTALS team whether they > support hybrids in their view, and their joint response, which they wrote > in tiki torches -- flaming and placed across the facade of a certain > skyscraper located in the Iberian Peninsula, with a massive fireworks show > celebrating the lighting of these torches -- was "No, of course not!" > > [[*The above was said facetiously*. In full disclosure, I have not been > explicitly told by the CRYSTALS team that they lit fiery torches in the > Iberian Peninsula with a massive fireworks show in support of any > particular cryptographic viewpoint.]] > > ----- > > *On a more serious note:* This entire thread of discussion is blatantly > lacking in any novel, critical technical material. > > In fact, this entire thread of discussion has been kicked off by DJB, in a > fervent (hopefully deeply sincere!) attempt to remedy what he views as a > technical gap in upcoming standards. > But, let's be clear: DJB had years to make *his technical case* in the > NIST PQC process, and he didn't achieve what he hoped. > > Indeed, despite claiming early in the process that he would have a massive > technical breakthrough that would break NewHope, Kyber, etc. (and thus, > presumably lead to NTRU Prime being the chosen standard) -- which motivated > the creation of the NIST PQC 3rd Round Seminar Talk Series > https://csrc.nist.gov/Projects/post-quantum-cryptography/post-quantum-cryptography-standardization/round-3-submissions/round-3-seminars > in the first place, which now continues to this day as > https://csrc.nist.gov/projects/post-quantum-cryptography/workshops-and-timeline/pqc-seminars > (and thus, is still open to DJB giving a technical talk with his > long-promised cryptanalytic breakthroughs) > > So, DJB has moved to this IETF process: a more *political* and more > *human* process, involving significantly less technical discussions, and > hammered and hammered against the constraints of the process here itself to > lead us to this point. > > After all, the worst thing for those advocating against pure-PQC solutions > is a technical discussion on the cryptographic merits. > > On Sat, May 30, 2026 at 3:54 PM Tibor Jager <jager@uni-wuppertal.de> > wrote: > >> >> >> On 30.05.26 14:11, John Mattsson wrote: >> > >> > - Most experts have a high degree of confidence in hash-based and >> > lattice-based signatures. This includes US NIST, CNSA 2.0, European >> > crypto agencies, as well as cryptographers in academia and industry, >> > such as Sophie Schmieg [2]. >> >> This suggests a consensus in academia that, as far as I can tell, does >> not exist. >> >> Regarding “most experts”: the authors themselves (!) of Dilithium/ML-DSA >> recommend hybrid deployment. On their website they write (see >> https://pq-crystals.org/dilithium/index.shtml) >> >> "For users who are interested in using Dilithium, we recommend the >> following: [...] Use Dilithium in a so-called hybrid mode in combination >> with an established "pre-quantum" signature scheme." >> >> >> Similarly, for Kyber/ML-KEM (see >> https://pq-crystals.org/kyber/index.shtml) they write: >> >> "For users who are interested in using Kyber, we recommend the >> following: [...] Use Kyber in a so-called hybrid mode in combination >> with established "pre-quantum" security; for example in combination with >> elliptic-curve Diffie-Hellman. >> >> >> This statement might of course be outdated, but I recently asked one of >> the members of the CRYSTALS team whether this is still his view, and the >> response was: "Yes, of course." >> >> >> In my view, the concern is not with lattice-based cryptography as a >> paradigm, nor with the algorithms. Also, not with backdoors. Rather, it >> is with the underlying hardness assumptions and, in particular, the >> concrete parameter choices. At present, these appear fine. However, >> assuming that this assessment is unlikely to change seems optimistic. >> >> >> > I am very unconvinced by people who criticize ML-DSA while >> > not applying the same scrutiny to RSA, ECDSA, and EdDSA. The criticism >> > of ML-DSA and IETF often applies double standards that don't survive >> > scrutiny. >> >> >> The above comparison is not entirely apt. 30-40 years ago, there were >> fewer alternatives available, computational resources were much more >> limited, and hybrid deployment was generally not a practical option. By >> the time computational costs had decreased, RSA and >> discrete-logarithm-based systems had already accumulated decades of >> scrutiny and practical experience. >> >> More importantly, in my perspective, advocating hybrids is neither a >> criticism of ML-DSA, nor an application of double standards. But it is a >> matter of risk management. We are considering introducing algorithms >> based on comparatively new hardness assumptions into the most important >> cryptographic protocol on the Internet. There is nothing wrong with >> optimism, but in this context one may also argue that a more cautious >> approach is warranted. Better safe than sorry. >> >> >> >> _______________________________________________ >> TLS mailing list -- tls@ietf.org >> To unsubscribe send an email to tls-leave@ietf.org >> >
- [TLS] Complaint to ADs and IESG regarding TLS WG … D. J. Bernstein
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Soatok Dreamseeker
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Muhammad Usama Sardar
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Nadim Kobeissi
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Nadim Kobeissi
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Deb Cooley
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Nadim Kobeissi
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Simon Josefsson
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Watson Ladd
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Nico Williams
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Watson Ladd
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Nico Williams
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Watson Ladd
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Eric Rescorla
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Eric Rescorla
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Nico Williams
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Martin Thomson
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Nico Williams
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Simon Josefsson
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Ilari Liusvaara
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Salz, Rich
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Joseph Birr-Pixton
- [TLS] Re: Complaint to ADs and IESG regarding TLS… John Mattsson
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Tibor Jager
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Bas Westerbaan
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Daniel Apon
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Daniel Apon
- [TLS] Re: Complaint to ADs and IESG regarding TLS… IETF Chair
- [TLS] Re: Complaint to ADs and IESG regarding TLS… IETF Chair
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Tibor Jager
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Simon Josefsson
- [TLS] Re: Complaint to ADs and IESG regarding TLS… Daniel Apon