It's normal for post-quantum cryptography to be rolled out as an extra layer of security on top of traditional pre-quantum cryptography, rather than as a replacement.
For example, Google's CECPQ1 experiment was double encryption with traditional pre-quantum ECC (specifically X25519) and post-quantum NewHope1024. CECPQ2, a joint experiment between Google and Cloudflare, was ECC+NTRUHRSS701. CECPQ2b was ECC+SIKEp434. Ten SSH implementations support ECC+sntrup761. Today's usage of post-quantum cryptography by browsers is approaching half of the connections seen by Cloudflare, where 95% of that is ECC+MLKEM768 and 5% is ECC+Kyber768.
If post-quantum cryptography is designed to be super-strong, so strong that it even survives future quantum computers, then why are we keeping the ECC layer? Same reason that you wear your seatbelt: in the real world, cars sometimes crash, and seatbelts reduce the damage.
Google already explained this back in 2016: "The post-quantum algorithm might turn out to be breakable even with today's computers, in which case the elliptic-curve algorithm will still provide the best security that today's technology can offer." We've seen many breaks of post-quantum proposals since then, including the sudden public collapse of SIKE three years after CECPQ2b applied SIKE to tens of millions of user connections. The only reason that this user data wasn't immediately exposed to attackers is that CECPQ2b encrypted data with SIKE and with ECC, rather than switching from ECC to just SIKE. As another example, the reference Kyber/ML-KEM software went through two rounds of security patches for KyberSlash at the end of 2023, and then had another security patch in mid-2024.
Deploying ECC+PQ rather than just PQ is an easy common-sense win. ECC software is practically everywhere anyway, and nobody has identified an application that can afford PQ without being able to afford ECC+PQ.
Typically people talk about deploying ECC+PQ as deploying "hybrids" rather than "non-hybrids", although you have to be careful with this terminology since the word "hybrid" also has other meanings in cryptography. It's more descriptive to talk about "double encryption" and "double signatures" rather than "single encryption" and "single signatures".
The problem in a nutshell. Surveillance agency NSA and its partner GCHQ are trying to have standards-development organizations endorse weakening ECC+PQ down to just PQ.
Part of this is that NSA and GCHQ have been endlessly repeating arguments that this weakening is a good thing (in much the same way that NSA advertised Dual EC as providing "increased assurance"). I have a previous blog post showing that those arguments collapse upon examination. But that's not today's topic. In today's blog post I'm instead looking at how easy it is for NSA to simply spend money to corrupt the standardization process.
Two TLS encryption drafts. For concreteness, I'll focus on what's happening in a particular standards-development organization called the Internet Engineering Task Force (IETF). Within that, I'll focus on current proposals within an IETF "working group" (WG) that sets standards for Transport Layer Security (TLS), the security layer inside HTTPS and inside various other protocols. I'll look specifically at how the TLS WG handled two drafts specifying post-quantum encryption mechanisms for TLS:
Hybrid (double encryption): "Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3". This draft specifies ECC+PQ in TLS, specifically usage in TLS of "X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024". The first of those is also what I mentioned above as 95% of current post-quantum connections to Cloudflare.
Non-hybrid (single encryption): "ML-KEM Post-Quantum Key Agreement for TLS 1.3". This draft specifies usage in TLS of "ML-KEM-512, ML-KEM-768, and ML-KEM-1024" without seatbelts.
The non-hybrid draft was first posted in March 2024. Of course someone asked "what the motivation is for being 'fully post-quantum' rather than hybrid". The draft author responded: "FIPS / CNSA 2.0 compliance guidelines ... currently are a big 'maybe' at best for 'hybrid solutions', and the timetables for compliant browsers, servers, and services are to exclusively use FIPS 203 at level V (ML-KEM-1024) by 2033. I figure there will be demand for pure ML-KEM key agreement, not hybrid (with no questions that come along with it of whether it's actually allowed or not)."
As context, the massive U.S. military budget now publicly requires cryptographic "components" to have NSA approval. "CNSA 2.0" refers to a public NSA document "Commercial National Security Algorithm Suite 2.0". The document says up front that its requirements apply to "all NSS use of public cryptographic algorithms (as opposed to algorithms NSA developed), including those on all unclassified and classified NSS". The legal definition of "national security system" (NSS) covers practically all military information systems, except for "routine administrative and business applications" such as "payroll".
In June 2024, NSA's William Layton wrote that "we do not anticipate supporting hybrid in NSS".
In December 2024, a Cisco employee wrote the following: "There are people whose cryptographic expertise I cannot doubt who say that pure ML-KEM is the right trade-off for them, and more importantly for my employer, that's what they're willing to buy. Hence, Cisco will implement it; I am essentially just asking for code points." Certainly "willing to buy" is a statement about funding, evidently from a source large enough to dictate Cisco actions, evidently from a source asking for non-hybrids, evidently from "people whose cryptographic expertise I cannot doubt"; if that source isn't NSA, who is it?
(Side note: If you think the word "pure" in "pure ML-KEM" sounds good, remember that replacing CECPQ2's ECC+SIKE with "pure SIKE" would have been a disaster.)
In June 2025, NSA's Mike Jenkins posted the following: "As the CNSA 2.0 profiles should make clear, we are 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." Evidently there are many companies happy to jump when NSA says jump.
Pretending to eat your own dog food. For software engineers, "dogfooding" (a term perhaps coined by Paul Maritz in the 1980s) refers to making regular use of the software that you're writing. This builds your confidence that the software works, and helps iron out problems.
But there's also a marketing version of the same concept, where you publicly say that you're using your own software as a way to build other people's confidence in the software. As in other types of marketing, what you're saying doesn't have to be true.
Once upon a time, NSA weakened the Data Encryption Standard to just 56 bits. In public, NSA claimed that it hadn't tampered with the standard, and that the "implausibility of public allegations is further demonstrated by the fact that NSA has endorsed the use of DES for the encryption of national security-related information, including selected classified information".
This is powerful marketing. Many people hearing this last quote will think "Oh, okay, NSA is using DES, so DES is strong". Koblitz and Menezes claimed that it's "far-fetched" that NSA would have intentionally selected something weak "for U.S. government usage (for both unclassified and classified communications [41])". Many people today will think "Oh, okay, NSA is buying single encryption, so double encryption is unimportant".
But DES wasn't strong. NSA had engineered DES to be "weak enough" for NSA to break. NSA wanted DES to "drive out competitors", to "reduce the field that NSA had to be concerned about".
It's perfectly plausible that NSA was using DES, but surely NSA was then using DES multiple times (Triple-DES or beyond), which makes it much harder to break (as long as you switch keys frequently). Obviously NSA wouldn't have said "use multiple layers" publicly: NSA wanted to fool people into thinking that DES was secure.
Today we have better ciphers than DES. However, for data that it cares about, NSA still uses two independent encryption layers "to mitigate the ability of an adversary to exploit a single cryptographic implementation". Gee, maybe multiple encryption is important after all!
Try to put yourself in the mindset of NSA as an attacker. You have a massive budget to "covertly influence and/or overtly leverage" systems to "make the systems in question exploitable"; "to the consumer and other adversaries, however, the systems' security remains intact". One of your action items is to "influence policies, standards and specification for commercial public key technologies". Another is to "shape the worldwide commercial cryptography marketplace to make it more tractable to advanced cryptanalytic capabilities being developed by NSA/CSS".
You spend this money pursuing many different attack paths, taking whatever surveillance wins you can get. It's not that everybody was using Dual EC, for example, but you managed to manipulate some people into using it, and for you that's a win.
Weakening ECC+PQ to just PQ, normalizing the practice of driving without seatbelts, is another win for you as the attacker. It's adding further vulnerabilities to the cryptographic ecosystem. The point is that, beyond SIKE and many other publicly broken cryptosystems, there will be some further cases where your "advanced cryptanalytic capabilities" break the PQ part while the "consumer and other adversaries" think the PQ part is secure.
What do you do with your control over the U.S. military budget? That's another opportunity to "shape the worldwide commercial cryptography marketplace". You can tell people that you won't authorize purchasing double encryption. You can even follow through on having the military publicly purchase single encryption. Meanwhile you quietly spend a negligible amount of money on an independent encryption layer to protect the data that you care about, so you're actually using double encryption.
Adoption of double encryption in TLS. "Adoption" in IETF is a preliminary step before standardization: when a WG is "ready to develop a particular document, the most common mechanism is for it to 'adopt' an existing document as a starting point".
In March 2025, after the close of a two-week "WG adoption call", the TLS WG chairs declared "consensus to adopt" the "Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3" draft.
There were no objections to the declaration of consensus on adopting this draft. I had pointed out that the patents on Kyber/ML-KEM create two issues related to IETF's patent policy, but I said that the first issue can be fixed after adoption (before standardization), and I now think that this is also true for the second issue. The risks from patents are orthogonal to the risks from non-hybrids, and I won't say more about patents in this blog post.
Why worry about a weaker standard if there's a stronger standard? At this point you might be wondering: if people are driving with seatbelts and this is on its way to being standardized, what's the problem with also having a driving-without-seatbelts standard for reckless fools who want to use that?
Think about Dual EC. Dual EC wasn't the only randomness-generation standard. But companies paid for FIPS certification of at least 62 different implementations of Dual EC. NSA bribed the RSA company to change its popular cryptographic library to use Dual EC by default.
These companies saw that Dual EC was a standard from a reputable standards organization (in fact, from three such organizations, namely ANSI, ISO, and NIST). Even for companies realizing that Dual EC was a controversial standard pushed by NSA, how many companies would risk losing money by refusing to implement Dual EC? It's easy for purchasing managers to use standards to set purchasing requirements.
What's particularly pernicious about a driving-without-seatbelts standard is that a purchasing manager who looks at it has an incentive to pick it instead of the driving-with-seatbelts standard. Wow, I can save $50 for every seatbelt that I skip! Wow, I can save 50 picodollars for every ECC operation that I skip! The purchasing manager doesn't care whether this cost reduction matters in context: every penny saved sounds good, right? The purchasing manager also doesn't realize the standard is dangerous: on the contrary, why would it be a standard if it were unsafe?
Soon we're faced with widespread non-usage of seatbelts. And then, years too late, we realize that, oops, something people used and thought was secure actually wasn't, just as in the case of SIKE.
Adoption of single encryption in TLS. On 1 April 2025—unfortunately not as a joke—the TLS WG chairs issued a two-week "WG adoption call for the ML-KEM Post-Quantum Key Agreement for TLS 1.3 I-D", the non-hybrid draft mentioned above.
Here are some quotes (some from me, some from other people) illustrating objections raised on the TLS mailing list during the call period:
The draft creates security risks. Sample quote: "SIKE was applied to large volumes of user data as part of the CECPQ2 experiment in 2019. SIKE was publicly broken in 2022. [paragraph break] The only reason that this didn't immediately give away the user data to attackers is that CECPQ2 was ECC+SIKE, rather than just SIKE. [paragraph break] Should we keep rolling out post-quantum cryptosystems to try to stop future quantum attacks? Yes, of course. But, just in case this goes horribly wrong again, let's make sure to keep ECC in place. Any draft violating this should be rejected as a security risk not just by WGs but also by the ISE."
The draft violates BCP 188. Sample quote: "To the extent that this is an allusion to NSA purchasing, it violates BCP 188 ('IETF Will Work to Mitigate Pervasive Monitoring')."
The draft violates the WG charter. Sample quote: "the draft's regression from ECC+PQ to just PQ is certainly a technology issue; and this is fatal, as a contravention of the 'improve security' goal in the WG charter".
There are no principles supporting the adoption decision. Sample quote: "I don't see what criteria we might use in adopting this that wouldn't leave the WG open to accusations of favouritism if we don't adopt other pure PQ national standards that will certainly arise".
The draft's motivation section is circular. Sample quote: there is "a preliminary step that has been skipped here, namely identifying why the proposal is claimed to be adding something important. The draft's motivation sentence consists of rearranging buzzwords without answering the question: 'Having a fully post-quantum (not hybrid) key agreement option for TLS 1.3 is necessary for migrating beyond hybrids and for users that need to be fully post-quantum.' "
The draft increases software complexity. Sample quote: "The main stated benefit of using a standalone ML-KEM is complexity reduction, but with the current progress in the deployment of the ML-KEM + ECC hybrid method, a standalone ML-KEM method actually increases overall complexity in software stacks." (This was responding to a claim during the adoption-call period that the draft provided a "compute / dependency base that is minimalist".)
This is just a high-level survey of the objections. These quotes aren't intended to convey the full text of objections. They also aren't intended to convey the number of people objecting; I'll get back to that below.
Standardization procedures. How does a standards-development organization handle objections? The law on this topic in the United States has been settled for decades.
The starting point is that agreements in restraint of interstate commerce are illegal. Courts interpret this to cover various types of agreements that are illegal per se, such as price fixing and group boycotts, along with further agreements that unreasonably interfere with competition.
Here's an example from the 1980s. Agents of a company that was leading its market, McDonnell and Miller, took control of a subcommittee of the American Society of Mechanical Engineers, a standards-development organization. They generated a letter, under ASME's apparent authority, declaring that a new competitor's product wasn't compliant. They distributed that letter to buyers, of course damaging the new competitor's business.
The competitor, HydroLevel, sued the conspirators—including ASME, which didn't even know the abuse was happening. HydroLevel won. ASME was ultimately forced to pay millions of dollars. The Supreme Court didn't mince words in describing the anti-competitive power of standards-development organizations:
ASME wields great power in the Nation's economy. Its codes and standards influence the policies of numerous States and cities, and, as has been said about "so-called voluntary standards" generally, its interpretations of its guidelines "may result in economic prosperity or economic failure, for a number of businesses of all sizes throughout the country," as well as entire segments of an industry. ... ASME can be said to be "in reality, an extragovernmental agency which prescribes rules for the regulation and restraint of interstate commerce." ... When it cloaks its subcommittee officials with the authority of its reputation, ASME permits those agents to affect the destinies of businesses, and thus gives them the power to frustrate competition in the marketplace.
... Many of ASME's officials are associated with members of the industries regulated by ASME's codes. Although undoubtedly most serve ASME without concern for the interests of their corporate employers, some may well view their positions with ASME, at least in part, as an opportunity to benefit their employers. When the great influence of ASME's reputation is placed at their disposal, the less altruistic of ASME's agents have an opportunity to harm their employers' competitors through manipulation of ASME's codes.
... Only ASME can take systematic steps to make improper conduct on the part of all its agents unlikely, and the possibility of civil liability will inevitably be a powerful incentive for ASME to take those steps. Thus, a rule that imposes liability on the standard-setting organization -- which is best situated to prevent antitrust violations through the abuse of its reputation -- is most faithful to the congressional intent that the private right of action deter antitrust violations.
Another Supreme Court case rejected an argument of antitrust immunity for another standards-development organization. The organization made various decisions by majority vote, and had allowed steel manufacturers to pack a standards-development group, filling the group with pro-steel agents to take over a vote. The Supreme Court again recognized the importance of procedural safeguards preventing abuse:
The antitrust validity of these efforts is not established, without more, by petitioner's literal compliance with the rules of the Association, for the hope of procompetitive benefits depends upon the existence of safeguards sufficient to prevent the standard-setting process from being biased by members with economic interests in restraining competition. An association cannot validate the anticompetitive activities of its members simply by adopting rules that fail to provide such safeguards.
The Supreme Court declined at that point to draw a dividing line saying which safeguards were required. In 2004, Congress passed a law pinning this down: the new law said that "standards development activity" by a "standards development organization" isn't illegal per se, and gave definitions of the quoted phrases.
In particular, a "standards development organization" is required by law to "incorporate the attributes of openness, balance of interests, due process, an appeals process, and consensus in a manner consistent with the Office of Management and Budget Circular Number A-119, as revised February 10, 1998".
That OMB rule, in turn, defines "consensus" as follows: "general agreement, but not necessarily unanimity, and includes a process for attempting to resolve objections by interested parties, as long as all comments have been fairly considered, each objector is advised of the disposition of his or her objection(s) and the reasons why, and the consensus body members are given an opportunity to change their votes after reviewing the comments".
The Antitrust Division of the Department of Justice inserted itself into a private court case in 2019 to say that "the United States has a significant interest in the correct interpretation of the exemption from per se treatment for standards development organizations engaging in standard setting activities".
Deputy Assistant Attorney General Alexander Okuliar in the same division presented a longer statement to ANSI in 2020 regarding antitrust and standards. The statement mentioned ANSI's compliance with the same requirements and said "From an antitrust perspective, these requirements are central".
Here's a random example of what an objection-response document looks like in ISO, IEC, etc. Not the best user interface, but it gets the job done.
There was not general agreement to adopt the non-hybrid draft. Now that we have the concept of consensus in mind, let's go back to what happened in the IETF TLS WG regarding the non-hybrid draft.
During the adoption-call period, there were statements from 20 people unequivocally supporting adoption: David Adrian from Google, Joseph Birr-Pixton, Uri Blumenthal from Department of Defense subsidiary Lincoln Labs, "Flo D" from GCHQ, Quynh Dang from NIST, Viktor Dukhovni, Scott Fluhrer from Cisco, Rebecca Guthrie from NSA, Russ Housley, Alicja Kario from IBM subsidiary Red Hat, Kris Kwiatkowski, Andrei Popov from Microsoft, Tirumal Reddy from Cisco, Yaroslav Rosomakho, Jan Schaumann, Sophie Schmieg from Google, Martin Thomson from Mozilla, Filippo Valsorda formerly from Google, Loganaden Velvindron, and Thom Wiggers.
There were also statements from 2 people conditionally supporting adoption: John Mattsson from Ericsson ("I support adoption as long as reuse of ephemeral keys is normatively forbidden, i.e. MUST NOT reuse") and Yaakov Stein ("I support adoption of pure PQC KEMs drafts with Intended status: Informational (meaning that the IETF is not recommending using)").
However, there were statements from 7 people unequivocally opposing adoption: Thomas Bellebaum ("I agree with Stephen on this one and would not support adoption of non-hybrids"), Andrey Jivsov ("I am opposed to the adoption of ML-KEM at this time"), Stephen Farrell ("I'm opposed to adoption, at this time"), Rich Salz ("I was all set to say that I am in favor of adoption, but Stephen's post changed my mind. [paragraph break] The conservative and safe thing is to stick to hybrids and that is what the IETF should do for now"), Rob Sayre ("I oppose adoption"), Sun Shuzhou ("I'm opposed to adoption"), and me.
Even assuming that the 2 statements of conditional support are treated as positive votes, the overall situation here, 22 positive votes and 7 negative votes, does not qualify as general agreement. "General" means "shared by or affecting most people, or most of the people in a group"; "most" means "nearly all of the people or things in a group, or nearly all of something"; the phrase "general agreement" means that nearly everyone agrees. Merely having three quarters agree is not good enough.
What happens if a standards-development organization issues a rule declaring that "general agreement" exists even when a quarter of the votes are in opposition? I haven't found any court cases on point, but I would expect courts to reject this as being inconsistent with the plain meaning of "general agreement".
Anyway, IETF hasn't attempted to issue such a rule. On the contrary, IETF claims that WG decisions are not taken by voting: "Decisions within WGs, as with the broader IETF, are taken by 'rough consensus' and not by voting." This begs the question of what IETF thinks "rough consensus" means. Letting chairs make arbitrary decisions is a violation of due process.
More to the point, IETF can't override the definition of "consensus" in the law. That definition requires general agreement. Adoption of this draft was controversial, and didn't reach general agreement.
Objections were not handled properly. Within the statements in favor of adoption, most of the statements were very short: e.g., just the words "I support adoption" with no further comments.
Some statements in favor of adoption did say more, such as stating circular arguments for the draft (e.g.: "as time progresses, non-hybrid key exchanges will become more and more commonplace, so why not have it already defined?"), or expressing concerns about key reuse (e.g.: "I also share John's concerns about key reuse, but would prefer to litigate that in the working group, rather than during adoption"), without responding to the content of the objections.
There was a response to one word in the lack-of-principles objection. (The response was as follows: "The NIST competition was international, and Kyber was developed by an international team. I struggle to understand how adopting this document would somehow be 'favoritism'.") A brief note by one supporter tangentially related to one objection falls far short of fair consideration of each objection by the group as a whole.
I tried to engage that supporter in discussion. I started by quoting the following earlier statement in the commentator's message: "I find it to be cognitive dissonance to simultaneously argue that the quantum threat requires immediate work, and yet we are also somehow uncertain of if the algorithms are totally broken. Both cannot be true at the same time." I responded as follows:
Rolling out PQ is trying to reduce the damage from an attacker having a quantum computer within the security lifetime of the user data. Doing that as ECC+PQ instead of just PQ is trying to reduce the damage in case the PQ part is broken. These actions are compatible, so how exactly do you believe they're contradictory?
Here's an analogous example of basic risk mitigation: there's endless work that goes into having planes not crash, not hit turbulence, etc., but we still ask airplane passengers to keep their seatbelts on whenever they're in their seats.
There was still no reply to this by the time the adoption call closed two weeks later.
The broader pattern was that objectors were engaging in discussion while supporters were not. The majority process wasn't "attempting to resolve each objection"; it was simply collecting positive votes, trying to override objections from the minority without even answering those objections, let alone trying to resolve them.
That's in an organization saying that decisions aren't taken by voting. The same organization also says, as part of explaining why it's supposedly complying with antitrust law: "IETF activities are conducted with extreme transparency, in public forums. Decision-making requires achieving broad consensus via these public processes."
When there's an objection, the legal concept of consensus requires not just fairly considering the objection, and not just attempting to resolve the objection, but—if resolution fails—having the group agree on the contents of a response to the objection. That's an official statement of why the objection was overridden. It's something that can be appealed if it's wrong. Consider, for example, ISO's simple rule saying "Committees are required to respond to all comments received". In IETF, there weren't even informal responses to the objections listed above, let alone official responses.
The chairs declared consensus anyway. Shortly before the end of the specified adoption-call period, the chairs declared "consensus to adopt this draft as a working group item". There were some notes on followup procedures, but there was no explanation of the rationale for this claim of consensus.
I challenged the claim of consensus:
Um, what? There were several people (including me) raising objections on list to basic flaws in this draft, such as (1) the failure to provide an ECC backup to limit the damage from further security problems in the PQ layer, (2) the failure to provide an engineering justification for this option, and (3) the lack of any principles that would justify saying no to options selected by other governments if this option is allowed.
Your message doesn't explain how you came to the conclusion that there's consensus. Surely you aren't relying on some tally of positive votes to ram this document through while ignoring objections; voting isn't how IETF is supposed to work. So how did you come to this conclusion?
A few days later, the chairs responded that they had declared consensus "because there is clearly sufficient interest to work on this draft".
I said that this was ambiguous (sufficient for what?); said that in any case this criterion was improper since it "would allow a draft to be adopted over amply justified objections of almost all WG participants, simply because the chairs and a few participants say they have enough interest in working on the draft"; and asked for an explicit statement of whether this was the complete explanation of why the chairs had declared consensus.
The chairs responded that "sufficient" means "that there were enough people willing to review the draft". They added that "WGs groups have adopted drafts with much less support than this one received." Gee, that's confidence-inspiring.
Meanwhile an IETF "security area director" had jumped into the discussion, in particular writing "There is clearly consensus based on the 67 responses to the adoption call. ... The vast majority was in favour of adoption ... There were a few dissenting opinions".
Remember that the actual tallies were 20 supporters, 2 conditional supporters, and 7 opponents, even if some people (for example, me) had sent multiple messages. Nobody had posted the actual tallies at this point: there was just this "security area director" claiming that the "vast majority" of the "67 responses" were in favor while there were only "a few dissenting opinions". Also remember that this is an organization that claims that it doesn't make decisions by voting.
The "security area director" continued that "you cherry-picking when to call consensus evaluation 'voting' depending on whether misnaming this is in your advantage ... is dishonestly manipulative"; that I was violating the "code of conduct"; and that if I did not "voluntarily stop this kind of behaviour" there would be "measures under the terms of RFC3934 which is part of BCP25".
In a followup message, the "security area director" wrote "you calling into question this consensus call of the WG chair is abusive and follows a repetitive pattern. Nevertheless, for now this is your right ... you are attempting to bait the chairs to say they took inventory of the public emails ... there comes a point where you will be prevented from further playing these games".
Wait a minute: "for now this is your right" (emphasis added) and "you will be prevented from further playing these games"? Sounds ominous. What did the "security area director" mean by this? No more objections in IETF? No more appeals? NSA's minions can just ram their non-consensual drafts through IETF without opponents even being allowed to speak up?
Actually, yes, there's a stealth activity going on right now that will have this effect unless enough people take action by Tuesday the 7th. I hope to have another blog post up in a day or two saying what's going on here.
Anyway, I've filed a formal complaint regarding the claim of consensus to adopt. So far the complaint hasn't been handled properly, but hope springs eternal. I don't have an answer yet to the subtitle question of this blog post.