[TLS] Re: Complaint to chairs regarding false claim of consensus to issue an RFC for draft-ietf-tls-mldsa

[Jacob Appelbaum <[e-mail]>]

Hi Dan (et al),

On 4/29/26 06:49, D. J. Bernstein wrote:
> Sean Turner writes:
>> The chairs have judged that there is consensus to progress this I-D.
> 
> There isn't consensus; not even close. I'm hereby complaining to the
> IETF TLS WG chairs under BCP 9, Section 6.5.
> 

I agree. I have already stated on the tls list in reply to Stephen that 
the consensus should be vacated in another thread. It seems plainly 
obvious that it couldn't be fairly declared as "consensus" or even rough 
consensus. The discussion related to an outstanding edit _after_ 
consensus was declared was mildly surprising in that context and it only 
further underscores the lack of consensus.

I am even more surprised that your complaint hasn't been acknowledged, 
nor has it been released from list moderation in the ~five days since 
you sent it. This delay probably gives the appearance on the tls list 
that there is no sustained and well reasoned objection to the 
declaration of consensus, or that objectors who spoke up after consensus 
was declared are simply isolated exceptions. Moderating your complaint 
seems plainly and directly related to your views on hybrid cryptography, 
and to the views of others who were ignored in the consensus call.

> There were at least _11 people_ sending clear objections to the TLS WG
> mailing list during the specified "last call" period: David Stainton,
> Fabiana Da Pieve, Jacob Appelbaum, Ludovic Perret, Muhammad Usama
> Sardar, Nicola Tuveri, Simon Josefsson, Stephen Farrell, Tanja Lange,
> Thomas Bellebaum, and at least one person (the one I know about is me)
> whose objection sent to the list was censored by the chairs.

That matches my understanding. You are correctly representing the facts 
as far as I understand them.

To reconfirm for myself: my concerns were not addressed. In-fact in one 
discussion where I raised entirely on topic issues including factual 
citations with relevant cryptographic sabotage history, the thread was 
declared off-topic somewhat abruptly and without justification beyond a 
characterization of the discussion "veering off-topic."

Setting aside the appearance of a conflict of interest in that 
declaration, my actual comments and concerns from that thread and 
related threads were not addressed.

My stated issues included several technical questions and the related 
highly relevant _appearance_ of corruption of process concerns. There is 
some irony of an additional appearance of a conflict of interest in 
ruling a thread off-topic as reinforces the need to address those 
matters directly.

Consensus was declared without addressing or even responding to those 
concerns or to other concerns by other objectors as you enumerated. I 
could repeat my concerns again in this email but I worry that repeating 
myself now would also risk moderation...

> 
> (I worry that this message similarly won't appear on the list. I'm
> cc'ing the other 10 people listed above so that, just in case I
> misunderstood their postings, they can correct me.)
> 

Given the statements about the basis for your moderation, I don't see 
why this wouldn't show up on the list. With that said, I think it hasn't 
yet which is odd. Perhaps this is a coincidence of timing with the 
weekend and a lack of list moderation people in other time zones than 
(North) America?

> Meanwhile 37 people stated support on list, including a document author
> (Sophie Schmieg), two other Google employees (David Adrian and David
> Benjamin), an NSA employee whose name has never shown up on the TLS
> mailing list before (Nicholas Gajcowski), etc. That's more than 11
> people, but IETF decisions are _not_ made by majority vote. As
> 
>      https://web.archive.org/web/20260425180139/https://www.ietf.org/support-us/endowment/
> 
> puts it, IETF is "the primary _neutral_ standards body because
> participants cannot exert influence as they could in a pay-to-play
> organization where members, companies, or governments pay fees to set
> the direction. IETF standards are reached by rough consensus, allowing
> the ideas with the strongest technical merit to rise to the surface".
> 
> Every WG-issued RFC claims "consensus of the IETF community". That's not
> merely "majority support"; certainly not merely "majority support from
> people who spoke up on the mailing list during a two-week WG last call".
> 
> Furthermore, contrary to what readers would expect from a "last call"
> for objections, there were already various objections filed to this spec
> _before_ the "last call"---including objections from people not listed
> above. For example, Izzy Grosof wrote (along with further explanation):
> "The performance improvements of a non-hybrid approach are trifling; the
> security risks are immense ... Do not endorse or standardize any
> non-hybrid post-quantum cryptosystem, via this document or any other."
> 
> That statement was posted in response to a "last call" regarding
> non-hybrid ML-KEM in TLS, but, obviously, also applies to non-hybrid
> ML-DSA in TLS. Some proponents of non-hybrid ML-DSA in TLS claim that
> arguments against non-hybrid ML-KEM in TLS don't apply to ML-DSA; this
> claim is disputed, and in any case it would be insane for the chairs to
> allow a proponent to withdraw _someone else's_ objection.
> 
> The chairs promised last month that they wouldn't engage in this
> insanity---that previously stated positions would be taken into account
> unless retracted: "If you did not recommend changes, then your position
> will remain the same, unless you state that you are reconsidering." But
> then the chairs were obliged to (1) acknowledge that there were already
> unresolved objections to the ML-DSA spec and (2) refrain from issuing
> "last call". I already wrote that issuing "last call" was improper (see
> postscript below), but the chairs censored my message.
> 
> RFC 2418 includes some absolute requirements for WG decisions. One of
> them is to reach at least "rough consensus" ("Working groups make
> decisions through a 'rough consensus' process"). This did not happen for
> draft-ietf-tls-mldsa. The numbers for this "last call" are nothing at
> all like RFC 2418's example where "100 people in a meeting" reach
> agreement and "only a few people on the mailing list disagree with the
> consensus".
> 
> Furthermore, RFC 2418 states that "51% of the working group does not
> qualify as 'rough consensus'"---which does not merely say that 51% _of
> the people responding_ does not qualify; it says that 51% _of the
> working group_ does not qualify. 37 people is very far below 51% of the
> TLS working group, so it's very far below the level of support that RFC
> 2418 says is _still_ not enough.
> 
> (Just to be clear about who counts as part of the WG: IETF says in
> https://web.archive.org/web/20250603130154/https://www.ietf.org/about/introduction/
> that "Anyone can participate by signing up to a working group mailing
> list". RFC 2418 says the same: "Participation is open to all. This
> participation may be by on-line contribution, attendance at face-to-face
> sessions, or both. Anyone from the Internet community who has the time
> and interest is urged to participate in IETF meetings and any of its
> on-line working group discussions." So, according to the rules, even
> NSA's Nicholas Gajcowski counts as a participant---as do hundreds of
> people who _have not_ stated support for this spec.)
> 
> Another RFC 2418 requirement that has been violated here, perhaps the
> most fundamental requirement, is the following: "Disputes are possible
> at various stages during the IETF process. As much as possible the
> process is designed so that compromises can be made, and genuine
> consensus achieved; however, there are times when even the most
> reasonable and knowledgeable people are unable to agree. To achieve the
> goals of openness and fairness, such conflicts must be resolved by a
> process of open review and discussion."
> 
> This mandated resolution process did not occur here. This isn't just a
> question of what happened during "last call": most of the objections
> tracked in https://blog.cr.yp.to/20260221-structure.html were already
> raised earlier, and many of those still haven't even been answered by
> anyone, let alone resolved by the WG.
> 
> Part of the responsibility of the chairs is to track disputes and
> enforce the "must be resolved" rule, so that document proponents are
> forced to build consensus. What the chairs have instead been doing is
> issuing one "last call" after another while not acknowledging most of
> the objections to these non-hybrid documents. For rich companies, it's
> no problem to pay employees to flood the IETF process with redundant
> support statements (and the costs are even less noticeable since the
> chiars allow one-line support statements); people acting in the public
> interest very often can't afford redundant work, and yet the chairs are
> demanding that objections be stated and explained again and again. RFC
> 2418 does not allow burdens to be shifted in this way: it requires the
> WG to resolve objections by a process of open review and discussion.
> 
> Finally, the document in question is related to (and normatively cites)
> the TLS 1.3 spec, which is on the IETF standards track. This makes the
> document "standards-related", bringing the chair discussion of the
> document within BCP 9's rule that the public record of IETF's
> "standards-related activity shall include at least the following: ...
> complete and accurate minutes of meetings; ... all written contributions
> from participants that pertain to the organization's standards-related
> activity". Obviously the chairs had a discussion of whether to issue a
> "last call" and of how to handle the results, but the records of those
> discussions aren't publicly available. My complaint isn't just about the
> false claim of consensus, but about the surrounding secrecy, which makes
> the appeal process unnecessarily difficult and violates BCP 9.

This is my understanding as well and I was surprised that consensus was 
declared without even addressing the numerous outstanding concerns.

> 
> ---D. J. Bernstein
> 
> P.S. Here's another copy of the objection I filed during "last call":
>> From: "D. J. Bernstein" <[e-mail]>
>> To: [e-mail], Sean Turner <[e-mail]>
>> Mail-Followup-To: [e-mail]
>> Subject: Re: [TLS] Working Group Last Call for Use of ML-DSA in TLS 1.3
>> In-Reply-To: <[e-mail]>
>>
>> A controversial document is not "the consensus of the IETF community".
>> It is deceptive and procedurally improper for chairs to issue a "last
>> call" for objections when there were already unanswered objections.
>>
>> Back in February, there was a "last call" for objections to non-hybrid
>> ML-KEM in TLS, and 22 people filed objections:
>>
>>      https://blog.cr.yp.to/20260405-votes.html
>>
>> Many (not all) of the objections stated rationales that also apply to
>> non-hybrid ML-DSA in TLS, sometimes verbatim. My tracker
>>
>>      https://blog.cr.yp.to/20260221-structure.html
>>
>> (most recently updated on 18 April) shows that some objections were
>> answered but some were not. So there shouldn't have been a "last call"
>> for non-hybrid ML-DSA in the first place.

I agree, and it seems par for the course as you have clearly documented. 
The burden is again unfairly on objectors who favor hybrid (i.e.: less 
risky) constructions.

>>
>> I had already, before this "last call", objected to the "proposal to use
>> non-hybrid ML-DSA in TLS" and said why. Unfortunately, it seems that the
>> chairs will disregard this objection unless I repeat it in this new
>> thread. So: I object to the issuance of this document as an RFC, for the
>> reasons I've already explained. Most importantly, we have already seen
>> many PQ security failures, including Dilithium/ML-DSA security failures;
>> I expect many further PQ security failures; when PQ fails, ECC+PQ often
>> saves the day; ECC adds negligible cost on top of PQ.
> 
> 
> ===== NOTICES =====
> 
> IETF BCP 78, "Rights Contributors Provide to the IETF Trust", provides a
> modification right "unless explicitly disallowed in the notices
> contained in a Contribution (in the form specified by the Legend
> Instructions)".
> 
> The official language from IETF's "Legend Instructions"
> for the situation that "the Contributor does not wish to allow
> modifications nor to allow publication as an RFC" is as follows: "This
> document may not be modified, and derivative works of it may not be
> created, and it may not be published except as an Internet-Draft."
> <https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf>
> 
> The same language is used in, e.g., RFC 5831. The same language hereby
> applies to this document. This is not disclaiming or limiting the
> applicability of IETF policies; it is strictly following IETF policies.
> 
> Rationale: I'm fine with redistribution of copies of this document. The
> issue is with modification, such as (1) IESG's May 2025 posting of an
> IESG-mangled version of an appeal that I had filed and (2) IETF
> management selling IETF mailing-list text to AI companies.

Thanks for that context, I appreciate it.

Kind regards,
Jacob Appelbaum