{"slug": "nsa-and-ietf-part-9", "title": "NSA and IETF, Part 9", "summary": "In an IETF vote on standardizing the removal of ECC from hybrid ECC+ML-KEM in TLS, 82 people spoke in unambiguous opposition during the voting period, according to a blog post by cryptographer Daniel J. Bernstein. Bernstein forwarded quotes from 75 of those opponents to the Internet Engineering Steering Group (IESG), along with his replies to spec proponents' talking points, amid concerns about NSA influence and the weakening of cryptographic standards.", "body_md": "Back in June,\nI saw that NSA and its minions\n[had called and were packing](20260706-fairness.html)\nan IETF vote on\n[standardizing](20260702-standard.html)\na specification of how to\n[remove the ECC seatbelt](20251004-weakened.html)\nfrom hybrid ECC+ML-KEM in TLS.\nFor example,\none vote for the spec was from\n[NSA's Mike Jenkins](https://web.archive.org/web/20260720022608/https://mailarchive.ietf.org/arch/msg/tls/XIckyKVIEgKNus-koXOLooFpU54/),\nwho had never sent email to the TLS mailing list before.\nI responded by\n[calling for volunteers](https://nsa.2026.action.cr.yp.to)\nto speak up on the public-interest side.\n\nI'm happy to report that 82 people spoke up\non the TLS mailing list in unambiguous opposition to this spec\nduring the voting period.\nThere were also some additional people\n([Izzy Grosof](https://web.archive.org/web/20260814174711/https://mailarchive.ietf.org/arch/msg/tls/ACw9YLxCqSQUOXUnw_4lbuqeuGw/),\nfor example, and\n[Ivan Visconti](https://web.archive.org/web/20260719032953/https://mailarchive.ietf.org/arch/msg/tls/Cr3JZMPFGyVDHOI8c0ZASXxDtdY/))\nwho had already registered opposition before the voting period;\nI've heard credible reports of further opposition messages being blocked by the chairs;\nand, even though this wasn't filed as opposition,\nit was good to see the following\n[statement](https://web.archive.org/web/20260710230832/https://www.linkedin.com/posts/billatnapier_the-debate-around-hybrid-key-exchange-ecdh-activity-7480546081622196225-aldO)\nfrom Roberto Avanzi:\n\"as a\ncodesigner of ML-KEM myself I would not trust using it exclusively: what\nif it gets broken mathematically and in the classical computational\nmodel (I.e. non-quantum)? Hybrid is better, and the additional time used\nby ECC is not significant.\"\n\n(In the opposite direction,\nI've been pointed to the following claim from Thomas Ptacek:\n[\"The more cryptography-literate you are, the more likely it is you think hybrids are silly.\"](https://web.archive.org/web/20260814085741/https://news.ycombinator.com/item?id=48813239)\nOh, well, I guess that settles it then.)\n\nFor 75 of the 82 people with opposition statements on the list during this voting period,\nI see no way that anyone can even try arguing\nthat anything in their messages suggests the possibility of spec modifications removing the objections.\nI've taken quotes from those 75 people\nand forwarded them to \"IESG\", the Internet Engineering Steering Group,\nalong with my replies to talking points from spec proponents.\nCopies of my messages to IESG:\n[1](https://archive.cr.yp.to/2026-08-11/11:07:06/Py4B3LXgfQLJ5t3FqOWOuU8VGh7uZdCw98eLOzBWFpE/https/mailarchive.ietf.org/arch/msg/tls/g-oB-wLzxRO9VCrX1FPHQxVEfBE/),\n[2](https://archive.cr.yp.to/2026-08-11/11:07:17/PjAcoRVE3bZ26cFIfUYAM3kPKB0L7kdewHiJPD6U1vQ/https/mailarchive.ietf.org/arch/msg/tls/y8SB0h1D7IU1MD1ZQHpLuVJSm-g/),\n[3](https://archive.cr.yp.to/2026-08-11/11:07:28/dwRWTT0R3MycM7ejMvdh1D4VAqn-0VjpVihZjrY_Dw4/https/mailarchive.ietf.org/arch/msg/tls/0yf-y5TdzghP8F9j3hlNoSV20jc/),\n[4](https://archive.cr.yp.to/2026-08-11/11:07:40/4yNdY1U1i454phk2p_xUgbLI1ro7kCDgeu2DVmuCDc8/https/mailarchive.ietf.org/arch/msg/tls/yw4jeDTFmcHdWDehavATABn8pio/).\n\nThe rest of this blog post says what's supposed to happen, what has happened so far, and what's likely to happen next.\n\nHere's what IETF\n[says](https://web.archive.org/web/20260719124332/https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/):\n\"IETF participation is free and open to all interested individuals. ...\nIETF activities are conducted with extreme transparency, in public forums.\nDecision-making requires achieving broad consensus via these public processes. ...\nFundamentally, 'IETF participants use their best engineering judgment\nto find the best solution for the whole Internet,\nnot just the best solution for any particular network, technology, vendor, or user.' \"\n\nIETF work is divided across \"working groups\" (WGs).\nHere's what IETF\n[says](https://web.archive.org/web/20260704221723/https://www.ietf.org/process/wgs/)\nabout WG decisions:\n\"The general rule on how Working Groups make decisions\nis that the Working Group has to come to 'rough consensus',\nmeaning that a very large majority of those who care must agree,\nand that those in the minority have had a chance to explain why\nand their points have been addressed, even if they were not agreed with.\"\n\nThere's a further rule that\n[\"51% of the working group does not qualify as 'rough consensus' \"](https://web.archive.org/web/20260722091830/https://www.rfc-editor.org/rfc/rfc2418.html).\nThis rule doesn't say \"51% of a quorum\".\nAlso, there's a rule that disagreements\n[\"must be resolved by a process of open review and discussion\"](https://web.archive.org/web/20260722091830/https://www.rfc-editor.org/rfc/rfc2418.html).\n\nIf a WG \"last call\" shows \"rough consensus\" to issue an RFC,\nthe WG chair still can't issue the RFC directly.\nInstead the WG chair forwards the spec to IESG,\nwhich issues its own \"last call\".\nThe rules say that\n[\"Comments on a Last-Call shall be accepted from anyone\"](https://web.archive.org/web/20260810221550/https://www.rfc-editor.org/rfc/rfc2026.html).\nIf IESG decides to issue an RFC,\nthe RFC says that it \"represents the consensus of the IETF community\".\n\nIf there isn't \"rough consensus\" in the WG in the first place—for example, if the spec hasn't reached agreement of \"a very large majority of those who care\"—then the spec isn't supposed to be sent to IESG; it's supposed to be rejected by the WG chairs.\n\nFor this particular spec,\neven after the vote-packing by NSA and its \"vendors\",\nproponents certainly don't have 51% of the working group—and 51% still wouldn't qualify.\nProponents certainly don't have \"a very large majority\" of the people who cared enough to speak up;\nthey weren't even half of the people who spoke up.\nFurthermore, the most important points from opponents remain\n[unaddressed](https://blog.cr.yp.to/20260221-structure.html).\n\nTo summarize, \"rough consensus\" includes a bunch of requirements that the spec doesn't meet. So the WG chairs were supposed to say: sorry, there isn't \"rough consensus\" to issue this spec as an RFC.\n\nThe chairs ignored the rules and declared \"rough consensus\" to issue this spec as an RFC. Here are some of the shifting rationales they've presented for this so far:\n\n[Story 1](https://web.archive.org/web/20260723121223/https://mailarchive.ietf.org/arch/msg/tls/tPe7m_vpmDco43588yVW3JWrb8U/):\n\"if we look at pre-existing WG participants or people with demonstrated expertise,\nroughly 7/10 WG participants favor advancing the document,\nwhich shows rough consensus to move the document forward\".\n(Where's the list of people that the chairs declare haven't \"demonstrated expertise\"?\nWhat happened to \"IETF participation is free and open to all interested individuals\"?\nWhat happened to \"Decision-making requires achieving broad consensus via these public processes\"?\nWhat happened to reaching agreement of \"a very large majority of those who care\"?)\n\n[Story 2](https://web.archive.org/web/20260729142704/https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/shepherdwriteup/):\nthe chairs \"focused their consensus judgement on people that participated in TLS prior to the last WGLC\".\n(Wait, so new participants with \"demonstrated expertise\" suddenly *don't* count any more?\nAnd what gives chairs the right to disenfranchise new participants in favor of pre-existing participants?)\n\n[Story 3](https://web.archive.org/web/20260810164318/https://mailarchive.ietf.org/arch/msg/tls/ckh4S8usKpKrp_Ai12xAAJzdHQs/):\n\"Consensus is determined by assessing the quality and resolution of technical arguments rather than by simple counts\".\n(Wait, what happened to\n\"roughly 7/10 WG participants favor advancing the document,\nwhich shows rough consensus to move the document forward\"?\nSounds like the chairs were using counts a moment ago!)\n\nWhen the chairs called their vote in the first place,\nthey asked WG participants to say\n\"whether you support publishing a document specifying a stand alone ML-KEM\"—and to\n[\"refrain from further discussion on this topic\"](http://web.archive.org/web/20260720015725/https://mailarchive.ietf.org/arch/msg/tls/ol2otAvtdDrdz_xY0_eKcuY1om0/).\nWhen some people engaged in discussion anyway,\nthe chairs sent messages such as the following:\n[\"AGAIN!!!! Let's stick to the consensus call, 'I support' or do 'I do not support' as was requested in the email that began this thread.\"](https://web.archive.org/web/20260701193845/https://mailarchive.ietf.org/arch/msg/tls/7l8RfNfdCABM0HYpGrbx-Eja5p0/)\nSo it's amazing to see the chairs retroactively claiming that\n[\"a consensus call is not a vote\"](https://web.archive.org/web/20260721143439/https://mailarchive.ietf.org/arch/msg/tls/RLDcZHHbCUZRgmmWbP1j2dDQhAQ/)\nand that people were instead supposed to provide technical arguments for quality evaluation by the chairs.\n\nDespite the chairs saying just shut up and vote,\nmany opposition statements *did* lay out technical arguments against this spec.\nThe chairs didn't post an evaluation of those arguments.\nInstead the chairs\n[dodged the arguments](https://web.archive.org/web/20260729142704/https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/shepherdwriteup/)\nby claiming that\n\"a recommended status of 'N' in the IANA registry ...\nclearly indicates that hybrid approach is recommended over the pure approach by the working group\"\nand that\n\"Fundamentally whether or not to use pure ML-KEM is a judgement call people have to make for themselves\".\nNotice that this violates\n\"IETF participants use their best engineering judgment\nto find the best solution for the whole Internet,\nnot just the best solution for any particular network, technology, vendor, or user\".\n\nMore to the point, the chairs aren't supposed to be taking action based on their own view that the spec is okay. They're supposed to be evaluating whether there's \"rough consensus\".\n\nThe chairs,\npurportedly \"on behalf of the TLS working group\",\n[forwarded the spec to IESG](https://web.archive.org/web/20260812122508/https://mailarchive.ietf.org/arch/msg/tls/131foConAhq1wZ0EOKmD23zSAGY/)\nby email dated 28 Jul 2026 15:10:40 -0700 to request issuance of an RFC.\nIESG sent email on 30 Jul 2026 13:38:00 -0700\nissuing \"last call\" on this spec,\nbased on supposedly having \"received a request from the Transport Layer Security WG\".\n\nAt no moment have the chairs admitted how many people spoke up to object.\nPeople looking at what the chairs\n[reported up the ladder](https://web.archive.org/web/20260729142704/https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/shepherdwriteup/)\nwon't see most of the objections—and might not even realize how controversial this spec is.\n\nThe chairs paint a picture of the opposition disintegrating.\nThat [simply isn't true](https://archive.cr.yp.to/2026-08-11/11:07:06/Py4B3LXgfQLJ5t3FqOWOuU8VGh7uZdCw98eLOzBWFpE/https/mailarchive.ietf.org/arch/msg/tls/g-oB-wLzxRO9VCrX1FPHQxVEfBE/).\nThe number of opponents has increased in each round of voting.\nThree narrow-issue opponents (Stephen Farrell, John Mattsson, Muhammad Usama Sardar) dropped their objections,\nbut many more people found out what was going on and spoke up in opposition.\n\nI'd like to think that IESG will look at the opposition statements from 75 people and say:\nokay, there's no consensus here, we have to reject this.\nI'd also like to think that IESG will grasp\nthat this spec is contrary to the security goal in the\n[TLS WG charter](https://web.archive.org/web/20260428182400/https://datatracker.ietf.org/doc/charter-ietf-tls/)\nand doesn't serve any of the other goals in the charter,\nso it has to be rejected as a charter violation.\n\nBut the reality is that people tend to do what they're paid to do. So let's take a moment to look at the money flow.\n\nI've previously posted quotes showing how\n[NSA is pressuring its \"vendors\"](20251004-weakened.html#tls).\nFor example, a Cisco employee wrote \"that's what they're willing to buy. Hence, Cisco will implement it\";\nand an NSA employee wrote \"Our interactions with vendors suggests that this won't be a problem in most cases\".\nHere are some of the IESG members:\n\nAs another example, consider SEI.\nThe\n[SEI web page](https://web.archive.org/web/20260519072310/https://www.sei.cmu.edu/divisions/cert)\nsays \"Sponsored by the Department of War, the SEI is a federally funded\nresearch and development center\"; Congress's Office of Technology\nAssessment explained\n[many years ago](https://web.archive.org/web/20240326163508/https://www.princeton.edu/~ota/disk1/1995/9501/9501.PDF)\nthat FFRDCs are shell companies created by the U.S. government \"to\nattract the best and the brightest people available using salary above\nthe wage scale the federal government offers\".\nSEI is hosted at a university,\nbut it's a U.S. defense subsidiary, not an independent academic lab.\nHere are another two IESG members:\n\nLet's try some more examples.\nAkamai is the\n[sole provider](https://web.archive.org/web/20260814141958/https://www.highergov.com/contract-opportunity/notice-of-intent-to-sole-source-global-content-d-842673947-s-db5a4/)\nof the Global Content Delivery Service\nto the Defense Information Systems Agency.\n[Cloudflare](https://web.archive.org/web/20260609163920/https://www.linkedin.com/posts/cloudflare-for-government_cloudflare-for-defense-and-intelligence-activity-7429966260391587840-PoNx)\nand\n[Nokia](https://web.archive.org/web/20260328061957/https://www.nokiafederal.com/nokia-federal-solutions-awarded-shield-idiq-contract-by-us-missile-defense-agency/)\nannounced in March 2026 their participation in the\n\"Missile Defense Agency Scalable Homeland Innovative Enterprise Layered Defense (SHIELD) indefinite-delivery/indefinite-quantity (IDIQ) contract with a ceiling of $151B\".\nEach of these companies employs an IESG member:\n\nThen there's NSA itself:\n\nCooley says she retired to join IESG in 2024.\nShe was accurately listing NSA\non a [conflict-of-interest form](https://web.archive.org/web/20240527074304/https://www.ietf.org/about/groups/iesg/iesg-coi-policy/)\nafter joining IESG.\nBut then she switched to claiming that retirement removed the conflict of interest.\nNo, it doesn't.\nThat's the whole point of what are called\n[\"revolving door\"](https://knowledgehub.transparency.org/guide/topic-guide-on-conflicts-of-interest/5852)\nprohibitions.\n\nThere are only 14 IESG members, and I've just listed 9 of them. So, okay, let's assume IESG makes up some excuse to approve the spec. What happens then?\n\nThere are procedures to appeal the decision by the WG chairs,\nfirst to NSA's Deb Cooley,\nthen to the full IESG,\nthen to another committee called the \"Internet Architecture Board\" (IAB),\nwhere defense-contractor employees\n(SEI employee Roman Danyliw,\nCisco employee Suresh Krishnan,\nCloudflare employee Mark Nottingham,\nNokia employee Matthew Bocci,\n[Google](https://web.archive.org/web/20250714161930/https://cloud.google.com/blog/topics/public-sector/google-public-sector-awarded-200-million-contract-to-accelerate-ai-and-cloud-capabilities-across-department-of-defenses-chief-digital-and-artificial-intelligence-office-cdao/) employee Warren Kumari,\n[Comcast](https://web.archive.org/web/20260814163211/https://www.highergov.com/awardee/comcast-government-services-llc-10018728/) employee Jason Livingood,\n[Zscaler](https://web.archive.org/web/20260814182615/https://www.highergov.com/contract/W15P7T24C0003/) employee Yaroslav Rosomakho)\nare again a majority.\n\nThere are also procedures to appeal the IESG decision, first to SEI's Roman Danyliw, then to the full IESG, then to IAB.\n\nAnti-corruption organization Transparency International\nhas a\n[reference guide](https://knowledgehub.transparencycdn.org/kproducts/ti_document_-_guide_complaint_mechanisms_final.pdf)\nfor procedures that organizations should set up to handle complaints.\nIETF doesn't follow any of that.\nIETF has no procedural constraints on how appeals are handled.\n\nIt also won't be surprising to see an RFC issued *before* appeals are resolved.\nEven without tons of money being thrown around,\nthis would produce yet another incentive to deny the appeals,\nsimply to avoid the paperwork of withdrawing an RFC.\n\nThere's one last level of appeal possible within the IETF procedures:\ncomplaining to the Board of Trustees of the Internet Society, IETF's parent organization,\nthat IETF's procedures are\n[\"inadequate or insufficient to the protection of the rights of all parties in a fair and open Internet Standards Process\"](https://web.archive.org/web/20250314041520/https://www.rfc-editor.org/rfc/rfc2026.html).\nI already complained to ISOC\nin [December 2025](https://cr.yp.to/2025/20251223-isoc.pdf).\nISOC said that the \"timing and process\" of handling the complaint\nwould be discussed during ISOC's 25–26 July 2026 meeting\nand then the board would \"designate someone to get in touch with you\".\n\nMaybe they'll designate board member Russ Housley. He's already familiar with what's going on:\n\nHe has\n[voted](https://web.archive.org/web/20260814172248/https://mailarchive.ietf.org/arch/msg/tls/cbHL8zEvwVNPMkmY2BeHVl6ompY/)\n[three](https://web.archive.org/web/20260323162910/https://mailarchive.ietf.org/arch/msg/tls/mXAMgEcgE8mUhnDU0idczgrmCXU/)\n[times](https://web.archive.org/web/20260811110144/https://mailarchive.ietf.org/arch/msg/tls/e0p_FyXBtXo6UDgNa8tPBh9egOM/)\nto issue this spec as an RFC.\nSo he's familiar with the particular topic at hand.\n\nHe was originally\n[Air Force](https://web.archive.org/web/20250616023104/https://vigilsec.com/about.html),\nand is now\n[president](https://web.archive.org/web/20251122090826/https://www.icann.org/en/ssac/members/archive/21-12-2021)\nof a small consulting firm called Akayla\nthat has received $210000 in military contracts since 2023,\nas my regular readers might recall.\nSo he's familiar with the influence of defense contracting.\n\nThe six NSA employees who showed up in the latest round to vote for the spec—Mark Motley,\nMike Jenkins, Morgan Stern, Nicholas Gajcowski, Peter Yee, and William Layton—include\none, Peter Yee,\nwho works not just [for NSA](https://web.archive.org/web/20251010040332/https://www.ieee802.org/1/files/public/docs2025/new-yee-IETFupdate-EMUPQC-0725.pdf)\nbut also [for the same small firm Akayla](https://web.archive.org/web/20260718082844/https://www.ieee802.org/11/Reports/tgbh_update.htm).\nSo Housley is familiar with NSA's interests.\n\nSean Turner, one of the TLS WG chairs,\nis the\n[\"Treasurer, Secretary, and Security Officer\"](https://web.archive.org/web/20250924031317/https://www.ietf.org/media/documents/Turner_-_REDACTED_-_CoI_-_Version_1_-_20241120.pdf)\nof Akayla\n(along with having various redacted affiliations).\nSo Housley is familiar with the interests of the WG chairs.\n(Another TLS WG chair, the spec's author,\nis an employee of\n[CIA-funded](https://web.archive.org/web/20260423024526/https://www.insidequantumtechnology.com/news-archive/sandbox-aq-gets-backing-from-cias-venture-arm-in-q-tel/)\nSandbox AQ.)\n\nHousley served as IETF's Security Area Director 2003–2007, as IETF Chair 2007–2013, and as an IAB member 2007–2017. So he's familiar with how IETF works.\n\nSounds like he's the perfect man in the perfect position to make sure that the IETF procedures do what they're supposed to do. Let's see what happens!", "url": "https://wpnews.pro/news/nsa-and-ietf-part-9", "canonical_source": "https://blog.cr.yp.to/20260814-update.html", "published_at": "2026-08-15 00:54:01+00:00", "updated_at": "2026-08-15 01:11:30.903830+00:00", "lang": "en", "topics": ["ai-safety", "ai-policy"], "entities": ["NSA", "IETF", "ML-KEM", "TLS", "Mike Jenkins", "Daniel J. Bernstein", "IESG", "Roberto Avanzi"], "alternates": {"html": "https://wpnews.pro/news/nsa-and-ietf-part-9", "markdown": "https://wpnews.pro/news/nsa-and-ietf-part-9.md", "text": "https://wpnews.pro/news/nsa-and-ietf-part-9.txt", "jsonld": "https://wpnews.pro/news/nsa-and-ietf-part-9.jsonld"}}