My last blog post for today is an example of IETF management censoring dissent.
The IETF TLS working-group chairs issued "last call" on 5 November 2025 for objections to a particular document, the same controversial NSA-driven document that was also the topic of my earlier posts today, as if still-unresolved objections hadn't already been raised before that. The deadline for objections is 26 November 2025.
During this limited-time "last call" for objections. IETF management has censored a new objection that I've raised to this document. It's fascinating to compare this to IETF's claim to be "open to all interested individuals"; to IETF's claim that "decision-making requires achieving broad consensus via these public processes"; and to the legal requirement of openness.
Specifically, I was thinking about a point that had very briefly come up earlier, and I realized that it's actually a powerful objection to this document. Each WG has a charter, which according to IETF rules is a "contract between a working group and the IETF to perform a set of tasks". Groups can be rechartered, but chairs and other document proponents don't have authority to do this unilaterally; they have to stick to the charter unless and until it changes. In the case of the TLS WG, standardizing PQ in TLS turns out to be violating the TLS WG charter.
I wrote up the details and sent this objection to the TLS mailing list more than 24 hours ago. The objection still hasn't appeared on the mailing list. As I'll explain below, it's clear why it hasn't appeared: as a technological matter, the WG chairs have power to set up filters, and did so to stop my messages from promptly appearing on the list. It's also clear that the chairs violated applicable IETF policy by blocking this message.
The message. First, here's the text I sent that still hasn't appeared on the mailing list. I used the specified recipient list for objections ("draft-ietf-tls-mlkem@ietf.org, tls-chairs@ietf.org, tls@ietf.org"), and the specified subject line ("Re: [TLS] WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)").
Contrary to what readers would expect from a "last call" for objections,
several people (including me) had already filed earlier objections that
haven't been resolved.
It shouldn't be necessary to repeat the objections, but Thomas Bellebaum
promptly replied to the "last call" by highlighting various objections.
That was on the 6th, more than two weeks ago. I've seen no response.
The rest of this message focuses on a different objection, which is that
this document is out of scope for the WG. This document doesn't serve
any of the official goals in the TLS WG charter. Most importantly, this
document is directly contrary to the "improve security" goal, so it
would violate the charter even if it contributed to another goal.
Specifically, the charter
https://web.archive.org/web/20251011020257/https://datatracker.ietf.org/wg/tls/about/
sets three goals for the WG: to improve applicability to "emerging
protocols and use cases"; to "improve security, privacy, and
deployability"; and to maintain the protocol, for example by specifying
general best practices.
TLS is already moving forward with ECC+PQ. This document instead removes
the ECC seatbelt. This will create unnecessary damage if the PQ choice
is broken. Half of the PQ proposals submitted to NIST in 2017 have been
broken already (for details see https://cr.yp.to/papers.html#qrcsp),
often with attacks having sufficiently low cost to demonstrate on
readily available computer equipment. Further PQ software has been
broken by implementation issues such as side-channel attacks (see, e.g.,
https://cr.yp.to/papers.html#kyberslash).
This document is thus directly contrary to the "improve security" goal
in the charter, a goal that one would imagine has very high weight for a
WG on "Transport Layer Security".
There are situations where one can argue that incurring a security risk
is justified by a different goal in the charter---such as deployability,
which is a prerequisite for security. But weakening ECC+PQ to just PQ
isn't enabling deployment.
The main cost of ECC+PQ (see https://blog.cr.yp.to/20240102-hybrid.html
for concrete numbers) is PQ network traffic, not ECC network traffic or
ECC computation. The cost difference between ECC+PQ and PQ is even less
noticeable in the context of overall application costs: for example,
Meta reports spending only 1/2000 of its CPU cycles on X25519, the
dominant ECC choice.
Furthermore, the PQ option isn't in a vacuum: it's an _extra_ option on
top of the existing ECC+PQ. This makes TLS _harder_ to implement, yet
another obstacle to software competition. This _damages_ deployability.
The WG's "use cases" goal allows "protocol changes that reduce TLS
resource consumption without affecting security". That's not the
situation at hand. This document isn't making a security-preserving
protocol change: it's incurring unnecessary security risks by adding new
"groups" that throw away common-sense seatbelts. Furthermore, the change
in resource consumption is so minor that it can't possibly outweigh the
"improve security" goal in the charter.
This document also doesn't fit any of the maintenance subgoals in the
charter. It isn't specifying "general best practices for use of (D)TLS,
extensions to (D)TLS, and cipher suites"; in particular, it's far away
from best practices for cipher suites. The proposal to mark the document
as D wouldn't make the document fit the "when a particular version
should be deprecated" part of the charter: that's about TLS (or DTLS)
versions, not about more specific options.
The document was introduced in pursuit of "CNSA 2.0 compliance", which
can be viewed as a different type of deployability argument:
https://web.archive.org/web/20250613195524/https://mailarchive.ietf.org/arch/msg/tls/qFRxBSnEPJcdlt7MO0cIL2kW5qc/
This seems echoed by unofficial comments from NSA employees, such as a
comment that NSA is "looking for products that support /standalone/
ML-DSA-87 and /standalone/ ML-KEM-1024. If there is one vendor that
produces one product that complies, then that is the product that goes
on the compliance list and is approved for use. Our interactions with
vendors suggests that this won't be a problem in most cases":
https://web.archive.org/web/20250613195524/https://mailarchive.ietf.org/arch/msg/spasm/xUKIoHQwm1BjNZWS2x3xb-BhsLI/
However, NSA has issued various official documents, such as
https://web.archive.org/web/20250827175413/https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF
from this year, saying that "hybrid solutions may be allowed or required
due to protocol standards".
If the TLS WG simply holds the line and refuses to standardize
non-hybrid PQ, then NSA's TLS purchasing will be forced to comply,
destroying this deployability argument.
What if, hypothetically, NSA suddenly issues a new official document
saying that it _won't_ obey IETF's TLS standards? The resulting "NSA
demands it, therefore supporting it improves deployability" argument
would still fail to outweigh the damage done to the "improve security"
goal in the charter.
We have already seen many examples where options added because of NSA
pressure continued causing security problems for many years. See, e.g.,
https://publish.illinois.edu/science-of-security-lablet/files/2016/08/10062016-Heninger-Slides.pdf
or Dual EC. TLS 1.3 did better by going beyond removing known failures:
it also tried to proactively eliminate unnecessary risks, for example by
asking for security proofs and, more to the point, taking steps to
remove unnecessary options. Adding new options because of NSA pressure
would be going back to the dark ages where "improve security" was merely
removing known failures.
Furthermore, even if a standard has a completely clear warning saying
"This is a controversial document incurring unnecessary security risks",
most people who make purchasing decisions _won't see that warning_. All
they'll see is that there's a standard. They'll also assume that each
option has a good reason for existence---for example, that an option
providing microbenchmark wins is providing _important_ wins. If the WG
endorses this document then it's begging for bad purchasing decisions.
That's again contrary to the "improve security" goal in the charter.
Finally, given that "Fundamentally, 'IETF participants use their best
engineering judgment to find the best solution for the whole Internet,
not just the best solution for any particular network, technology,
vendor, or user.' ", the "deployability" wording in the charter has to
be understood as deployability for the whole Internet, not just what
NSA claims is the solution it wants.
The filtering. Why am I saying that the chairs targeted my messages with a filter? Because they admitted it. On 17 October 2025, they posted a "Notice of Moderation for Postings by D. J. Bernstein" saying that they would "moderate the postings of D. J. Bernstein for 30 days due to disruptive behavior effective immediately" and specifically that my postings "will be held for moderation and after confirmation by the TLS Chairs of being on topic and not disruptive, will be released to the list".
Do IETF procedures allow WG chairs to censor a participant for unspecified "disruptive behavior"? No. The procedures cited by the chairs, RFC 3934, do allow censorship by chairs, but only for behavior that the chairs claim is "disruptive to the WG process". There has been no such claim, nor would such a claim be defensible.
The IETF WG procedures say that conflicts "must be resolved by a process of open review and discussion". Filing objections is following this process, not disrupting it. Sure, NSA is unhappy whenever any of its efforts to sabotage standards are disrupted, but RFC 3934 doesn't allow chairs to retaliate for that.
The chairs cited an ad-hominem attack that the chairs had issued in 2024. Specifically, the chairs claimed in 2024 that I "continue to violate list policy with unprofessional commentary on other participants' motivations" (not true) and "repeatedly raising points that are out of scope" (the context indicates that this was a new claim that antitrust-law issues are out of scope for the TLS mailing list, so I simply stopped raising antitrust-law issues on that list). They didn't claim back then that I was disrupting the WG process, nor did they obey RFC 3934 asking them to communicate privately before issuing public warnings, nor have they claimed that anything else I've sent to the list is out of scope, nor have they claimed now that I'm disrupting the WG process.
More importantly, RFC 3934 has the following clear rule: "This mechanism does not permit WG chairs to suspend an individual's posting privileges for a period longer than 30 days regardless of the type or severity of the disruptive incident." It's clear that the chairs have violated this rule. (This rule is part of what's disappearing as part of IETF management expanding its censorship authorities, but at this instant the rule is still there.)
I didn't send anything to the IETF TLS mailing list for 30 days after that. Yesterday I finished writing up my new objection and sent that in. And, gee, after more than 24 hours it still hasn't appeared. Another message to the TLS mailing list appeared in the meantime with negligible delay after its sending date. Something I sent to another IETF list appeared promptly. IETF's mailing lists have length limits, but this message is shorter than other messages that have appeared promptly.
Presumably the chairs "forgot" to flip the censorship button off after 30 days. Oh, yes, I'm sure they're so sorry for this accidental violation of the rules, a violation that just happens to prevent a new objection from showing up on list for other WG participants to consider during the limited-time last-call period. This has nothing to do with the NSA money. Move along now.