The cr.yp.to blog

2026.07.02: A standard by any other name: How IETF evades responsibility for its actions. #standards #doublespeak

IETF prominently advertises itself as "the premier standards development organization (SDO) for the Internet". The dictionary says that a "standard" is "something set up and established by authority as a rule for the measure of quantity, weight, extent, value, or quality"; IETF is an authority issuing rules for measuring the quality of various components of the Internet.

IETF says it "publishes its technical documentation as RFCs". Every RFC issued by every IETF working group (after final approval by a small central committee) is labeled as "consensus of the IETF community". Corporate purchasing managers understand "RFC" to mean "Internet standard". Cisco sends around 100 people to every IETF meeting, plus endless email messages between meetings, all aimed at influencing what ends up in RFCs. Cisco is just one Internet company.

But then IETF plays wording games to evade responsibility for the damage caused by any particular RFC. IETF labels only 1% of its standards as "Internet standards", mostly older ones basically locked into stone at this point, and about 0% of Cisco's IETF activity is aimed at influencing those. The rest are just "proposed standards" or "informational" or some similar weaseling.

Let's look at a concrete example of why this evasion matters. The events I'll describe are part of a vote on an explicitly NSA-driven effort for IETF's TLS working group to issue an RFC extending the TLS 1.3 standard to allow solo ML-KEM as an alternative to the common-sense, widely deployed ECC+ML-KEM. These are current events, a vote that's still happening right now: you can join and cast your own vote through 7 July 2026. If the vote passes then NSA will keep waving around money to pressure more and more companies to switch to this option in IETF's TLS standard.

The status right now is that the specification of solo ML-KEM in TLS is an unapproved draft. Proponents continually argue that it's important for IETF to turn this draft into an RFC. For example, here are quotes from two supporting votes from NSA's partner GCHQ:

• Peter Campbell writes "I support publication as an RFC. An Internet Draft with codepoints is not sufficient as most SDOs (including the IETF) won't allow their standards to cite I-Ds normatively".

• Florence Driscoll writes "We would also like to be able to recommend use of RFCs rather than draft standards in operational systems, as this is clear and consistent for those reading our guidance. As such, I am in favour of this document being published as an RFC".

"SDOs" in the first quote means "standards-development organizations". Here's what it means for document X to cite document Y "normatively": part of following the X rules is following the Y rules; if an authority (e.g., IETF or another SDO) is telling you to follow the X rules then the authority is also telling you to follow the Y rules; in other words, if X is a standard then Y is a standard too.

The second quote is accurately describing the current document as a "draft standard" and is accurately describing an RFC as an upgrade from that. An RFC would be a standard. An RFC would be adding IETF's authority to the notion that it's acceptable to use solo ML-KEM.

People objecting to IETF issuance of this security-damaging document as an RFC often accurately express this as objecting to standardization. But then proponents suddenly switch to hyping IETF's deceptive labels. It's not a "standard"! It's not on the IETF "standards track"! It's just "Informational"! There's this buried note in Section 6 saying "Recommended: N"! And, by the way, TLS 1.3 isn't actually a standard; it's just a "proposed" standard! IETF is the premier not-standards development organization for the Internet!

For example, the same Peter Campbell from GCHQ who wrote "I support publication as an RFC. An Internet Draft with codepoints is not sufficient as most SDOs (including the IETF) won't allow their standards to cite I-Ds normatively" responded to an objection by writing "Good news! While draft-ietf-tls-ecdhe-mlkem is standards track, draft-ietf-tls-mlkem is not. Its intended status is Informational."

Praise the influence of an RFC when you're voting in favor of issuing the RFC, and then flip to denying the influence of the same RFC in response to people objecting to issuing that RFC? C'mon, you can't have it both ways. How many objections have been deterred by these denials?

The reality is that if this document is issued by IETF as an RFC then it's a standard, "something set up and established by authority as a rule for the measure of quantity, weight, extent, value, or quality"; concretely, it's an IETF rule saying that rolling out ML-KEM without ECC has acceptable quality. A corporate purchasing manager will accurately understand the RFC as a standard, and won't even see, let alone care about, labels such as "Informational" or "Recommended: N".

NSA contractor Eric Rescorla has admitted that what's controversial here is the endorsement conveyed by the issuance of an RFC, even an "informational" non-"recommended" RFC: "I think it's clear that many regard the publication of an RFC by the TLS WG as a form of endorsement, even when Recommended=N [0]. In fact, this is precisely why the publication of some documents has become so controversial. ... [0] I don't think this position is entirely unreasonable given that the documents state on the face of them that they 'represent[s] the consensus of the IETF community.' "