[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
>>
>