[Last-Call] Re: [TLS] Re: Re: Last Call: <draft-ietf-tls-mldsa-03.txt> (Use of ML-DSA in TLS 1.3) to Informational RFC

[Bron Gondwana <[e-mail]>]

With my last-call mailing list moderator hat on. (removed CC: the tls list, which I don't moderate)

Dan, this is an explicit warning that making accusations about people's motivations is not acceptable on the last-call mailing list (see RFC 7154 section 2).

Further, you have an open appeal to the IESG for the process question that you raise here.  It is not appropriate for the last-call list to re-litigate the same issue while that appeal is under consideration.

Multiple people have flagged that I should have done this earlier; I should have.  If you make another post attributing bad faith or dishonesty to other IETF participants, I will place your emails into moderation and reject any further emails which continue this pattern of behaviour.

Regards,

Bron.

On Sat, May 23, 2026, at 08:36, D. J. Bernstein wrote:
> 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.
> 
> -- 
> last-call mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 

--
  Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC
  [e-mail]