This is the second in a series of four messages responding to IESG's
"last call" for draft-ietf-tls-mlkem.

This message and the third message together present and comment upon
quotes from 75 people out of a larger number of people who spoke up in
opposition to issuance of draft-ietf-tls-mlkem as an RFC.

These quotes are only for opposition stated on the TLS mailing list
during the third TLS WGLC for that (24 June 2026 through 8 July 2026),
in messages where "WG Last Call: draft-ietf-tls-mlkem-08" was included
in the subject line. This excludes various opposition statements that
appeared in other venues, that were sent to the list but blocked by the
chairs, or that were sent to the list before or after the third WGLC.

The chairs asked people to just say yes or no, and complained when
people disobeyed ("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."). Astoundingly, the chairs then arrogated to
themselves the power to disenfranchise people who had not "demonstrated
expertise", unless those were "pre-existing WG participants".

The chairs claimed that "if we look at pre-existing WG participants or
people with demonstrated expertise, roughly 7/10 WG participants favor
advancing the document, which shows rough consensus to move the document
forward"; but also claimed that they had "focused their consensus
judgement on people that participated in TLS prior to the last WGLC".
The shifting stories and further evasion by the chairs left unclear who
had been disenfranchised. See my first message for more about this.

I objected during WGLC to the chair efforts to stop discussion. The
opposition statements often ended up saying much more than just no, as
you can see from the 75 quotes. The quotes are often just excerpts;
please also look at the original statements. I've linked to archived
copies of all WGLC messages from each of these 75 authors.

I've checked that none of those messages suggest any possibility that
document modifications can remove these objections. There would have
been 82 quotes otherwise, and even more if I had not narrowed this to
_unambiguous_ objections, but I want to avoid any accusations of
overstating the level of opposition; see my first message.

The 75 authors are in order of their first postings to the list during
the third WGLC. Regarding each of the 75 quotes: I agree with what I'm
quoting, and I object to publication on that basis. I request that IESG
state for the record what weight it is giving to that source: same
weight as everyone else? disenfranchisement? something different?

Furthermore, for each quote that includes more than simply saying no, I
request that IESG follow the normal process of directly responding to
each point for the record, so that the original author and I can see the
official response to that specific objection. Every legitimate SDO
records an official response to each objection, following the rule that
"each objector is advised of the disposition of his or her objection(s)
and the reasons why", rather than using the breadth of opposition as an
excuse for lazy blanket replies.

IETF says that "rough consensus" means "that a very large majority of
those who care must agree, and that those in the minority have had a
chance to explain why and their points have been addressed, even if they
were not agreed with". Neither of those conditions has been met. I want
the records to be clear.

To avoid a source of inaccuracies, I strictly avoid all use of LLMs in
writing all of my messages, including these four messages. See

    https://www.nytimes.com/2026/04/13/well/ai-chatbots-cancer.html?unlocked_article_code=1.4FA.nfHn.tMfHDs5AvOKj&smid=url-share

for motivation. I request that responses also avoid all use of LLMs.


## Quote 1

Original messages from this author:
* https://web.archive.org/web/20260720020421/https://mailarchive.ietf.org/arch/msg/tls/SABh7Sw1dqdv_I04WFUeQByoVVY
* https://web.archive.org/web/20260721044636/https://mailarchive.ietf.org/arch/msg/tls/UlHB21g1-eUvTHPKUfL76q2ZM74
* https://web.archive.org/web/20260722040841/https://mailarchive.ietf.org/arch/msg/tls/tjeyhW0sZx7-Pbq9rRFaocl73w8

Simon Josefsson <simon@josefsson.org> writes:
> I am against publication of the document through the TLS WG.
> 
> My reasons were explained earlier, e.g. in [1], and have not been
> addressed in later versions of the document.
  [ ... ]
> [1] https://www.mail-archive.com/tls@ietf.org/msg23297.html

The cited message says that "a hybrid ECC+PQ provides a more appropriate
risk/cost ratio". That was in the context of signatures, but the same
author had already expressed the same concern regarding encryption:
"Pure PQ KEM's in TLS comes with cryptographic risks, and the risks
aren't sufficiently motivated by reasonable needs here."


## Quote 2

Original messages from this author:
* https://web.archive.org/web/20260720021438/https://mailarchive.ietf.org/arch/msg/tls/kxf0UioZkaIUhGOR9u682SG7g_o
* https://web.archive.org/web/20260721023034/https://mailarchive.ietf.org/arch/msg/tls/AMVKoS_Yn6fdqg092zUUnizAmY8
* https://web.archive.org/web/20260721023336/https://mailarchive.ietf.org/arch/msg/tls/fwtYE1uTA8eCKruMSxiiZpX3RJA
* https://web.archive.org/web/20260721043957/https://mailarchive.ietf.org/arch/msg/tls/EhkjcpoDm9Gme6yyEcZNBrA6KZE
* https://web.archive.org/web/20260721044519/https://mailarchive.ietf.org/arch/msg/tls/b30_Q2E2VKdC9pEEojz4mppwm9k
* https://web.archive.org/web/20260722041155/https://mailarchive.ietf.org/arch/msg/tls/_aWcL_2JCzYfb2vNMEn8J0vazIM
* https://web.archive.org/web/20260722043707/https://mailarchive.ietf.org/arch/msg/tls/yO7OQQPX0eyYYAvwNZ6ReoUk8IE
* https://web.archive.org/web/20260722050402/https://mailarchive.ietf.org/arch/msg/tls/Pz-BufT5R0y8n60RECllJgFk0bw
* https://web.archive.org/web/20260721020459/https://mailarchive.ietf.org/arch/msg/tls/Wrmgro45mXfLpw8J8n4v_7HEofM
* https://web.archive.org/web/20260722051551/https://mailarchive.ietf.org/arch/msg/tls/eHgnRPruPNTMfJP2qvZf53HvZzc
* https://web.archive.org/web/20260722051630/https://mailarchive.ietf.org/arch/msg/tls/VZZ0rZhfdPtvNZJTNv1gX5-sJPk
* https://web.archive.org/web/20260721034023/https://mailarchive.ietf.org/arch/msg/tls/6mLJEgCTFbGmxUcTTSMXBv14Uwo
* https://web.archive.org/web/20260722052109/https://mailarchive.ietf.org/arch/msg/tls/7VPpoyFJr0snQy1Iwh60gYQg708

Andrew Lee <andrew@joseon.com> writes:
> I do not support publication of this document.
  [ ... ]
> Publishing this RFC will signal legitimacy to what is, as of today, a
> downgrade [1].
  [ ... ]
> [1] Serious flaws in implementations continue to be discovered, daily,
> including, 1 day after this third round of votes began, in Wolf SSL
  [ ... ]
> [2] https://www.cve.org/CVERecord?id=CVE-2026-6330
  [ ... ]
> Thank you for confirming, on the record, that the Canadian government
> plans to recommend solo ML-KEM for TLS despite the document carrying a
> RECOMMENDED=N flag.
  [ ... ]
> That means Canada plans to treat a limited-applicability,
> specific-use-case option as equivalent to the RECOMMENDED=Y hybrid.
> 
> That is the very definition of ignoring the flag.

Let me emphasize two different points made in this quote.

The first point is that downgrading from ECC+PQ to solo PQ means extra
exposure to PQ implementation flaws.

This isn't the only problem with the downgrade, but it's an extremely
difficult point for proponents to answer. Answers such as "There won't
be any exploitable PQ implementation flaws" or "Every attacker who can
exploit a PQ implementation flaw is also able to exploit ECC" wouldn't
pass the laugh test. Weaker answers such as "I think my PQ software is
safe" or "Someday attackers will all have quantum computers cheaply
breaking ECC keys" don't counter the point.

Proponents often switch to claiming that objections, whatever the
objections are, don't matter since Section 6 of the document lists "N"
under "Recommended" while a safer ECC+PQ document (ecdhe-mlkem) lists
"Y". We're supposed to believe that this information will actually get
through to readers, stopping the downgrade. One proponent acknowledges
that draft-ietf-tls-mlkem is at NSA's behest but claims that any
problems will be "not impacting anyone else" beyond NSA:

    https://web.archive.org/web/20251225222528/https://keymaterial.net/2025/11/27/ml-kem-mythbusting/

The reality, however, is that this "N"-vs.-"Y" distinction is buried
and often won't get through to people making decisions about what to
use. That's the second point made in the above quote.

The Canadian example used in the quote is NSA partner CSE, which says
that it "plans to recommend the use of ML-KEM for TLS" according to
draft-ietf-tls-mlkem and also "plans to recommend hybrid ECDHE-MLKEM as
per draft-ietf-tls-ecdhe-mlkem":

    https://web.archive.org/web/20260722051034/https://mailarchive.ietf.org/arch/msg/tls/vn-EJkWHCrKes1TvCvRU4CrSsbA/

So the original "Recommended: N" and "Recommended: Y" turn into just
"recommend" and "recommend".


## Quote 3

Original messages from this author:
* https://web.archive.org/web/20260721014234/https://mailarchive.ietf.org/arch/msg/tls/41NCesGJzppwNL5fkLhyi_Cydqs
* https://web.archive.org/web/20260721033305/https://mailarchive.ietf.org/arch/msg/tls/wp9cDcGoee6ZPVuPGt9amPtgRtE
* https://web.archive.org/web/20260721033419/https://mailarchive.ietf.org/arch/msg/tls/5LhgUbxxbn5iPMg_CiUkNX62HzU
* https://web.archive.org/web/20260721041045/https://mailarchive.ietf.org/arch/msg/tls/ysC7Xz_g2-aavveGp_5BSB9Vf5Y
* https://web.archive.org/web/20260721042326/https://mailarchive.ietf.org/arch/msg/tls/TodOftD9_5f-YdLvkpNor1lo6s4
* https://web.archive.org/web/20260722183906/https://mailarchive.ietf.org/arch/msg/tls/MY3UshnWC0LIvDdhIKBiyFx1tPQ

David Stainton <dstainton415@gmail.com> writes:
> I object to the publication of this document.
  [ ... ]
> Publication isn't neutral. It's the
> thing that turns some registry entries into products people ship.
> 
> So "does the RFC drive deployment" isn't really in dispute anymore.
> You've argued that it does. The real question is whether we want to
> push deployment toward standalone ML-KEM when X25519MLKEM768 is
> already there, already Recommended=Y, strictly stronger, and costs
> almost nothing.

This quote begins by emphasizing that issuing an RFC has an influence
(despite various denials from proponents), and continues by highlighting
this spec's foolish removal of a low-cost defense.


## Quote 4

Original messages from this author:
* https://web.archive.org/web/20260721014544/https://mailarchive.ietf.org/arch/msg/tls/GL9oPGn60Oz601--gqCk4hcQlCM
* https://web.archive.org/web/20260721020812/https://mailarchive.ietf.org/arch/msg/tls/sJZkQ1YRYXF_lIhr0tKF_qTvlOg
* https://web.archive.org/web/20260721020620/https://mailarchive.ietf.org/arch/msg/tls/IxuKXmrNL3drVmEo-3cJiYBfOwI
* https://web.archive.org/web/20260721022040/https://mailarchive.ietf.org/arch/msg/tls/m-gqGbrdOObvMd1qxb6PnOvJVzw
* https://web.archive.org/web/20260721022529/https://mailarchive.ietf.org/arch/msg/tls/XHT418V8IBYcl0bHf9tsdBc1Sds
* https://web.archive.org/web/20260721023931/https://mailarchive.ietf.org/arch/msg/tls/lo9FBpW-6WhvltdV5CFATAnUNgk

"D. J. Bernstein" <djb@cr.yp.to> writes:
> 1. Security damage of solo PQ
> 
> Deployment of draft-ietf-tls-mlkem and/or draft-ietf-tls-mldsa means two
> things:
> 
>     (1) Throw away the protection provided by the status quo. I'll focus
>         on ECC as the typical status quo for concreteness, but the exact
>         choice has only minor effects below.
> 
>     (2) As something that's _claimed_ to provide more protection, roll
>         out ML-KEM and/or ML-DSA.
> 
> But let's look at whether this claim is actually true.
> 
> I have a new paper this month that presents fast exploit scripts for
> some ML-DSA bugs; uses standard techniques to predict ML-DSA bug rates
> starting from ML-DSA code sizes and https://arxiv.org/abs/2107.04940;
> uses known ML-DSA bugs such as https://eprint.iacr.org/2026/1032 and
> ML-DSA CVEs as sanity checks; and quantifies the security damage of
> rolling out solo ML-DSA. The following graph summarizes the damage:
> 
>     https://cr.yp.to/papers/mldsa-20260601.pdf#breakable-keys
> 
> The TLS part of the damage will be millions of breakable ML-DSA keys in
> 2027, millions of breakable ML-DSA keys in 2028, etc. Even years after
> the first secret quantum attacks begin (I was already on record in 2023
> with a median estimate of 2029 for that), there will be many more ML-DSA
> keys broken because of software vulnerabilities than ECC signature keys
> broken because of quantum attacks _plus_ software vulnerabilities.
> 
> It's not hard to carry out a similar analysis for ML-KEM. The code is
> noticeably smaller for ML-KEM than for ML-DSA and not quite as new on
> average, so the vulnerability rates per ML-KEM implementation will be
> lower, but this is outweighed by the fact that there will be many more
> total ML-KEM keys in TLS than total ML-DSA keys, making quantum attacks
> an even smaller part of the overall attack picture.
> 
> To summarize, using draft-ietf-tls-mlkem and/or draft-ietf-tls-mldsa
> will be an unmitigated security disaster. Let me emphasize that this is
> simply accounting for the predictable impact of bugs, never mind timing
> attacks (see, e.g., https://cr.yp.to/papers.html#kyberslash) never mind
> the risk of breaks of the _specs_ of ML-KEM and ML-DSA.
> 
> 
> 2. Mitigation: ECC+PQ
> 
> The well-known, widely deployed, common-sense mitigation for failures of
> PQ security is to preserve the existing ECC layer as part of ECC+PQ: for
> example, continue signing with ECC as part of ECC+PQ double signatures,
> and similarly for encryption. (Typically ECC+PQ is called a "hybrid",
> although that name often confuses people.) There are many detailed
> ECC+PQ examples, including specs that do the job for TLS, namely
> draft-ietf-tls-ecdhe-mlkem and draft-reddy-tls-composite-mldsa.
> 
> ECC+PQ has negligible cost beyond solo PQ. The complexity and risks of
> software engineering and testing are almost entirely inside the ECC code
> (which was there already) and the much newer PQ code (for code sizes
> see, e.g., https://cr.yp.to/papers/pqcomplexity-20240419.pdf regarding
> ML-KEM and https://cr.yp.to/papers/mldsa-20260601.pdf regarding ML-DSA),
> not the combiner code. Sure, combiner code can have bugs too, but adding
> that code is mitigation against bugs in much more complicated code for
> ML-KEM and ML-DSA, so it would make absolutely no sense to wave at the
> combiner complexity as a reason to avoid this mitigation.
> 
> To be clear, having less code _tends_ to be good. But this has many
> exceptions. Arguing for less code isn't a valid argument to throw away
> test code, or to downgrade to the null cipher, or to use solo PQ rather
> than ECC+PQ. ECC+PQ is safer than solo PQ.
> 
> Quantification of bug rates and exploitation costs in the case of ML-DSA
> is new to my paper this month, but qualitatively the advantage of ECC+PQ
> is something I pointed out much earlier. For example,
> 
>     https://cr.yp.to/talks.html#2016.02.24
> 
> recommends ECC+PQ, even (explicitly) for the case of the PQ part being
> hash-based signatures. As for software issues,
> 
>     https://web.archive.org/web/20220308032457/https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/LVpCs_vjMlE/m/M2uQPfaEAQAJ
> 
> from 2018 describes NISTPQC as "the largest regression _ever_ in the
> quality of cryptographic software" and says this "will not be easy to
> fix"; see also
> 
>     https://cr.yp.to/talks/2018.12.28/slides-dan+tanja-20181228-pqcrypto-16x9.pdf#page.74
> 
> for a summary of the software situation. Putting this together,
> 
>     https://web.archive.org/web/20260603074058/https://mailarchive.ietf.org/arch/msg/spasm/pcISUlnedpExwwLuISP18oR1zxc/
> 
> from 2024 emphasizes how the risks of "bugs in post-quantum software"
> warrant "a blanket rule of always upgrading from ECC to PQ+ECC, _not_
> discarding the ECC layer, even when the PQ layer is SPHINCS+"; and the
> same 2024 posting explains the difference between state-of-the-art bug
> elimination and what happens in the real world.
  [ ... ]
> Who's the supposed user base for these specs? The answers are absurdly
> inconsistent. Someone asking about the purported _advantage_ of solo PQ
> over ECC+PQ is treated to wild exaggerations of the cost difference and
> to a whac-a-mole game of supposed applications (such as "high-frequency
> trading"). Someone asking about the _security damage_ is instead told
> that this is just for NSA. C'mon, this doesn't pass the laugh test.
> 
> The case for the specs also includes arguments that, because of some
> "recommended" entry in the IANA registry, solo PQ won't be used. Huh?
> How many purchasing managers ever look at the IANA registry?
> 
> The reality is that an RFC will be viewed by typical readers as IETF
> endorsement, and will lead to many deployments that wouldn't otherwise
> exist. See, e.g.,
> 
>     https://web.archive.org/web/20260625095524/https://mailarchive.ietf.org/arch/msg/tls/LCtGfIAfsOkuuh5NP7l0wAWUk4A/
> 
> saying "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 ... 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.' " Or see
> 
>     https://web.archive.org/web/20260521112257/https://mailarchive.ietf.org/arch/msg/last-call/mNqIHumBiO2kJMfh7-MBWlVS3xg/
> 
> saying that what "largely" matters is whether there's an RFC, not how
> the RFC is labeled.
> 
> Perhaps most importantly, the case for the specs includes arguments
> denying that ECC+PQ is safer than solo PQ:
> 
>     * There's conflation of spec security with software security (how do
>       we explain all the bugs and timing attacks, then?), accompanied by
>       a claim that the ML-KEM and ML-DSA specs were "fully vetted"
>       during the NIST competition (so eprint papers 2025/1910,
>       2025/2189, and 2026/279 are all wrong?).
> 
>     * There's a claim that ML-KEM and ML-DSA will have "exceedingly few
>       bugs"---but no response to clarification questions asking (1) how
>       many bugs, (2) where this number is coming from, and (3) how this
>       is supposed to be an argument for the specs when the same posting
>       admits that "a single broken key per month can be catastrophic".
> 
>     * There are some astounding claims that attacks don't matter. For
>       example, in the case of ML-DSA, we're supposed to believe that
>       "the blast radius for signatures has a strict end with revocation
>       of the key". This ignores not just the expense and difficulty of
>       cleaning up after attacks that are discovered, but also the damage
>       done by attacks _before_ the attacks are discovered. For example,
>       NSA said that its QUANTUMINSERT forgery attacks were "highly
>       successful" starting in 2005; those attacks weren't publicly
>       detected until the Snowden documents revealed them in 2013.
> 
>     * There's a claim that ECC is useless. This ignores (1) all of the
>       available evidence regarding the cost of quantum computation (see
>       generally https://cr.yp.to/papers/mldsa-20260601.pdf#ecc) (2)
>       the value of limiting the number of attackers, and (3) the value
>       of delaying attacks.
> 
>     * There's a claim that specific ECC+PQ mechanisms proposed for TLS
>       allow malleability attacks that PQ by itself wouldn't allow. This
>       claim has been repeatedly debunked, even with a debunking demo in
>       https://github.com/crypto-security-tools/on-composites-signatures,
>       and yet the claim continues to be repeated on this mailing list.
> 
> RFC 2418 says that disagreements "must be resolved by a process of open
> review and discussion". This rule is obviously a big problem for these
> specs: the case for the specs is flimsy and cannot survive a resolution
> process. Unfortunately, aside from a few minor issues such as the FATT
> issue, this resolution process simply hasn't happened for these specs.
> 
> What the chairs _should_ be doing is insisting on the specs stating a
> coherent, stable rationale that survives scrutiny and reaches consensus.
> Instead the chairs are allowing spec proponents to ignore objections;
> allowing new arguments for the specs to suddenly appear at the moment of
> a limited-time last call; and now trying to terminate the process of
> dispute resolution ("Please refrain from further discussion on this
> topic"). Sorry, no, RFC 2418 says "must be resolved" and gives chairs no
> authority to override this.
  [ ... ]
> Regarding the draft-ietf-tls-mlkem last call: I am opposed to any
> endorsement of this spec. In particular, I am opposed to the proposal on
> the table to issue the spec as an RFC.
  [ ... ]
  [ regarding "Recommended: N" in the IANA registry: ]
> This argument might be relevant in a fantasy world where corporate
> purchasing managers understand IETF endorsement to be conveyed not by
> the issuance of RFCs but rather by the IANA registry.
> 
> In the real world, I'm sure a survey will show that the majority haven't
> even heard of the IANA registry. They also don't check the RFCs they're
> requiring to check for unexplained buried notes saying "Recommended: N".
> 
> We've even seen Eric Rescorla admitting this: "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.' "
> 
> Just to emphasize: that's admitting the controversy regarding _the WG
> issuing an RFC_ (the proposal on the table). It's also admitting that
> pointing to "Recommended: N" doesn't address the controversy.
> 
> Now the chairs are pointing to "Recommended: N" (by comparison to
> "Recommended: Y" in a better spec) and claiming that this addresses the
> controversy. No, it doesn't. Any action that will be interpreted as
> endorsing this security-sabotaging spec is unacceptable. The issuance of
> an RFC will be viewed as IETF endorsement; that's unacceptable. The
> (fraudulent) claim of "consensus of the IETF community" will also be
> viewed as IETF endorsement; that's also unacceptable.

This quote is from me. I request an official response to each point.

To be clear, my request for responses is not limited to this quote. For
each of the other 74 quotes, whenever the quotes are making points
beyond just saying no, I am also requesting an official response to each
point in that quote and each point in my own comments on that quote.


## Quote 5

Original message from this author:
* https://web.archive.org/web/20260721014855/https://mailarchive.ietf.org/arch/msg/tls/rzp31-ihIzLMUrso_IlSs0isCwY

Mark Atwood <mark@reviewcommit.com> writes:
> I do not support publication of this document.
> 
> The hybrid approach (draft-ietf-tls-ecdhe-mlkem) provides
> defense-in-depth: if ML-KEM is broken by classical cryptanalysis, ECDH
> still protects the session. This draft removes that fallback for no
> meaningful benefit---the overhead difference is approximately 100 bytes
> per handshake.
> 
> ML-KEM has two years of deployment experience. ECDH has forty years of
> cryptanalysis. SIKE was broken shortly after NIST selection,
> demonstrating that post-quantum algorithms can fail unexpectedly.
> Removing the classical fallback is a security regression, not an
> improvement.
> 
> The hybrid draft is already approved and in the RFC Editor queue.
> Chrome, Firefox, and Edge ship X25519MLKEM768 as their default. There
> is no demonstrated need for a pure ML-KEM option that abandons
> defense-in-depth.

This quote is highlighting how the spec unnecessarily incurs
cryptanalytic risk for negligible benefit. The spec does not improve
TLS deployability.

SIKE is a post-quantum algorithm that survived three rounds of NIST
selection. It was one of just four algorithms that NIST said it would
consider for standardization at the end of round 4. It was one of just
two algorithms selected by Google and Cloudflare for a large-scale
experiment on real user data. https://eprint.iacr.org/2021/543
advertised it as "a decade unscathed". But then it was suddenly smashed.

Mark Atwood hasn't posted to the TLS mailing list before. Does IETF say
"a very large majority of those who care must agree, except that people
like Mark Atwood can be ignored"?


## Quote 6

Original messages from this author:
* https://web.archive.org/web/20260721014937/https://mailarchive.ietf.org/arch/msg/tls/Pvfya0JV8VnmRmXcq1AcpuW3CCI
* https://web.archive.org/web/20260722195131/https://mailarchive.ietf.org/arch/msg/tls/qBCBEsc6QRG1OxYsUg1k0nThDrE

Sam <sam.leavin@gmail.com> writes:
> I do not support the publication of the document.
> Defense-in-depth is a proven strategy, and the so-called hybrid
> approach would be best.
  [ ... ]
> Just because some people want to make it easier for others to use a less
> powerful security mechanism doesn't mean that the IETF needs to assist
> them.
  [ ... ]
> This document could affect millions of people for decades to come - it is
> not something to be pushed out casually. The IETF uses (rough) consensus so
> that all concerns may be heard and considered. I appreciated the table-like
> ISO document someone linked that had a list of issues raised, the category
> the issue was placed into, and a documented response, so that it was clear
> that all grievances had been addressed.

Of course, forcing an official response to each objection also means
forcing consensus on those responses. This is important protection
against proponents issuing talking points that haven't been thought
through or that contradict each other.

Here's one of my postings giving an example of such an inconsistency:
"Who's the supposed user base for these specs? The answers are absurdly
inconsistent. Someone asking about the purported _advantage_ of solo PQ
over ECC+PQ is treated to wild exaggerations of the cost difference and
to a whac-a-mole game of supposed applications (such as 'high-frequency
trading'). Someone asking about the _security damage_ is instead told
that this is just for NSA. C'mon, this doesn't pass the laugh test."


## Quote 7

Original message from this author:
* https://web.archive.org/web/20260721015020/https://mailarchive.ietf.org/arch/msg/tls/SHfslpHXoWR8TZxc-DD9eh3GpRI

Pretty Hot And Tasty Bits <phatbitz@gmail.com> writes:
> I do not support the publication of this document.

As noted in my first message, I saw support statements from 5 people who
might be barred by a real-name policy ("Flo D", "Michael P", "Peter C",
"Q Misell", "Soatok Dreamseeker"), and also opposition statements from 5
such people; this is one of the latter.


## Quote 8

Original messages from this author:
* https://web.archive.org/web/20260721015405/https://mailarchive.ietf.org/arch/msg/tls/cQnuMNzLZJ_iYyolSdTZbpjUjVQ
* https://web.archive.org/web/20260721015619/https://mailarchive.ietf.org/arch/msg/tls/L87JNYxG_7YvyYw0VdwRD0Ix0Kg
* https://web.archive.org/web/20260721023703/https://mailarchive.ietf.org/arch/msg/tls/N2LKhaif3rItz6ptZY5v0p1OtTE
* https://web.archive.org/web/20260721023812/https://mailarchive.ietf.org/arch/msg/tls/h-aRkNhXva1Ts-sLYiBmY-lfWQA
* https://web.archive.org/web/20260721030901/https://mailarchive.ietf.org/arch/msg/tls/m-fStN2j38Rut3k1idbf73WaTrY
* https://web.archive.org/web/20260721042952/https://mailarchive.ietf.org/arch/msg/tls/rkkyF_SHmtUwILNn4AGN7zoo6qU
* https://web.archive.org/web/20260721043031/https://mailarchive.ietf.org/arch/msg/tls/JXKbaSleLn4aEbAqlDzIF39QHm4
* https://web.archive.org/web/20260722030549/https://mailarchive.ietf.org/arch/msg/tls/pYkth5FVEWGUyVGd6VKhhjy_N8E
* https://web.archive.org/web/20260702163419/https://mailarchive.ietf.org/arch/msg/tls/gdWhrNE0x286y3S0WpQDpep1fso
* https://web.archive.org/web/20260722044433/https://mailarchive.ietf.org/arch/msg/tls/mY0bbEygG5NkWPUCIuL-5DpgRPw
* https://web.archive.org/web/20260722051149/https://mailarchive.ietf.org/arch/msg/tls/7ofxq9DL8H42-mF3ue8vNoBhIgA
* https://web.archive.org/web/20260722191606/https://mailarchive.ietf.org/arch/msg/tls/4iJykBUmkyn5bZxL6fHRd099beU
* https://web.archive.org/web/20260722192134/https://mailarchive.ietf.org/arch/msg/tls/Y0SwHC6QgkbFFvBQGJWbQaFpTpY
* https://web.archive.org/web/20260722192411/https://mailarchive.ietf.org/arch/msg/tls/GKzXW_Uiy6zKu0sw0gJ0DNV8sjQ
* https://web.archive.org/web/20260722200801/https://mailarchive.ietf.org/arch/msg/tls/6YnmGxKWY1XNAvjy3a_fHG4pSUk

Nadim Kobeissi <nadim@symbolic.software> writes:
> I oppose the publication of this document.
  [ ... ]
> Imagine you have a company that manufactures vaults. This company has
> been following a successful, highly popular, well-specified and
> performant dual-lock design to produce vaults for many years that have
> two separate unique locks. Each lock has a different design, and the
> two-lock design ensures that if one lock's unique design fails for
> whatever reason, the other lock helps maintain the vault's security.
> 
> Everyone loves these vaults and they work great. Millions have been
> sold and there are no complaints or problems.
> 
> One day, a group of people petition the company to also specify an
> alternative vault design with only one lock. Their reasoning is: "our
> country prefers designs with one lock." I oppose such a draft because
> (a) their proposed design brings absolutely not a single benefit
> whatsoever over a design that 's been specified, deployed, proven to
> work great, is loved by everyone and has proofs of security, and (b)
> their stated reason for wanting this alternative design is really weak
> and non-technical.
> 
> The leadership of the vault company retort by saying "it's okay, this
> alternative one-lock design will be published as an informative,
> not-recommended draft. We will still recommend that everyone uses the
> dual-lock design." My answer to that would be: "okay, that's nice, but
> still, the single-lock design simply doesn't have any technical merit
> over the dual-lock design! It's strictly worse and simply brings no
> benefit to something we've already deployed for years! So why bother?"

I think it's important to note here that solo PQ was introduced into the
TLS WG based on claims that NSA demands solo PQ and will refuse to
authorize government purchases of ECC+PQ ("that's what they're willing
to buy. Hence, Cisco will implement it"; "CNSA 2.0 compliance"; etc.).
An NSA employee wrote elsewhere that "Our interactions with vendors
suggests that this won't be a problem in most cases". For longer quotes
and links see https://blog.cr.yp.to/20251004-weakened.html#tls.

More and more opposition appeared to solo PQ. There were then unfounded
insinuations that removing ECC from ECC+PQ was important for performance
(see https://blog.cr.yp.to/20260221-structure.html#cost) such as an
absurd claim that high-performance trading needed this.


## Quote 9

Original messages from this author:
* https://web.archive.org/web/20260721020220/https://mailarchive.ietf.org/arch/msg/tls/G8RweFH4IBTBXXSi_nOTAKMI9Vw
* https://web.archive.org/web/20260721020447/https://mailarchive.ietf.org/arch/msg/tls/7tarfPR5lwAs7m4Jmz8YkttnDyM
* https://web.archive.org/web/20260721031056/https://mailarchive.ietf.org/arch/msg/tls/5Ow38mh6RLymbuqfrPtrKRnJUXg
* https://web.archive.org/web/20260721031540/https://mailarchive.ietf.org/arch/msg/tls/wuTdIQ-DY7ypRrmiQwweM3tkcP8
* https://web.archive.org/web/20260721034524/https://mailarchive.ietf.org/arch/msg/tls/KmKLzvawaKtIg8MmVyboXPUSzUY
* https://web.archive.org/web/20260721035039/https://mailarchive.ietf.org/arch/msg/tls/sOOrrG-xLK6Npi-PRUXAqAF4Vas
* https://web.archive.org/web/20260721030704/https://mailarchive.ietf.org/arch/msg/tls/JWUNh_c78VN9LDjpdiqfgPG7bkw
* https://web.archive.org/web/20260721041839/https://mailarchive.ietf.org/arch/msg/tls/7Pn9evR0667rS_0F79vIicqbhJw
* https://web.archive.org/web/20260722031252/https://mailarchive.ietf.org/arch/msg/tls/VQLuOGXRJdaQ1u4G7evLczcIQMk

Yaakov Stein <ystein@allot.com> writes:
> I too strongly oppose publication (for the same reasons as others have
> already articulated).
  [ ... ]
> > Publishing a description of how to do X, when X is something we know
> > people want to do, helps interoperability without hindering people
> > from choosing an alternate approach Y.
> Making a codepoint available but NOT publishing an RFC enables people
> to do something they want to do without implying that the IETF thinks
> it a good idea.
  [ ... ]
> the crux is "no attack has been demosntrated" is not the same as "no
> attack will be found"
  [ ... ]
> And, of course, we shouldn't neglect an undiscovered structural
> weakness in the particular ML-KEM methods (several problems were
> uncovered during the NIST rounds and fixed, but can we be sure all
> attack avenues were found?).
> 
> Maybe all of this is stupid and it will all turn out perfectly secure.
> I truly hope that this is the case.
> 
> All I am saying is that if there is a cheap second lock that protects
> us until we can be sure, then why not use it?????
  [ ... ]
> I once implemented AES (which is trivial compared to Kyber) in FPGA
> and came away with a healthy respect for getting simple things right
> in low level production code.

This quote is addressing cryptanalytic risks, implementation risks,
the low cost of ECC+PQ beyond solo PQ, and the point that many people
understand issuance of an RFC as IETF endorsement.

We've also seen Eric Rescorla in

    https://web.archive.org/web/20260625095524/https://mailarchive.ietf.org/arch/msg/tls/LCtGfIAfsOkuuh5NP7l0wAWUk4A/

admitting this last point: "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.' " See also Quote 4.


## Quote 10

Original messages from this author:
* https://web.archive.org/web/20260721021151/https://mailarchive.ietf.org/arch/msg/tls/TQWcgLnrnPre-3UGeIvVui9wykY
* https://web.archive.org/web/20260721022352/https://mailarchive.ietf.org/arch/msg/tls/xhBaVE91jtiav7RgXeqT_9QKYSQ
* https://web.archive.org/web/20260721031315/https://mailarchive.ietf.org/arch/msg/tls/7Zu7EaI6BkrNItV-fkx-dDtx36I
* https://web.archive.org/web/20260721034636/https://mailarchive.ietf.org/arch/msg/tls/3TQZ_2odBbWvhCp87cWxWnJLZME
* https://web.archive.org/web/20260721034714/https://mailarchive.ietf.org/arch/msg/tls/qq1G_8d2E8mccpWOgUvO2cuc4gY
* https://web.archive.org/web/20260721041645/https://mailarchive.ietf.org/arch/msg/tls/2NV6U7BccBftXZEMy8zypjgXbbQ

Patrick Duc <patrick.duc2@gmail.com> writes:
> I do not support the publication of this document.
  [ ... ]
> In case of an implementation error that would lead to a vulnerability,
> then an attacker would need to find two implementation errors : one
> for ECC, one for ML-KEM. Otherly said, and AFAIK, finding an
> implementation error would not break the hybrid solution.
> Besides, regarding implementation flaws, ML-KEM implementations have
> not yet stood the test of time like ECC implementations have. And you
> really want to rely on only on ML-KEM ? In particular in the frame of
> SNDL ?

This quote is highlighting the way that downgrading from ECC+PQ to solo
PQ adds exposure to PQ implementation flaws.

Does IETF say "a very large majority of those who care must agree,
except that people like Patrick Duc can be ignored"?


## Quote 11

Original message from this author:
* https://web.archive.org/web/20260720021216/https://mailarchive.ietf.org/arch/msg/tls/Err40FOTKRJkd1x5sKsV0cH4ZKs

Christian Grothoff <grothoff@gnu.org> writes:
> I do not support the publication of this document.
> Best regards,
> Christian Grothoff, PhD (UCLA)

This is an example of an opposition statement that obeyed the chair
demand to just say yes or no. Does the conciseness of this objection
mean that the chairs discarded it as not demonstrating "expertise"?
Google Scholar shows more than 4000 citations to Christian Grothoff's
work.

More to the point, does IETF say "a very large majority of those who
care must agree, except that people like Christian Grothoff can be
ignored"?


## Quote 12

Original message from this author:
* https://web.archive.org/web/20260721024717/https://mailarchive.ietf.org/arch/msg/tls/mKFzPpIGOZOov0Ndm4-Gb2tG-oA

Leonid Shamis <shamis.leonid@gmail.com> writes:
> I would like to register my strong objection to the publication of this
> document.
> Hybrid ("double encryption") constructions protect us from classes of
> attacks that pure-PQ constructions do not protect us against. Hybrid
> constructions have a negligible overhead compared to pure-PQ constructions.

In other words: Downgrading from ECC+PQ to solo PQ adds exposure to PQ
attacks that would otherwise face the attacker with the problem of
breaking ECC. The downgrade produces negligible cost savings.


## Quote 13

Original messages from this author:
* https://web.archive.org/web/20260721024837/https://mailarchive.ietf.org/arch/msg/tls/wB2mPlX4XU6FlkEZjzkuAboLt7s
* https://web.archive.org/web/20260701193845/https://mailarchive.ietf.org/arch/msg/tls/a6uZ6otdF21I2N9CFAPOIh_FcPI
* https://web.archive.org/web/20260721042618/https://mailarchive.ietf.org/arch/msg/tls/ezwSVswZfK_HDfEYE2766Z4rjKc
* https://web.archive.org/web/20260722044026/https://mailarchive.ietf.org/arch/msg/tls/W80LhMt4BAgyGfAjVy50XpzmHig
* https://web.archive.org/web/20260722050557/https://mailarchive.ietf.org/arch/msg/tls/vO5S15r8AGYfe1FsWS8lyuJW-Fk
* https://web.archive.org/web/20260722183634/https://mailarchive.ietf.org/arch/msg/tls/gvgXK4UMlTklKXuphGbeYqZRYFM
* https://web.archive.org/web/20260722195622/https://mailarchive.ietf.org/arch/msg/tls/jHRW5htCIrLeAoA_gsFb85TO1h0
* https://web.archive.org/web/20260722201759/https://mailarchive.ietf.org/arch/msg/tls/IICb-ZkQC-lkFPcj0NMpf3Ym7OA
* https://web.archive.org/web/20260722214705/https://mailarchive.ietf.org/arch/msg/tls/MdZeJQb7KEuEsNNzynxACIfe3eA

Peter Gutmann <pgut001@cs.auckland.ac.nz> writes:
> mark@reviewcommit.com writes:
  [ ... ]
> Everything Mark said.
  [ ... ]
> We have essentially zero deployment experience with ML-KEM compared
> to RSA, DH, ECDSA, etc.  If every single other one of those algorithms is
> anything to go by, we've still got decades of problems with ML-KEM ahead of
> us.
  [ ... ]
> Uhh... ML-KEM and constrained devices?  The ML-KEM code I'm using, the very
> nice mlkem-native cut down to only do -768, is about the same size as all the
> other crypto code I've got (AES, (3)DES, SHA-1, SHA2, Poly1305, ChaCha, CAST,
> IDEA - yeah, for PGP) put together.  The only time you can put "ML-KEM" and
> "constrained devices" in the same sentence is if the words in between them are
> "totally unsuited for".

The first part of this quote is adopting Mark Atwood's objection to the
document, based on cryptanalytic risks. The second part is looking at
"deployment", a perspective that also includes implementation risks. The
third part is challenging (unsubstantiated) claims that removing ECC from
ECC+ML-KEM in TLS is necessary to fit into (unspecified) small devices.


## Quote 14

Original message from this author:
* https://web.archive.org/web/20260721025118/https://mailarchive.ietf.org/arch/msg/tls/xLizHAckIpiWeTNFJQZYwkl2rqY

mStar <me@mstar.dev> writes:
> I'd like to voice my very clear objection to the release of the
> drafted document due to security concerns.
> Kind regards
> Melody

See my earlier comments regarding real-name policies.


## Quote 15

Original messages from this author:
* https://web.archive.org/web/20260701194830/https://mailarchive.ietf.org/arch/msg/tls/RbpRQbHkEizsM8P9XeyBzIm2Bpw
* https://web.archive.org/web/20260721030314/https://mailarchive.ietf.org/arch/msg/tls/-ToiPhUCo2paBEOM3_wuO7cUN0g
* https://web.archive.org/web/20260722033936/https://mailarchive.ietf.org/arch/msg/tls/pdWul5h9xirgxCojZfYOCl4FqzU
* https://web.archive.org/web/20260722034131/https://mailarchive.ietf.org/arch/msg/tls/RSdbZ19Ecl26GHUaxfiHxdw7WHQ
* https://web.archive.org/web/20260722034543/https://mailarchive.ietf.org/arch/msg/tls/zI8e-XBbeB2oXtK0-cwFl5xZty0
* https://web.archive.org/web/20260722035507/https://mailarchive.ietf.org/arch/msg/tls/3vq5NpEYK-iEpUEnuqrM1FN7Lrs
* https://web.archive.org/web/20260722181307/https://mailarchive.ietf.org/arch/msg/tls/IQaQz2RGk8LSOQDU8pSKRBkUJeY
* https://web.archive.org/web/20260722213810/https://mailarchive.ietf.org/arch/msg/tls/DzKqY4cZf4n33LoRUEa3KieC2go
* https://web.archive.org/web/20260722214015/https://mailarchive.ietf.org/arch/msg/tls/je0NBZxhDRBsTDOCN1WFEIJE8PA

Orr Dunkelman <orrd@cs.haifa.ac.il> writes:
> Due to numerous reasons discussed in this mailing list, I strongly object
> to the publication of the document.
  [ ... ]
> In many instances people just follow the standards, RFC,
> ISO, ETSI, and don't care whether they are informational, mandatory, or
> otherwise just a standard that is there. Many people view this as a seal of
> approval by some standardization body. And I believe that such seals should
> be given less promiscuously.
  [ ... ]
> there is a noteworthy security downgrade - the new
> proposal offers less algorithmic security, and increases the chances of a
> black-swan events.
  [ ... ]
> Obviously, this is a risk-management decision - and I personally prefer the
> more cautious approach (and thus, I object to the publication).

This quote is emphasizing the cryptanalytic risks, along with the fact
that many people treat issuance of an RFC as IETF endorsement.


## Quote 16

Original messages from this author:
* https://web.archive.org/web/20260721025546/https://mailarchive.ietf.org/arch/msg/tls/-HW1O5j8mxLNBG__KqffUVH1q54
* https://web.archive.org/web/20260721030554/https://mailarchive.ietf.org/arch/msg/tls/giOzKq9rb0a1EcGR-Xy_yXadlkk

Shane Killian <shane@shanekillian.org> writes:
> Due to major security concerns discussed elsewhere in this mailing list, 
> I strongly object to the publication of this document.
  [ ... ]
> PQ algos are currently not strong 
> enough to stand on their own against classical attacks. Cloudflare's 
> experience with SIKE is evidence of this; the fact that they used a 
> hybrid protocol is what protected them and their customers. I think it 
> is irresponsible at this time to push for PQ alone, compared to hybrids 
> that give the full protection currently afforded by ECC.

Beyond my general statement of agreement with the quotes that I'm
giving, let me emphasize specifically that I agree with "not strong
enough".

Proponents of solo PQ commonly misunderstand the words "strong" and
"weak" to be referring narrowly to the question of how fast known
attacks are. These blinders make it impossible to see in advance how
removing ECC from ECC+PQ is weakening protection for the end user.

The same blinders would, for example, have incorrectly declared at the
time of the SIKE deployment that solo SIKE is as strong as ECC+SIKE;
would have foolishly advocated using solo SIKE on this basis; and would
not have recognized the error until after SIKE was publicly broken.


## Quote 17

Original message from this author:
* https://web.archive.org/web/20260721025802/https://mailarchive.ietf.org/arch/msg/tls/Wpnp6GJXQYz_S09qaKHmTPhraLE

Lauren Amsterdamer <laurenamsterdamer@gmail.com> writes:
> I do *not* support the publication of this document per the security
> concerns listed time and time again.

See my earlier comments regarding real-name policies.


## Quote 18

Original message from this author:
* https://web.archive.org/web/20260721030541/https://mailarchive.ietf.org/arch/msg/tls/fMwZwW3E4vBEZ-8H38MgaHNMURA

Willow Liquorice <willow@howhill.com> writes:
> Do not publish this document. Enabling state SIGINT harms everyone.

See my earlier comments regarding real-name policies.


## Quote 19

Original message from this author:
* https://web.archive.org/web/20260721030940/https://mailarchive.ietf.org/arch/msg/tls/shWdhveBpvTPu0TzRARHAZdAlTM

Frieder Hannenheim <ietf_tls@fhannenheim.net> writes:
> I do not support the publication of this document. In my opinion ML-KEM 
> does not exist long enough to warrant adoption into the TLS 1.3 family 
> of cipher suites alone. This can be done once a cryptographically 
> relevant quantum computer exists and is widely accessible, since the ECC 
> part is easily breakable then.

I think the numbers in https://blog.cr.yp.to/20240102-hybrid.html help
visualize this: "Concretely, think about a demo showing that spending a
billion dollars on quantum computation can break a thousand X25519 keys.
Yikes! We should be aiming for much higher security than that! We don't
even want a billion-dollar attack to be able to break _one_ key! Users
who care about the security of their data will be happy that we deployed
post-quantum cryptography. But are the users going to say 'Let's turn
off X25519 and make each session a million dollars cheaper to attack'?
I'm skeptical. I think users will need to see much cheaper attacks
before agreeing that X25519 has negligible security value."


## Quote 20

Original message from this author:
* https://web.archive.org/web/20260721033033/https://mailarchive.ietf.org/arch/msg/tls/HLNUyDtgePiB40im74MCyzGogxw

Abhinav Gottumukkala <anak4569@gmail.com> writes:
> I do not support the publication of this document. I have yet to see a
> cogent argument for why hybrid systems would be less secure or
> non-trivially less performant than purely post-quantum systems.

Indeed, removing ECC from ECC+PQ adds risks while having negligible
performance benefit.


## Quote 21

Original message from this author:
* https://web.archive.org/web/20260721033227/https://mailarchive.ietf.org/arch/msg/tls/BbQntL8_MpiwiSBmtyXg0lUmDLU

Christian Kuehne <demian@fiff.de> writes:
> I have followed the discussions on the mailing list for a long time and 
> I do not support the publication of this document. 

See https://www.computer.org/csdl/proceedings-article/csp/2022/797500a016/1FRKJ5iiC0U
for an example of Christian Kuehne's background.

This is another case of a very short message from someone following the
chair demands to just say yes or no. Did the chairs disenfranchise him
because he didn't say more? Does IETF say "a very large majority of
those who care must agree, except that people like Christian Kuehne can
be ignored"?


## Quote 22

Original message from this author:
* https://web.archive.org/web/20260721031853/https://mailarchive.ietf.org/arch/msg/tls/b5QLcyGgu9Vil7Cml8DROPYvsn0

Martin Guy <martinwguy@gmail.com> writes:
> Hi all, just to let you know that I do not support the publication of 
> this document, redolescent of the 56-bit ciphers and clipper chips of 
> the past.

56-bit DES and the Clipper chip are classic examples of NSA-driven
weakening of cryptography. Note that these two examples have different
types of weaknesses: the Clipper chip was designed with a special key
for NSA to exploit (Dual EC was also like that but with an effort to
conceal the weakness); the primary weakness of 56-bit DES was simply
that its key size was too small.


## Quote 23

Original message from this author:
* https://web.archive.org/web/20260721033820/https://mailarchive.ietf.org/arch/msg/tls/ubTUWWrx3apR8CjMQ1XqoWaAFJg

michael@gouin.xyz writes:
> I'm opposed to the publication of this document. We can't trust ML-KEM
> to stand on its own against classical attacks yet. The hybrid approach
> is more secure and worth the 3% cost during key exchange.
> 
> After Q-Day, hybrids are still more secure for a while. Because if an
> actor breaks the post quantum part, he may not have access to the
> quantum hardware that breaks the classical part yet. We should drop
> ECDHE only when quantum computers are ubiquitous.
> 
> Michael Gouin

The first part of this quote highlights the ML-KEM risks and the low
cost of keeping ECC. The second part highlights that the existence of a
quantum computer breaking _some_ ECC keys still won't eliminate the
value of ECC.

Does IETF say "a very large majority of those who care must agree,
except that people like Michael Gouin can be ignored"?


## Quote 24

Original message from this author:
* https://web.archive.org/web/20260721033855/https://mailarchive.ietf.org/arch/msg/tls/rKvghQtWpjlSbCkn0IIB9D2XElQ

Patrick Dalrymple <patrick@lyria.io> writes:
> I vehemently object to the NSA's proposition.
  [ ... ]
> Patrick Timothy Dalrymple
> Founder & CEO, LYRIA

See https://blog.cr.yp.to/20251004-weakened.html#tls for evidence
justifying the attribution of this push to NSA.

Does IETF say "a very large majority of those who care must agree,
except that people like Patrick Dalrymple can be ignored"? Does a
small-business owner have less of a voice in IETF than an NSA employee?


## Quote 25

Original message from this author:
* https://web.archive.org/web/20260721034245/https://mailarchive.ietf.org/arch/msg/tls/nuUncoYtF5XjfY5HwbVav-syviA

Andrey <solaris700@gmail.com> writes:
> I do not support the publication of this document. Please adopt a
> hybrid approach.
> 
> Andrey Lundin

The first sentence makes clear that "adopt" in the second sentence
refers to IETF's selection of what will become an RFC, not to internal
IETF jargon where "adopt" refers to a WG decision to work on something.


## Quote 26

Original message from this author:
* https://web.archive.org/web/20260721034324/https://mailarchive.ietf.org/arch/msg/tls/3fLWgSou5DyQ1f8qpgebCTzHi3A

Nicola Lazzari <mr.nicola.lazzari@gmail.com> writes:
> Voicing my opposition to this renewed 'last call' on tls-mlkem RFC
> publication.
> 
> The risks outweigh the potential benefits of using this algo, where
> the TLS-ECDHE-MLKEM is already active and there is novel PQ work
> happening in cryptography.

This is emphasizing the poor benefit-risk tradeoff of this spec.


## Quote 27

Original message from this author:
* https://web.archive.org/web/20260721034753/https://mailarchive.ietf.org/arch/msg/tls/aCGnSG57jNkNVINgHj9WLGowSHI

Adam Firestone <adam@six3ro.com> writes:
> I oppose the publication of this document for reasons already ably
> stated.
> 
> Many thanks,
> 
> Adam Firestone
> SIX3RO, Inc.

Does IETF say "a very large majority of those who care must agree,
except that people like Adam Firestone can be ignored"?

After the chairs called for people to just say yes or no, and then
posted things like "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", did the chairs use the brevity of Adam Firestone's
message to conclude that he hadn't demonstrated expertise?

Did the chairs look online for evidence of expertise? I find, e.g., the
following: "Adam Firestone, CEO and Co-Founder of SIX3RO, drives the
company's strategic vision to deliver quantum-secure communications and
information exchange. With 30 years of expertise in systems engineering,
cryptography, decentralized systems, and entrepreneurship, he has led
the design and delivery of national security and commercial solutions
that enhance efficiency and empower enterprises."


## Quote 28

Original message from this author:
* https://web.archive.org/web/20260721034958/https://mailarchive.ietf.org/arch/msg/tls/YTu5TKS6VR_OuSmfa1HFJD3o-eg

Alexandr Burdiyan <burdiyan@gmail.com> writes:
> I do not support publishing this document.

Does IETF say "a very large majority of those who care must agree,
except that people like Alexandr Burdiyan can be ignored"?


## Quote 29

Original message from this author:
* https://web.archive.org/web/20260721035620/https://mailarchive.ietf.org/arch/msg/tls/MWQ1mNe8Z79DVGqlJF-Xq6-UMjE

Ludovic Perret <ludovic.perret@epita.fr> writes:
> Similarly, I oppose the publication; the reasons have already been 
> explained and debated.
> Ludovic Perret
> EPITA/Sorbonne University

Even though each of the stories from the chairs would imply that they
counted Ludovic Perret if they actually followed that story (since he
had posted to the TLS mailing list before), the fact that the chair
stories aren't consistent means that one has to ask whether the chairs
counted him.


## Quote 30

Original messages from this author:
* https://web.archive.org/web/20260721035851/https://mailarchive.ietf.org/arch/msg/tls/42BprJiOCWNr9tNuixoOR-IY_Pk
* https://web.archive.org/web/20260722035250/https://mailarchive.ietf.org/arch/msg/tls/HMJ088HhBp5HlPLQh-OoQ3WStCU

Justin Schnurbusch <schnurbusch.justin@web.de> writes:
> I do not support the publication of this document as it seems to me
> that the implementations "in the field" need a currently secure
> baseline as a mandatory border.

Indeed, adding PQ in the hopes of protecting against quantum attacks
shouldn't change the fact that ECC is mandated for every connection.


## Quote 31

Original message from this author:
* https://web.archive.org/web/20260721040500/https://mailarchive.ietf.org/arch/msg/tls/sbXARP74r1ZwIMk02t2Z2jaD1mw

Bertrand Jacquin <bertrand@jacquin.bzh> writes:
> I have read draft-ietf-tls-mlkem-08. For the record: I do not
> support publication of a standards-track document specifying
> standalone ML-KEM key establishment for TLS 1.3.
  [ ... ]
> The proposal s a large bet on a young primitive. FIPS 203 was finalized
> in 2024; lattice KEM cryptanalysis is far less mature than the decades
> behind X25519 and the NIST P-curves. We have recent reminders that
> "post-quantum" does not mean "safe": the 2022 classical break of SIKE
> (Castryck-Decru) destroyed a scheme that had survived years of NIST
> scrutiny, and the KyberSlash timing side channels (2023-2024) showed
> that even reference ML-KEM code shipped exploitable secret- dependent
> behaviour. None of this says ML-KEM is broken. It says betting the
> confidentiality of the Internet's most important security protocol on a
> single new primitive, with no fallback, is imprudent when the fallback
> costs almost nothing.
> 
> And it does cost almost nothing. The classical half of the hybrid is 32
> bytes and one X25519 scalar multiplication, lost in the noise next to
> ML-KEM-768's ~1.1 KB public key and ciphertext. There is no performance
> case for dropping it. The tradeoff is trivial cost against catastrophic,
> retroactive downside. For TLS, that asymmetry alone settles it.

I think it's important to note here that IETF uses remarkably confusing
terminology.

IETF prominently advertises itself as "the premier standards development
organization (SDO) for the Internet". IETF says that it "publishes its
technical documentation as RFCs". Every RFC issued by every IETF working
group (after IESG approval) is labeled as "consensus of the IETF
community". Corporate purchasing managers understand "RFC" to mean
"Internet standard".

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. The rest are just "proposed standards" or "informational" or
some similar weaseling.

The actual effect of draft-ietf-tls-mlkem is to extend IETF's TLS
_standard_ to allow solo ML-KEM as an alternative to the common-sense,
widely deployed ECC+ML-KEM. See

    https://web.archive.org/web/20260721031429/https://mailarchive.ietf.org/arch/msg/tls/muKBRDoLZ1vdnQe_SIKfcBjBkr8/

for a document proponent accurately describing the draft as a "draft
standard" and accurately describing an RFC as adding power to 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!

Bertrand Jacquin is accurately describing publication of this document
as standardization, and is unambiguously objecting to that. IETF's
doublespeak doesn't change the facts.

The main content of the quote says how unwise it is to remove a low-cost
mitigation against PQ security failures. The quote cites the destruction
of SIKE. It also cites some of the security flaws found so far in ML-KEM
software. Regarding cost, the communication cost and computation cost of
ECC are minor next to the communication cost of ML-KEM, never mind the
overall costs of TLS.


## Quote 32

Original messages from this author:
* https://web.archive.org/web/20260721040709/https://mailarchive.ietf.org/arch/msg/tls/H2jQkeEBk4ODLOqC2vyWrqEigzA
* https://web.archive.org/web/20260721040829/https://mailarchive.ietf.org/arch/msg/tls/r5uAFA8vO2956LbTPoldGV-ACx0
* https://web.archive.org/web/20260721041119/https://mailarchive.ietf.org/arch/msg/tls/hkqedq6eqtnYukL8L2CrMOku1TI
* https://web.archive.org/web/20260722044518/https://mailarchive.ietf.org/arch/msg/tls/0KXcI7-afJC1hlDFs-Hy87BkRY8
* https://web.archive.org/web/20260721044200/https://mailarchive.ietf.org/arch/msg/tls/mB6skqX9wjK9-oes2Y36iKNP9W8
* https://web.archive.org/web/20260722034056/https://mailarchive.ietf.org/arch/msg/tls/RiRY3vQcAtkxUTYZtz8UcERz-eI
* https://web.archive.org/web/20260722040603/https://mailarchive.ietf.org/arch/msg/tls/kMU5ej9Hxrl6JR6QFj-87G30k48
* https://web.archive.org/web/20260722041313/https://mailarchive.ietf.org/arch/msg/tls/6TBwjuxojRu5BbhSozWG8doLmG8
* https://web.archive.org/web/20260722041814/https://mailarchive.ietf.org/arch/msg/tls/oey-xnzQcDNeljblL-RHefNdPmQ
* https://web.archive.org/web/20260722042247/https://mailarchive.ietf.org/arch/msg/tls/Sm7lse5BTPxv2eoW-NIThbZ6u-4
* https://web.archive.org/web/20260722042608/https://mailarchive.ietf.org/arch/msg/tls/zg-t6ygkCWCtPSfHNL-UMCupwd8
* https://web.archive.org/web/20260721021907/https://mailarchive.ietf.org/arch/msg/tls/zMw7QZ46vncG5OkY9cwDBmClsGo
* https://web.archive.org/web/20260722045508/https://mailarchive.ietf.org/arch/msg/tls/ozmAbuEzf7yJ9vLrtbbBx_TbGXY
* https://web.archive.org/web/20260721020249/https://mailarchive.ietf.org/arch/msg/tls/rv5ZFrSegHSqSm2kXoRQQ88wAN0
* https://web.archive.org/web/20260722052609/https://mailarchive.ietf.org/arch/msg/tls/JOw-ayDis3XGk6X8DGtQdmO8Qao
* https://web.archive.org/web/20260722053942/https://mailarchive.ietf.org/arch/msg/tls/QPUFJxNllUwIkfJaYp3f-bt5BWU
* https://web.archive.org/web/20260722200036/https://mailarchive.ietf.org/arch/msg/tls/lcclWss5MnJ5BtFYi9AiZB5KK1U

Rob Sayre <sayrer@gmail.com> writes:
> That's not the argument, though.  It's that classical attacks might break
> the PQ algorithms. Something that has already happened.
  [ ... ]
> it seems kind of curious
> not to do ECC no matter what you think. What's the reasoning there? It's
> not costly, who cares.
  [ ... ]
> I do not support publication of
> this document by the TLS WG or the IETF.

This quote highlights the cryptanalytic risks of switching from ECC+PQ
to solo PQ, along with the negligible benefit.

Proponents typically downplay the risks by focusing narrowly on cases
that _haven't_ been broken. That's not how risk management works.


---D. J. Bernstein


===== NOTICES =====

IETF BCP 78, "Rights Contributors Provide to the IETF Trust", Section 5
(normative), "Rights in Contributions", provides a modification right
"unless explicitly disallowed in the notices contained in a Contribution
(in the form specified by the Legend Instructions)".

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" is as follows: "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."
<https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf>

That language hereby applies to this document. This is not disclaiming
or limiting the applicability of IETF policies; it is strictly following
IETF policies. IETF has similarly published, e.g., RFC 7425, which says
the following: "This document may not be modified, and derivative works
of it may not be created, except to format it for publication as an RFC
or to translate it into languages other than English."

IESG claims that the "explicitly disallowed" provision in BCP 78 is
limited to the examples in Section 3 in BCP 78. That is incorrect. BCP
78 states that Section 5, "Rights in Contributions", is normative, while
Section 3, "Exposition of Why These Procedures Are the Way They Are", is
informative. The opt-out provision in the normative text is clear, and
cannot be limited by an informative section. BCP 78 does not give IESG
any authority to issue changes or purported clarifications of the rules.

IETF Executive Director Jay Daley says that informative text can
"contextualise and disambiguate normative text as it does here". When he
was asked what he claimed was ambiguous about the BCP 78 "explicitly
disallowed" provision, he did not reply. There is no ambiguity, and an
"Exposition of Why These Procedures Are the Way They Are" is not a
change to the procedures.

Rationale for exercising the BCP 78 opt-out provision: I'm fine with
redistribution of copies of this document. However, BCP 78's default
position, without the opt-out, is a power grab that goes far beyond
redistribution and far beyond what copyright law allows as fair use
(such as giving quotes for purposes of commentary). BCP 78 authorizes
arbitrary modifications, such as plagiarism, quote falsification, data
falsification, and IETF management selling IETF mailing-list text in
bulk to AI companies spreading further misinformation.

For example, Google, a major source of IETF funds, systematically
ingests IETF mailing-list text into its AI system, which modifies the
text and frequently spits out misinformation to readers. IETF is only
one of many terms-of-service battlegrounds; this is not a reason to skip
the battle.

IETF itself also carries out problematic modifications. For example, in
May 2025, IESG posted an IESG-mangled version of an appeal that I had
filed, and then in its response confused exactly the point obfuscated by
that mangling. When I complained about the mangled document, the IETF
Executive Director responded not by apologizing but instead by asserting
that IETF management had the power to do whatever it wanted.