NSA en IETF, deel 9: Een update

In juni zag ik dat de NSA en haar handlangers een stemming binnen de IETF hadden geforceerd om een specificatie te standaardiseren die beschrijft hoe de "ECC-veiligheidsgordel" kan worden verwijderd uit hybride ECC+ML-KEM in TLS.

Een voorbeeld hiervan is dat een van de stemmen voor de specificatie afkomstig was van Mike Jenkins van de NSA, die tot dan toe nog nooit een e-mail naar de TLS-mailinglijst had gestuurd. Ik reageerde door vrijwilligers op te roepen om vanuit het publieke belang hun stem te laten horen.

Ik kan met genoegen melden dat 82 personen op de TLS-mailinglijst tijdens de stemperiode onambigüeel hun oppositie tegen deze specificatie hebben uitgesproken. Er waren ook anderen (bijvoorbeeld Izzy Grosof en Ivan Visconti) die hun verzet al vóór de stemperiode hadden geregistreerd. Ik heb geloofwaardige rapporten ontvangen dat verdere oppositieberichten door de voorzitters zijn geblokkeerd.

Ook was het goed om de volgende verklaring van Roberto Avanzi te zien:

"Als mede-ontwerper van ML-KEM zou ik het zelf niet vertrouwen om het exclusief te gebruiken: wat als het wiskundig wordt gebroken in het klassieke computationele model (d.w.z. niet-quantum)? Hybride is beter, en de extra tijd die ECC kost is niet significant."

In tegenovergestelde richting werd ik gewezen op de volgende bewering van Thomas Ptacek:

"Hoe cryptografisch onderlegd je bent, hoe groter de kans dat je denkt dat hybriden onzinnig zijn."

Wat betreft de 82 mensen die oppositieverklaringen hebben afgelegd, zie ik voor 75 van hen geen enkele manier waarop iemand kan beargumenteren dat hun berichten ruimte laten voor wijzigingen aan de specificatie die de bezwaren zouden wegnemen. Ik heb citaten van deze 75 personen verzameld en deze, samen met mijn reacties op de argumenten van de voorstanders, doorgestuurd naar de "IESG" (Internet Engineering Steering Group).

Het vervolg van dit artikel beschrijft wat er zou moeten gebeuren, wat er tot nu toe is gebeurd en wat er waarschijnlijk zal gebeuren.

Hoe het proces zou moeten verlopen

Volgens de IETF geldt het volgende: "Deelname aan de IETF is gratis en open voor alle geïnteresseerde individuen. ... IETF-activiteiten worden uitgevoerd met extreme transparantie, in openbare fora. Besluitvorming vereist het bereiken van een brede consensus via deze openbare processen. ... Fundamenteel gebruiken IETF-deelnemers hun beste technische oordeel om de beste oplossing voor het gehele internet te vinden, en niet alleen de beste oplossing voor een specifiek netwerk, technologie, leverancier of gebruiker."

Het werk van de IETF is verdeeld over werkgroepen (WGs). Over besluitvorming binnen deze werkgroepen stelt de IETF: "De algemene regel over hoe werkgroepen beslissingen nemen, is dat de werkgroep tot een 'ruwe consensus' (rough consensus) moet komen. Dit betekent dat een zeer grote meerderheid van de betrokkenen het eens moet zijn, en dat de minderheid de kans heeft gehad om uit te leggen waarom zij het er niet mee eens zijn, en dat hun punten zijn behandeld, zelfs als men het niet met hen eens is geworden."

Er is een verdere regel die stelt dat "51% van de werkgroep niet kwalificeert als 'ruwe consensus'". Deze regel spreekt niet over "51% van een quorum". Daarnaast is er een regel dat meningsverschillen "opgelost moeten worden door een proces van open review en discussie".

Als een "last call" van een werkgroep "ruwe consensus" laat zien om een RFC (Request for Comments) uit te geven, kan de voorzitter van de werkgroep de RFC nog niet direct publiceren. In plaats daarvan stuurt de voorzitter de specificatie door naar de IESG, die vervolgens zijn eigen "last call" uitvoert. De regels bepalen dat "commentaren op een Last-Call van iedereen geaccepteerd worden".

Als de IESG besluit een RFC uit te geven, stelt de RFC dat dit "de consensus van de IETF-gemeenschap vertegenwoordigt". Als er in eerste instantie geen "ruwe consensus" is in de werkgroep — bijvoorbeeld als de specificatie geen overeenstemming heeft bereikt bij een "zeer grote meerderheid van de betrokkenen" — dan zou de specificatie niet naar de IESG gestuurd moeten worden, maar door de voorzitters van de werkgroep moeten worden afgewezen.

Bij deze specifieke specificatie hebben de voorstanders, zelfs na het "stem-vullen" door de NSA en haar leveranciers, zeker geen 51% van de werkgroep — en 51% zou nog steeds niet kwalificeren. Ze hebben zeker geen "zeer grote meerderheid" van de mensen die betrokken genoeg waren om zich uit te spreken; ze vormden niet eens de helft van de mensen die reageerden. Bovendien blijven de belangrijkste punten van de tegenstanders onbeantwoord.

Samenvattend: de "ruwe consensus" omvat een reeks vereisten waaraan de specificatie niet voldoet. De voorzitters van de werkgroep hadden dus moeten concluderen dat er geen "ruwe consensus" is om deze specificatie als RFC uit te geven.

Wat er in werkelijkheid is gebeurd

De voorzitters hebben de regels genegeerd en "ruwe consensus" verklaard om deze specificatie als RFC uit te geven. Hier zijn enkele van de wisselende argumenten die zij hiervoor hebben opgevoerd:

  • Verhaal 1: "Als we kijken naar bestaande WG-deelnemers of mensen met bewezen expertise, is ongeveer 7/10 WG-deelnemers voor het voortzetten van het document, wat duidt op ruwe consensus." (Wie bepaalt wie "bewezen expertise" heeft? Wat gebeurde er met het principe dat deelname open is voor iedereen en dat besluitvorming via openbare processen verloopt?)
  • Verhaal 2: De voorzitters "richtten hun consensusoordeel op mensen die al deelnamen aan TLS vóór de laatste WGLC." (Waarom tellen nieuwe deelnemers met expertise plotseling niet meer mee? Wie geeft voorzitters het recht om nieuwe deelnemers uit te sluiten ten gunste van bestaande leden?)
  • Verhaal 3: "Consensus wordt bepaald door de kwaliteit en resolutie van technische argumenten te beoordelen, in plaats van door simpele aantallen." (Wat gebeurde er met de bewering dat 7/10 deelnemers voor waren? Dan gebruikten de voorzitters juist wel aantallen!)

Toen de voorzitters de stemming initieerden, vroegen ze deelnemers om aan te geven "of ze het steunen om een document te publiceren dat een stand-alone ML-KEM specificeert" en vroegen ze hen om "verdere discussie over dit onderwerp achterwege te laten". Wanneer mensen toch in discussie gingen, stuurden de voorzitters berichten als: "NOG MAALS!!!! Laten we ons houden aan de consensus-call, 'ik steun' of 'ik steun niet', zoals gevraagd in de e-mail die deze thread begon."

Het is dan ook verbazingwekkend dat de voorzitters achteraf beweren dat "een consensus-call geen stemming is" en dat mensen in plaats daarvan technische argumenten hadden moeten aanleveren voor een kwalitatieve evaluatie door de voorzitters.

Ondanks dat de voorzitters mensen vertelden om simpelweg te stemmen en stil te zijn, bevatten veel oppositieverklaringen wel degelijk technische argumenten. De voorzitters hebben geen evaluatie van deze argumenten gepubliceerd. In plaats daarvan ontweken ze de argumenten door te claimen dat:

  1. Een aanbevolen status van 'N' in het IANA-register "duidelijk aangeeft dat de hybride aanpak door de werkgroep wordt aanbevolen boven de pure aanpak".
  2. "Fundamenteel is de keuze of men pure ML-KEM gebruikt een inschatting die mensen voor zichzelf moeten maken."

Dit schendt de regel dat IETF-deelnemers hun beste technische oordeel gebruiken om de beste oplossing voor het gehele internet te vinden, en niet alleen de beste oplossing voor een specifieke gebruiker of leverancier. Bovendien horen voorzitters geen actie te ondernemen op basis van hun eigen visie dat de specificatie "oké" is; zij horen te evalueren of er "ruwe consensus" is.

De voorzitters hebben de specificatie op 28 juli 2026 namens de TLS-werkgroep naar de IESG gestuurd. De IESG stuurde op 30 juli 2026 een "last call" uit, gebaseerd op het feit dat zij een verzoek hadden ontvangen van de TLS WG.

Op geen enkel moment hebben de voorzitters toegegeven hoeveel mensen bezwaar hebben gemaakt. Mensen die kijken naar wat de voorzitters hoger in de boom hebben gerapporteerd, zullen de meeste bezwaren niet zien en beseffen mogelijk niet hoe controversieel deze specificatie is. De voorzitters schetsen een beeld van een uiteenvallende oppositie, maar dat is simpelweg niet waar. Het aantal tegenstanders is in elke stemronde toegenomen. Hoewel drie mensen met specifieke bezwaren (Stephen Farrell, John Mattsson, Muhammad Usama Sardar) hun bezwaren hebben ingetrokken, hebben veel meer mensen ontdekt wat er aan de hand was en zich tegen de specificatie uitgesproken.

Wat er waarschijnlijk zal gebeuren: Belangenverstrengeling en geldstromen

Ik zou graag willen denken dat de IESG naar de oppositieverklaringen van 75 personen kijkt en concludeert dat er geen consensus is en dat de specificatie afgewezen moet worden. Ook zou ik willen denken dat de IESG inziet dat deze specificatie in strijd is met het beveiligingsdoel in het TLS WG-handvest en daarom afgewezen moet worden als een schending van het handvest.

Maar de realiteit is dat mensen vaak doen waarvoor ze betaald worden. Laten we kijken naar de geldstromen. Ik heb eerder citaten gepubliceerd die laten zien hoe de NSA druk uitoefent op haar "leveranciers". Een Cisco-medewerker schreef bijvoorbeeld: "dat is wat ze bereid zijn te kopen. Daarom zal Cisco het implementeren"; en een NSA-medewerker schreef: "Onze interacties met leveranciers suggereren dat dit in de meeste gevallen geen probleem zal zijn."

Kijk nu naar de leden van de IESG:

  • Cisco-medewerkers: Charles Eckel, Eric Vyncke, Ketan Talaulikar.
  • SEI-medewerkers: Roman Danyliw (IESG-voorzitter) en Christopher Inacio. (SEI wordt gefinancierd door het Amerikaanse Ministerie van Oorlog en is een federale R&D-instelling, in feite een dochteronderneming van de Amerikaanse defensie).
  • Akamai-medewerker: Mike Bishop. (Akamai is de enige leverancier van de Global Content Delivery Service aan de Defense Information Systems Agency).
  • Cloudflare-medewerker: Tommy Jensen. (Cloudflare heeft in maart 2026 deelname aangekondigd aan een contract met de Missile Defense Agency met een plafond van $151 miljard).
  • Nokia-medewerker: Gunter Van de Velde. (Nokia heeft eveneens deelgenomen aan het bovengenoemde MDA-contract).
  • NSA-veteraan: Deb Cooley. Zij beweert dat haar pensioen het belangenconflict heeft opgeheven, maar dit is precies waar "draaideur"-verboden tegen bedoeld zijn.

Van de 14 IESG-leden heb ik er zojuist 9 genoemd.

Stel dat de IESG een excuus verzint om de specificatie toch goed te keuren. Wat dan? Er zijn procedures om de beslissing van de WG-voorzitters aan te vechten: eerst bij Deb Cooley (NSA), dan bij de volledige IESG, en dan bij de "Internet Architecture Board" (IAB). Bij de IAB zijn medewerkers van defensiecontractanten (SEI, Cisco, Cloudflare, Nokia, Google, Comcast, Zscaler) wederom in de meerderheid.

De anti-corruptieorganisatie Transparency International heeft een handleiding voor procedures die organisaties zouden moeten opzetten om klachten te behandelen. De IETF volgt geen van deze richtlijnen en heeft geen procedurele beperkingen over hoe beroepen worden afgehandeld. Het zou niet verbazen als er een RFC wordt uitgegeven voordat de beroepen zijn afgehandeld, simpelweg om te voorkomen dat een RFC weer moet worden ingetrokken.

De laatste stap: Het bestuur van de Internet Society

Het laatste niveau van beroep binnen de IETF-procedures is een klacht indienen bij de Board of Trustees van de Internet Society (ISOC), de moederorganisatie van de IETF, over het feit dat de IETF-procedures "ontoereikend of onvoldoende zijn voor de bescherming van de rechten van alle partijen in een eerlijk en open Internet Standards Process".

Ik heb in december 2025 al een klacht ingediend bij ISOC. ISOC liet weten dat de afhandeling hiervan besproken zou worden tijdens hun vergadering van 25-26 juli 2026 en dat het bestuur iemand zou aanwijzen om contact met mij op te nemen.

Misschien wijzen ze bestuurslid Russ Housley aan. Hij is zeer bekend met de situatie:

  • Hij heeft drie keer gestemd om deze specificatie als RFC uit te geven.
  • Hij was oorspronkelijk werkzaam voor de Air Force en is nu president van Akayla, een klein consultancybureau dat sinds 2023 voor $210.000 aan militaire contracten heeft ontvangen.
  • Peter Yee, een van de zes NSA-medewerkers die in de laatste ronde voor de specificatie stemden, werkt naast de NSA ook voor Akayla.
  • Sean Turner, een van de TLS WG-voorzitters, is de penningmeester, secretaris en security officer van Akayla.
  • De andere TLS WG-voorzitter (en auteur van de specificatie) is een werknemer van Sandbox AQ, dat gefinancierd wordt door de CIA.

Housley was van 2003 tot 2007 IETF Security Area Director, van 2007 tot 2013 IETF Chair, en van 2007 tot 2017 IAB-lid. Hij weet dus precies hoe de IETF werkt.

Het lijkt erop dat hij de perfecte man is op de perfecte positie om ervoor te zorgen dat de IETF-procedures doen wat ze zouden moeten doen. Laten we zien wat er gebeurt!