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" <[email protected]>
To: [email protected], Sean Turner <[email protected]>
Mail-Followup-To: [email protected]
Subject: Re: [TLS] Working Group Last Call for Use of ML-DSA in TLS 1.3
In-Reply-To: <[email protected]>
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
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
