https://blog.cr.yp.to/20260221-structure.html charts the actual debate
about non-hybrid-PQ-in-TLS specs, including direct links to statements
from proponents and opponents. One point (re FATT) seems to have been
resolved, but most of the debate hasn't been resolved. For example, I
say that these specs frivolously incur unnecessary security risks
compared to common-sense ECC+PQ; obviously proponents disagree.

Rather than insisting on the disagreement being "resolved by a process
of open review and discussion" as RFC 2418 requires, the chairs claim
"There is consensus to move this document forward - a ratio of 4:1".

The starting problem with this claim is that the "ratio of 4:1" is a
fabrication by the chairs. There were only 37 people stating support
(even _after_ vote-packing by NSA and its "vendors"), versus 14 people
stating objections. This is nowhere near 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". RFC 2418 also states that
"51% of the working group does not qualify" as "rough consensus"; 37
people is very far below 51% of the TLS WG.

The chairs have never posted their claimed lists of supporters and
opponents. They haven't even posted their claimed totals, beyond the
"4:1" claim. Checking the facts takes work for readers. It saves time to
see a spec proponent admit how controversial non-hybrid PQ is.

> > > The significant and details of the problems is so controversial that
> > > we have not been able to achieve consensus.
> > I appreciate seeing a spec proponent admit the lack of consensus.
> I was talking about consensus for a new document that would discuss
> the issues and trade-offs in writing a new document like Eliot and
> others have proposed.

You already admitted on the TLS WG list in February that a new document
on the non-hybrid issues "wouldn't avoid the controversy, it would just
concentrate it in one place".

That quote admitted that there was already a controversy _and_ admitted
that the controversy would be shared by a new document. It didn't admit
the level of controversy, but you've now admitted that the "significant
and details of the problems is so controversial that we have not been
able to achieve consensus".

When I point out how much this last quote is conceding, you suddenly
claim that the big controversy you're talking about (without links) is
only for a new document and _not_ for draft-ietf-tls-mldsa. But this is
contradicted by your February admission that a new document "wouldn't
avoid the controversy, it would just concentrate it in one place".

---D. J. Bernstein


===== NOTICES =====

IETF BCP 78, "Rights Contributors Provide to the IETF Trust", Section 5
(normative), "Rights in Contributions", 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.