[TLS] Violations of the individual-participants rule

["D. J. Bernstein" <[e-mail]>]

> 1) The IEEE group wants an RFC. They can advocate for this just as
> anyone else can. (yes!)

No.

An organization trying to influence IETF decisions via liaison
statements to WGs is violating the following rule from RFC 2418:
"Participation is by individual technical contributors, rather than by
formal representatives of organizations."

This rule isn't merely about who's allowed to respond to last calls.
It's about _all_ participation in a WG.

RFC 4052 encourages liaisons with other organizations "to avoid overlap
in work efforts and to manage interactions between their groups". This
doesn't authorize liaisons to violate the RFC 2418 rules.

To override the RFC 2418 rule that prohibits organizations as WG
participants, RFC 4052 would have to say that it's overriding this rule,
_and_ would have to list itself as updating RFC 2418. RFC 4052 doesn't
do any of that.

As motivation for requiring WG participation to be by individuals, see
https://www.ietf.org/support-us/endowment/ saying that anyone "can
participate in an individual capacity" so "participants cannot exert
influence as they could in a pay-to-play organization where members,
companies, or governments pay fees to set the direction".

The type of influence that isn't supposed to be possible is perfectly
illustrated by the discussion at hand, which has featured extended
commentary on what a particular organization, a new IEEE WG, supposedly
wants from the TLS WG.

This input should never have been allowed in the first place. But, given
that it did appear, I agree with some previous comments that it's
important to be clear about the events that led to it. The following
description includes events pointed out in previous TLS WG email and
further events that I've investigated.

Rewinding to February: The IETF TLS chairs issued another "last call"
regarding issuance of this spec as an RFC. In response to the "last
call", 22 people spoke up in opposition, and 21 people spoke up in
support. See https://blog.cr.yp.to/20260405-votes.html for names,
quotes, and links. This is obviously _very_ far from consensus.

The chairs have not admitted the level of opposition. Instead they have
claimed that, to determine whether there's rough consensus, they'll need
to run yet another WGLC after document tweaks regarding "key reuse" and
"text for preferring hybrids" and "motivations".

Anyone who simply reads the statements of opposition sees that, no, only
a small fraction of those statements (such as John Mattsson's) will be
affected by these tweaks. The remaining statements of opposition are
more fundamental. The spec should simply be removed from the WG pile,
but, obviously, hasn't been removed.

I think it's useful to put my attack hat on for one paragraph here to
illustrate the sort of sabotage that well-designed procedures protect
against. If I were an attacker trying to change the results for this
spec, then I would try to fool and/or intimidate opponents into not
speaking up during the next WGLC, for example by claiming that the
chairs will still count their previous objections (despite not having
counted them in the first place!) and claiming that objecting again is
inappropriate. I would also try to generate more support statements for
the spec. The point is to have less of a voice for the public interest
in security, both in absolute terms and relative to spec proponents.

Back to the documented events: The AD (at the time) was in a 15-person
conf call on 25 February 2026. The WGLC period was almost done at that
point. Many statements of opposition had shown up, so it was clear that
there wasn't consensus, i.e., that the WGLC had failed.

According to the conf-call minutes, the conf call included the AD saying
"if IEEE 802.11bt wants pure ML-KEM, it would be helpful if they could
issue a liaison statement saying that":

    https://web.archive.org/web/20260408040241/https://datatracker.ietf.org/doc/minutes-interim-2026-ietfieee-01-202602252000/

An NSA employee was in the conf call and says that after the call he
received followup "clarification" that a statement would "do the trick"
to "help show consensus for publication during WGLC":

    https://web.archive.org/web/20260405212317/https://mentor.ieee.org/802.11/dcn/26/11-26-0652-00-00bt-ietf-request-for-pure-ml-kem-liaison.pptx

It's hard to imagine a more blatant example of what "exert influence"
means!

Presumably the "clarification" was from the same AD, but there don't
seem to be public records of this, despite the transparency rules in
Section 8 of RFC 2026. (Those rules aren't just for standards but for
any activity _related_ to standards; in particular, any AD email related
to TLS is required to be public.)

The IEEE 802.11bt email archives from last month show that Jarkko Knecht
suggested broadening the liaison statement to _any_ PQ specs (removing
the words "that use pure ML-KEM"), given that "it is important to remain
open to a range of PQC technologies rather than narrowing the focus
exclusively to pure PQC solutions":

    https://grouper.ieee.org/groups/802/11/email/stds-802-11-tgbt/msg00082.html

Dan Harkins sent two responses:

    https://grouper.ieee.org/groups/802/11/email/stds-802-11-tgbt/msg00083.html
    https://grouper.ieee.org/groups/802/11/email/stds-802-11-tgbt/msg00084.html

Part of this was saying that asking for non-hybrids is "expanding the
options available"---which would be a bizarre comment if IEEE 802.11bt
had decided that it has some sort of engineering problem using hybrids.

Meanwhile 802.11bt minutes from late last year (shortly after the group
was formed)---

    https://mentor.ieee.org/802.11/dcn/25/11-25-2259-00-00bt-tgbt-november-plenary-2025-session-minutes.docx

---indicate that an individual (not named in the minutes) was telling
802.11bt that NSA "do not allow hybrid mechanism". Sounds like the same
basic story that has been tried, so far unsuccessfully, on the TLS WG:
NSA demands non-hybrids, ergo support non-hybrids.

A more surprising aspect of

    https://grouper.ieee.org/groups/802/11/email/stds-802-11-tgbt/msg00083.html

is the following false claim: "the TLS working group ... is proposing to
define pure PQC ML-KEM ciphersuites for TLS 1.3."

The proposal is actually from some _individuals_, not from the TLS WG.
The TLS WG has _not_ endorsed the proposal. So far every TLS WGLC on
this proposal has failed to reach consensus.

The TLS WG chairs claimed that there was consensus to "adopt" the
document. That's not true: the adoption call produced 22 support
statements but also produced unanswered objections from 7 people. I'm
appealing this chair action to IAB.

Furthermore, adoption merely means putting the document on the WG's pile
of documents to work on and _maybe_ endorse. It means that the WG is
_evaluating_ something, _not_ that the WG is proposing it. As RFC 7221
notes: "adoption by a working group does not guarantee publication of
the document as an RFC". So the "TLS working group ... is proposing"
claim is wrong in any case.

Notice the circular influence game here:

    * The false claim of the TLS WG "proposing" this was presented to
      802.11bt as a reason to issue a support statement for this spec.
      
    * This 802.11bt statement was then presented to the TLS WG as
      supposedly being a reason for the TLS WG to support this spec.

Readers in each group are given the impression that the other group is
already supporting the spec (not true), and that this support is on
engineering grounds (all available evidence says no). Sending an
_organization_ statement to the TLS WG had the effect of burying the
actual motivation for that statement---an AD telling NSA that the
statement would "do the trick" to "help show consensus"---and making it
far too easy for readers to presume an engineering motivation.

The influence that this statement has had on TLS WG discussions is
divorced from IETF is supposed to work. WG participants are required to
be individuals, not organizations. IETF says that it makes decisions on
engineering grounds, not on political grounds. "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."

If the people who produced the statement would like to try to make an
engineering argument to convince opponents that this spec is the best
solution for the whole Internet, they're of course free to speak up as
individual TLS WG participants to make this case. But RFC 2418 doesn't
allow _organizations_ a voice in the WG.

---D. J. Bernstein


===== NOTICES =====

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. (That
sentence is 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". I'm fine with redistribution of
copies of this document; the issue is with modification. Legend language
also appears in, e.g., RFC 5831. For further background on the relevant
IETF rules, see https://cr.yp.to/2025/20251024-rules.pdf.)