This is the third in a series of four messages responding to IESG's
"last call" for draft-ietf-tls-mlkem. Please see the first and second
messages for important context. In particular, the general requests in
the second message regarding each quote apply to the quotes here too.

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 33

Original messages from this author:
* https://web.archive.org/web/20260721041207/https://mailarchive.ietf.org/arch/msg/tls/g2JIyULihGxzNTDhhgl1MabOnYM
* https://web.archive.org/web/20260721030911/https://mailarchive.ietf.org/arch/msg/tls/mG_sNqlFsSWVrpUL-0ZuZlFPXPc
* https://web.archive.org/web/20260722185750/https://mailarchive.ietf.org/arch/msg/tls/RQ08aT-apUT6QTG3qFu5GPPcb-M
* https://web.archive.org/web/20260722211947/https://mailarchive.ietf.org/arch/msg/tls/qnudL_jKVprROO2flnoOpslJFJg
* https://web.archive.org/web/20260722213500/https://mailarchive.ietf.org/arch/msg/tls/e6lRk3nT5WDulZKj20gjMGwvRwk
* https://web.archive.org/web/20260722215153/https://mailarchive.ietf.org/arch/msg/tls/DJkip-apHiVdOCol1YV2rtFe940
* https://web.archive.org/web/20260722215400/https://mailarchive.ietf.org/arch/msg/tls/HevWZh2pRHNutXoAdaBa4X1vAeU

Tanja Lange <tanja@hyperelliptic.org> writes:
> You mean the competition where Rainbow got broken in February 2022, a few
> months after the end-of-2021 date which NIST had announced as the planned end
> of the competition? Where GeMSS had its underlying hardness assumption pulled
> out under it in November 2020? Where we're having an entire extra competition
> on signatures because of this? Where an IND-CCA2 issue in HQC was found after
> it was selected for standardization? Not to mention all the other systems that
> went down along the away, despite being seemingly based on solid assumptions.
> Did you count how many of them used lattices?
  [ ... ]
> In the short term I'm more concerned about implementation errors, given the
> scale of the new rollout, and consider it reckless to give up on existing
> protections that have gone through years of vetting and fixes. In the long run
> I'm not convinced that what we'll switch to after ECC + ML-KEM is ML-KEM, it's
> much more likely that by then we'll have a different system -- in the
> optimistic case because we can do so much better (already now we have systems
> that are smaller and/or faster and based on the same ideas as Kyber, 9 years
> more of research make a difference), and in the pessimistic case because we
> need to increase the parameters or even move to a different system. I don't
> like the term "agility" and have complained about the misunderstandings it
> creates, but any change in systems now should be done in a way to make the
> next one easy.
  [ ... ]
> I do not support publishing this document.
> 
> I do not see any of my concerns addressed by the changes, nor do I see any
> acknowledgment of those concerns in the document. For reference, see below for
> one of my emails from the previous last call.
  [ ... ]
  [ incorporated comments from the second WGLC: ]
> I think it is irresponsible of the WG to publish an RFC that encourages risky
> behavior. Users will take the reputation of the IETF and understand this as a
> recommendation, whether it says = N or not. As much as I like PQC and push for
> its adoption asap because we're too late (not my fault), I also warn about
> stability and code quality and we must acknowledge that. I love formally
> verified software like everybody else and it's the best we can do, but also
> that is still a research area and we are currently in a situation where code
> can be formally verified and have bugs at the same time. That's not even
> addressing the mathematical stability of the problems. Still, it's better to
> add ML-KEM than not deploying it, but please not without ECC. I can't stop
> people from shooting themselves in the foot but I don't want the WG to cause
> this.
> 
> If I understand the email from Keegan correctly then we have a perfect example
> of the damage that this RFC can be causing as the Canadian government seems to
> be waiting for this RFC in order to recommend ditching hybrids in favor of
> fully exposed PQC. It's not hypothetical that people would ignore the = N, we
> have a stated intention on list. [And before I get the mansplaining: yes, I'm
> aware of the CA publication already including the option for exposed PQC. I'm
> also aware that that document has been referenced as motivation for the draft
> (though sold as regulation there). What was interesting to me from the email
> was that it sounds like this becoming an RFC carries more weight for them and
> will impact ther recommendations. That would then be our fault.]

The first point in the above quote is pointing to various examples of
security failures in high-profile post-quantum proposals, contrary to
the notion that SIKE was an isolated example.

The quote continues by pointing out implementation flaws in the short
term and the likelihood of ML-KEM being superseded in the long term.

The second-WGLC comments included in the quote address implementation
issues, verification deficiencies, cryptanalytic risks, and the
wimpiness of "Recommended: N".

The "sold as regulation" comment is referring to an incident in which

    https://web.archive.org/web/20260323162910/https://mailarchive.ietf.org/arch/msg/tls/pT4d0ND0cP2iEKMsdt02lknmZJQ/

argued for solo PQ by portraying CSE ITSP.40.111 as a "regulatory
reference" prohibiting ECC+PQ. That's doubly wrong:

    * CSE ITSP.40.111 isn't a regulation; it merely states "recommended
      cryptographic algorithms".

    * CSE ITSP.40.111 doesn't give ECC+PQ a lower status than solo PQ.

What's pernicious about this type of peer-pressure argument is the
circular evasion of responsibility: a fabricated CSE requirement is used
to push solo PQ within IETF, and then if solo PQ is endorsed by IETF
then that will be used to justify CSE adding a recommendation based on
that RFC.

IETF should in any case be categorically rejecting rubber-stamping
requests. "IETF participants use their best engineering judgment to find
the best solution for the whole Internet, not just the best solution for
any particular network, technology, vendor, or user."


## Quote 34

Original messages from this author:
* https://web.archive.org/web/20260721042505/https://mailarchive.ietf.org/arch/msg/tls/ebO-XDf2_dsJmekTCYjCJccrK8U
* https://web.archive.org/web/20260722052928/https://mailarchive.ietf.org/arch/msg/tls/Ue3tOfsOCKkQWX2DlYwnmweo8Zk
* https://web.archive.org/web/20260720021449/https://mailarchive.ietf.org/arch/msg/tls/NsCcR56vN7v_IIwSrHK5Zv2L7Iw

Stephan Neuhaus <neut@zhaw.ch> writes:
> I do not support the publication of this document.
> 
> I remember well that security standards get broken: when they have been 
> well-reviewed, but especially when they're new. Bugs show up in the 
> math, but also in implementations. Lattice cryptography seems to me to 
> be a very active field of research, when quite fundamental results (and 
> bugs!) are still being discovered, both in the math and in the 
> implementations. From a risk-management perspective alone, I believe 
> that it's too risky to standardise, even as "informational", a mode of 
> encryption that relies only on these new methods.
  [ ... ]
> Perhaps to illustrate my point, WolfSSL has received a CVE for a bug in 
> ML-KEM on https://nvd.nist.gov/vuln/detail/CVE-2026-10097.

Notice the accurate description of an "informational" RFC as a standard,
even if IETF doublespeak uses different terminology. See my comments on
this doublespeak under Quote 31.

CVE-2026-10097 is just one example of newly discovered bugs. There will
be more and more bugs. Studies of hundreds of bugs in cryptographic
libraries show that roughly 1/8 of "cryptographic" bugs are severe. The
quote also covers mathematical risks.


## Quote 35

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

Roald Van Glabbeek <roald.van.glabbeek@vub.be> writes:
> I do not support the publication of this document, it seems plain
> sabotage.

A secret NSA document

    https://www.eff.org/files/2014/04/09/20130905-guard-sigint_enabling.pdf

from 2013 showed that NSA already had a quarter-billion-dollar-a-year
budget for NSA's SIGINT Enabling Project, which "actively engages US and
foreign IT industries to covertly influence and/or overtly leverage
their commercial products' designs" to make the designs "exploitable ...
To the consumer and other adversaries, however, the systems' security
remains intact."

A specific goal in that budget document is to "Influence policies,
standards and specification for commercial public key technologies".
This tells us that NSA spends money to "covertly influence and/or
overtly leverage" cryptographic standards.

Obviously this doesn't mean NSA saying "Hi, this proposal damages
security, please adopt it". Instead NSA's fully owned "cybersecurity"
division and external intermediaries build trust by investing in some
non-controversial work---trust that NSA then exploits to insert
vulnerabilities while "the consumer and other adversaries" think "the
systems' security remains intact."

As defenders, we don't know in advance which of NSA's "cybersecurity"
contributions are exploitable. There are sometimes years of delay before
the public figures out how to exploit an NSA proposal. But if we're
seeing a poorly justified NSA-driven proposal to remove a defense
mechanism then Occam's Razor says that this is plain sabotage.


## Quote 36

Original messages from this author:
* https://web.archive.org/web/20260722050333/https://mailarchive.ietf.org/arch/msg/tls/VW_hwAYt_-XQ4G4yHnciJe_UF90
* https://web.archive.org/web/20260722050026/https://mailarchive.ietf.org/arch/msg/tls/wcX5g2yDFskXbZWnDw_KpkVfzVo

Charles Cazabon <charlesc-ietf.org@pyropus.ca> writes:
> I do not support publishing this document.
> 
> The costs of using PQ+ECC are known and minimal, while providing
> significant "belt and braces" backup security practices if the PQ
> primitive fails.  This document advocates removing that backup for no
> clear benefit and significant additional risk.  Given the chances that
> the PQ specification and implementation are both not subject to future
> successful attacks are approximately zero, I see no reason to
> recommend anyone implement PQ without an ECC backup.

This quote considers both cryptanalytic risks and implementation risks,
and emphasizes how unlikely it is for PQ deployment to manage to avoid
all security failures. ECC+PQ mitigates that risk.

The word "recommend" here can easily trigger document proponents to say
"it's not recommended!", which is again missing the reality that many
people understand the text "consensus of the IETF community" or the mere
issuance of an RFC to mean IETF endorsement.


## Quote 37

Original messages from this author:
* https://web.archive.org/web/20260721044432/https://mailarchive.ietf.org/arch/msg/tls/M8ENvPohKoUCdnQ3ozWZ4qd4xNU
* https://web.archive.org/web/20260722034953/https://mailarchive.ietf.org/arch/msg/tls/nGkT5rSpFnMHDeH5NEP_0b_UKTw

Travis Burtrum <travis.ietf@burtrum.org> writes:
> I do not support the publication of this document. Hybrid ECDHE-MLKEM 
> has already been published and implemented and if MLKEM is safe and 
> secure then that is too, only downsides come from having even an option 
> to do stand-alone MLKEM, with no upsides.
  [ ... ]
> PS: New joiner to this mailing list, but old hand at creating internet 
> standards (so far a few XEPs at XMPP Standards Foundation), finding and 
> fixing security bugs and in open source projects, and 
> writing/contributing my own open source code.
  [ ... ]
> Surely if anyone knew for sure ML-KEM was broken they'd bring that up, 
> but "cannot be trusted" is a different thing.  Obviously we've seen tons 
> of standardized crypto over the decades that everyone thought was secure 
> and then it turned out was broken.  So let me turn it around and ask you 
> a question, are you absolutely 100% sure without any doubt whatsoever 
> that both ML-KEM and these specs are completely secure forever?  If not 
> (and I'm not sure how anyone could be) it's only sensible to hedge 
> against this, which is why only hybrid should exist and this 
> draft-ietf-tls-mlkem should not be published.

The first part of this quote highlights the lack of benefit of this
spec. The last part highlights the cryptanalytic risk, and emphasizes
that the goal is to proactively protect against breaks, not merely to
avoid things known to be broken.

Does IETF say "a very large majority of those who care must agree,
except that people like Travis Burtrum can be ignored"? He's correcting
a common proponent error of conflating security with the absence of
known attacks; why should a proponent persisting in this mistake be
counted more heavily than someone correcting this mistake?


## Quote 38

Original message from this author:
* https://web.archive.org/web/20260722030155/https://mailarchive.ietf.org/arch/msg/tls/e3Pza5vl_T2JGezfwzQu-zisu0c

Koos Pol <koos2024@pohw.nl> writes:
> I do not support the publication of this document.
> 
> I am from semi-government as an IT professional. Other than a founded 
> interest in cybersecurity and encryption I have no background in the 
> topics at hand. However I am dependent on them for providing me a 
> reference framework on how to incorporate security measures into my IT 
> solutions.
> 
> For my work I need to have a baseline or other guidelines on what the 
> "smart persons in this world" advise me on these topics. I consider this 
> advice normative, irrespective of the (in-)formal role of the IETF. I 
> also consider this advise as the reference baseline.  So if I've made my 
> decision on a certain security solution I will not check again for the 
> next 5 years (I do have work to do).
> 
> From where I stand the whole MLKEM discussion is an academic one. And 
> the reasons for this are simple. And unfortunately only cynical in 
> nature:  (1) The scammers out there are there to get us. (2) The 
> intelligence agencies of governments are out there to get us. So I need 
> you to tell me what I need to do to keep my shop more secure for the 
> next 5 years than it was in the past 5 years.
> 
> For me, the intense discussion here is a mere confirmation that this 
> draft should not be implemented. If it had the best outcome, you 
> (collectively) wouldn't have brought to this level of intensity. It's 
> simply not ready. I see no benefits as I can already can do the things 
> as advised in its current form. I don't need more of the same as a 
> published reference.

This quote shows an important perspective on the discussion. There are
many people integrating cybersecurity into applications. Publishing this
spec as an RFC would lead many of them to use it without even realizing
the dangers. A tiny fraction of these people see TLS WG discussions; an
even smaller fraction, such as Koos Pol, have time to participate; this
doesn't mean that their interests should be ignored. IETF is supposed to
be finding "the best solution for the whole Internet, not just the best
solution for any particular network, technology, vendor, or user."

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


## Quote 39

Original message from this author:
* https://web.archive.org/web/20260722031526/https://mailarchive.ietf.org/arch/msg/tls/9ptpZyG7qLEQ0I1N_UJpTks30jA

stellakiritoy <stellakiritoy@proton.me> writes:
> I do not support the publication of this document.
> Kind regards,
> Stella Kiritoy

I don't know if this is a real name. See my earlier comments regarding
real-name policies.


## Quote 40

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

STProjects Security <security@st2projects.com> writes:
> I do not support the publication of this document
> Kindly regards,
> Ben Davies

Here I find https://st2projects.com/cv/cv.

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


## Quote 41

Original messages from this author:
* https://web.archive.org/web/20260722032229/https://mailarchive.ietf.org/arch/msg/tls/Ld2Kpyy1-taWtYOJdFEi522sgyY
* https://web.archive.org/web/20260722033542/https://mailarchive.ietf.org/arch/msg/tls/NX6HXmNdBwts7C5Fr72A9JdiNyk

Fe Lix <felix91proxy@gmail.com> writes:
> Hi yall. I'm Felix Fischer Marques. I'm from Chile.
> 
> I don't support the publication of this document. As to why, that's
> coming up next. I'll try to be brief.
> 
> In cryptography today, we rely on strong assumptions. We try to make
> the least amount of those we can, but as of right now, we're kind of
> screwed: we must make assumptions. Nonetheless, we try to keep the
> number and strength of them as low as we can.
  [ ... ]
> Let's remain humble and accept the reality that ML-KEM might not be
> computationally strong at all.
  [ ... ]
> What I'm trying to mitigate against is a trivially horrible worst case
> scenario: ML-KEM being broken by affordable classical computers.
> 
> The hybrid approach makes the assumption that a given opponent can't
> afford to break both ECC and ML-KEM, which is a weaker-or-equal
> assumption than assuming they can't break ML-KEM.
> 
> Since we're pushing standards that will determine the safety of tens
> of millions of people, I think it's only reasonable to pick the weaker
> assumption.

This quote emphasizes that cryptographic assumptions sometimes fail
badly, and that ML-KEM in particular might fail badly. ECC+ML-KEM
mitigates against that risk.

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


## Quote 42

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

Mark Sigsbee <mark.sigsbee@ztisolutions.com> writes:
> I do not support the publication of this document.
> Mark R. Sigsbee, CISSP
> https://www.linkedin.com/in/mark-sigsbee/
> SUNet PKI Support Team
> Mark.Sigsbee@ZTISolutions.com

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


## Quote 43

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

Mathieu Bilodeau <mathieubilodeau@protonmail.com> writes:
> I do not support the publication of this document.

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


## Quote 44

Original messages from this author:
* https://web.archive.org/web/20260722033301/https://mailarchive.ietf.org/arch/msg/tls/7xaLaVXC8ldPg70JXDbj3XveWjM
* https://web.archive.org/web/20260722041926/https://mailarchive.ietf.org/arch/msg/tls/dllZRsSmxM3rMT1XDJiG3AyMgx4
* https://web.archive.org/web/20260722044217/https://mailarchive.ietf.org/arch/msg/tls/TLR8tH33-8f1j0mfbK8nGiQHnXY

Brian Resnik <brian.resnik@gmail.com> writes:
> I am in direct opposition to this proposal. ietf-tls-ecdhe-mlkem
> covers the same problem space but does it better.
  [ ... ]
> Defense in depth is a fundamental security principle that we should
> all be aware of. There is no evidence to support the argument that
> weakening standards - that is, publishing a standard with fewer
> security features, namely solo-PQ - provides any value to TLS itself
> or operators implementing these standards.
> 
> Therefore our default posture should be to provide additional defensive
> layering wherever and whenever the costs of additional layers is negligible
> compared to the overall costs of the standard, as is the case with ECC+PQ
  [ ... ]
> I think if we are going to publish this RFC then we should immediately
> also publish the following RFCs:
> ----------------------------------------
> *SHA-256 Truncated to 32 bits (SHA-256/32)*
> 
> This RFC has value because ultra-low-bandwidth mesh networks cannot afford
> a 32-byte overhead per packet for a full SHA-256 hash. Since developers in
> these environments are already truncating hashes to fit into 4-byte fields
> to save bandwidth, we need to specify exactly which 32 bits of the SHA-256
> output to keep, ensuring that when attackers forge their packets, the
> collisions happen in a standardized, interoperable way.
> 
> We should publish this anyway despite a 32-bit hash having a completely
> broken collision space where an attacker could generate a malicious payload
> with a matching hash almost instantaneously, defeating the entire purpose
> of data integrity or signature verification.
> 
> *AES in Electronic Codebook (AES-ECB) Mode *
  [ ... ]
> *RSA with 512-bit Keys (RSA-512)*
  [ ... ]
> Oh....wait....we already published this one long ago and it led directly to
> FREAK 16 years later.
> 
> ----------------------------------------
> 
> I hope this *reductio ad absurdum* argument is obvious to everyone with
> regards to why it's unwise and misguided to publish weaker RFCs when we
> have demonstrably stronger algorithms with low-to-no cost difference that
> serve the same function.
  [ ... ]
> "People are doing it anyway" is a really terrible reason for IETF to
> publish an RFC.
> 
> And yes, I know people did RSA-512 for a long time. And it led to FREAK.
> That should be a cautionary tale about why we should prefer layered/hybrid
> solutions, not an example of "well it worked okay for 10 years so that's
> fine".

This quote begins with the importance of defense in depth. It recognizes
the possibility that defense-in-depth features might be unaffordable,
but correctly observes that removing ECC from ECC+PQ in TLS is a
negligible change in total cost.

The quote continues with examples of how treating cost minimization as
the top goal tends to damage security, for example through excessive
truncation of hash outputs.

I have further comments on the third example, RSA-512. In the 1990s, NSA
made deals with the RSA company and the Software Publishers Association
to exempt some weak cryptosystems, including RSA-512, from export
controls. Overtly sabotaged cryptography, falsely advertised as strong
cryptography, ended up in Lotus Notes, subsequently purchased by IBM,
and in many more products. RSA-512 ended up entrenched in the software
ecosystem, continuing to cause security damage decades later, long after
loosening of export controls. See

    https://publish.illinois.edu/science-of-security-lablet/files/2016/08/10062016-Heninger-Slides.pdf

for more about this.


## Quote 45

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

Daniel Tams <danieltams@hey.com> writes:
> I do not support publication of this document. 

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


## Quote 46

Original messages from this author:
* https://web.archive.org/web/20260722033505/https://mailarchive.ietf.org/arch/msg/tls/rDYeJdRcJ6s3yFWjSTlv6KMEok4
* https://web.archive.org/web/20260722050104/https://mailarchive.ietf.org/arch/msg/tls/IzsnCIeEHwuEflJK0OkBXclbLic
* https://web.archive.org/web/20260722050440/https://mailarchive.ietf.org/arch/msg/tls/xE4GiOtyYNSkYl6Q7BHCde9nV1g

Tony Patti <crypto@glassblower.info> writes:
> I do not support publication of this document.
> 
> I started publishing cryptographic software, with full source code,
> during the First Crypto War [1], and actively continue to publish both
> software and other resources [2][3]. I mention my tenure because I
> believe that cryptographers need to have long memories; all too often
> history has a funny way of repeating itself.
> 
> History has shown the long-term danger of narrowing security margins
> to satisfy immediate external pressures. Of course, the most famous
> example is when the key size of IBM's original design was gutted down
> to 56 bits for the final DES standard, artificially reducing its
> structural strength to the point that it could be broken. [4]
> 
> My technical argument is that, from a first-principles cryptographic
> standpoint, the security architecture of a hybrid key exchange is
> superior to a standalone deployment, by removing a Single Point of
> Failure (SPOF). A hybrid key exchange is defined precisely by its
> ability to combine multiple algorithms to "provide security as long as
> at least one of the component algorithms remains secure." [5]
> 
> The WG should not repeat the mistake of establishing a weaker
> cryptographic specification for the global internet.

This quote takes a perspective informed by history, giving the 56-bit
DES key size as an example. NSA secretly set a goal of having DES be
"weak enough" to break. NSA colluded with IBM to reduce the DES key size
to 56 bits. Publicly, NSA claimed that DES was strong and that NSA would
use DES for itself.

Solo PQ removes ECC from ECC+PQ, helping attackers whenever solo PQ
turns out to be weaker than ECC, something we have seen happen on many
occasions.


## Quote 47

Original message from this author:
* https://web.archive.org/web/20260722033746/https://mailarchive.ietf.org/arch/msg/tls/x4B2dXjY_FIq0ri-yd3ll3os9Fs

Bartlee Anderson <bartleeanderson@gmail.com> writes:
> I  do not support the publication of this document.

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


## Quote 48

Original message from this author:
* https://web.archive.org/web/20260722034327/https://mailarchive.ietf.org/arch/msg/tls/El-t5__laUjUia46421-NWDIS-w

Eren Eroglu <eren.eroglu@metu.edu.tr> writes:
> I do not support the publication of this document due to reasons 
> discussed in this mailing list.

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


## Quote 49

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

Muhammed Ali Kosen <mhalikosen@icloud.com> writes:
> I do not support the publication of draft-ietf-tls-mlkem-08.
> 
> The proposal removes the classical hedge from TLS 1.3 key establishment.
> Keeping X25519 alongside ML-KEM costs only 32 bytes per key and 32
> bytes per ciphertext, against ML-KEM-768's roughly 1.1 KB keys and
> ciphertexts. A hybrid remains secure if either component holds; solo
> ML-KEM is secure only if ML-KEM holds, forever, against classical and
> quantum cryptanalysis and against implementation flaws.

This quote gives a quantitative example of ECC+ML-KEM having very little
extra cost beyond solo ML-KEM. The quote goes on to consider a wide
range of ways that solo ML-KEM can fail to provide security. Sometimes
ECC will save the day, so keeping an ECC layer is an obvious win.


## Quote 50

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

Joseph Diragi <joseph.diragi@icloud.com> writes:
> I do not support the publication of this document.

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


## Quote 51

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

Nicola Tuveri <nic.tuv@gmail.com> writes:
> I do not support the publication of this document.
> The main reasons are the same stated by Mark Atwood in his email.

Did the chairs disenfranchise Nicola Tuveri given that (following the
chair demands to just say yes or no) he didn't state his own arguments?
Or did they include him because he's a preexisting TLS WG contributor?


## Quote 52

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

Alexander Burke <alex@alexburke.ca> writes:
> I do not support the publication of draft-ietf-tls-mlkem-08.
  [ ... ]
> Alexander Burke, CISSP, CIPP/E, CIPM, FIP

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


## Quote 53

Original message from this author:
* https://web.archive.org/web/20260722043137/https://mailarchive.ietf.org/arch/msg/tls/1emt4eiD9AY7WJdSj2n86_w3WcM

Preston Maness <aspensmonster@riseup.net> writes:
> I oppose the publication of this document.

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


## Quote 54

Original message from this author:
* https://web.archive.org/web/20260722043827/https://mailarchive.ietf.org/arch/msg/tls/qg5-Qb97r2PkOPyTKCbNSq8L_eI

ghostkill73 <ghostkill73@pm.me> writes:
> I object to the publication of this document.
> Best regards,
> Abner Benedito.

See https://github.com/ghostkill73?tab=repositories for prior work.

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


## Quote 55

Original message from this author:
* https://web.archive.org/web/20260722044624/https://mailarchive.ietf.org/arch/msg/tls/-JdsaJpgdcNb9qcq9S7NO_DSPTY

Sven Reissmann <sven.reissmann@rz.hs-fulda.de> writes:
> after reviewing the discussion, I strongly object to the publication of 
> the document.
  [ ... ]
> Sven Reissmann
> Bereichsleitung Infrastruktur
> Hochschule Fulda
> University of Applied Sciences
> Rechenzentrum
> Leipziger Strasse 123
> D-36037 Fulda, Germany

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


## Quote 56

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

John Turner <johnturner@gmail.com> writes:
> After reviewing discussions on this topic, I do not support the 
> publication of a document specifying a stand-alone ML-KEM.

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


## Quote 57

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

Vladimir Tamara Patino <pasosdejesus2@gmail.com> writes:
> I do not support the publication of this document.

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


## Quote 58

Original messages from this author:
* https://web.archive.org/web/20260722050520/https://mailarchive.ietf.org/arch/msg/tls/gJsJOEHFQLQv7HOAw7rYMuKwjPE
* https://web.archive.org/web/20260809143922/https://mailarchive.ietf.org/arch/msg/tls/kExvPLtQgk3_YOYjTqSFq5kyAfM
* https://web.archive.org/web/20260722185628/https://mailarchive.ietf.org/arch/msg/tls/X-y4_eDUIXw-OOdzX4JXFsIm8dA
* https://web.archive.org/web/20260722190603/https://mailarchive.ietf.org/arch/msg/tls/jeHKQqZvdyWt5ETxxq7RqVqjbZ0

Mark Tehrani <mark.tehrani@cyberseq.net> writes:
> I do not support the publication of this document. Defense in depth is
> clearly needed, implementation of algorithms are in the
> standardization process and therefore they may have implementation
> immaturity.

This quote is highlighting the importance of defense in depth as
mitigation against implementation flaws.


## Quote 59

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

"Mr. G" <gustavoantonio2001@gmail.com> writes:
> I do not support the publication of this document.
> Due to several reasons previously discussed within this mailing list, I
> strongly believe that the adoption of a standalone post-quantum
> cryptographic standard will
  [ ... ]
> diminish the security of the TLS
> protocol in the short term, rather than enhance it.
> Best regards
> Gustavo Sales

I agree that issuing this as an RFC will reduce the security of TLS. (My
quote replaces the word "inadvertently" with an ellipsis; I agree with
all of the quotes I'm giving, but not necessarily with other things
beyond the quotes.)

I should also note that "adoption ... standard" correctly describes the
proposal on the table, even though it's not using IETF's doublespeak
terminology. See my comments on Quote 31.


## Quote 60

Original messages from this author:
* https://web.archive.org/web/20260722052809/https://mailarchive.ietf.org/arch/msg/tls/GekHD5clZwcDAyMXEl17Q8D4z0g
* https://web.archive.org/web/20260722183808/https://mailarchive.ietf.org/arch/msg/tls/Ub8zX0ps-fVyah-mO-inDm5kT9w

DA PIEVE Fabiana <Fabiana.DA-PIEVE@ec.europa.eu> writes:
> I do not support the publication of this document.
> 
> I already expressed my points in the past but allow me to say that
> some specific concerns I have on security (successful classical
> attacks on PQ algorithms) cannot be addressed in some few months, in
> any possible manner. I understand certain people are becoming
> increasingly worried by an accelerated arrival of a CRQC, but I am
> also worried of things that can happen (and has already happened) in
> the meantime.
> 
> Given the considerable and excellent work already done to deploy
> hybrid ML-KEM, I think taking advantage of such work at maximum is a
> reasonable thing to do.
  [ ... ]
> Thank you for your kind attention
> Fabiana
> Team Leader Post-Quantum Cryptography
> 
> European Commission
> DG Communications Networks, Content and Technology
> Unit C4 -- Emerging & Disruptive Technologies

This quote highlights the risk of PQ algorithms being breakable even
without a quantum computer. It alludes to PQ breaks that have already
happened, and recommends continuing with ECC+PQ deployment.


## Quote 61

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

Marc Stibane <marc@taler.net> writes:
  [ after quoting Michael Gouin ]
> Exactly my thoughts.
  [ ... ]
> I'm afraid that people would mis-judge the publication as being "good
> enough" to be used.
> So I do not support the publication.

The first part of this quote imports Michael Gouin's comments regarding
the ML-KEM risks, the low cost of keeping ECC, and the fact that we
won't immediately have all attackers breaking all ECC keys. The second
part notes that many people will understand an RFC as IETF endorsement.


## Quote 62

Original messages from this author:
* https://web.archive.org/web/20260722053236/https://mailarchive.ietf.org/arch/msg/tls/ZR1SXyZL_EgzVrsDxMvgXYwSIug
* https://web.archive.org/web/20260722201437/https://mailarchive.ietf.org/arch/msg/tls/5e9MXHfyb-ISWRyRtbylepDL-DY

"Bellebaum, Thomas" <thomas.bellebaum@aisec.fraunhofer.de> writes:
> I object to the publication of this document.
  [ ... ]
> ML-KEM seems sound enough to heuristically get us through a first few
> years of transition while X25519 prevents attacks in the short term
> (with active attacks on today's connection becoming mostly irrelevant
> by the time a CRQC exists, and passive HNDL attacks becoming less
> relavant for many pieces of information).
> By that time, I also expect many improvements in safety, security and
> efficiency to be ripe for inclusion in TLS, which would make ML-KEM
> obsolete from any purely technical standpoint.

This quote is addressing various mistakes from proponents of solo PQ.

Proponents often assume without justification that there is a long-term
goal of switching to solo ML-KEM. I see little chance that solo ML-KEM
will be the best long-term choice. For example, there are already many
lattice options such as SMAUG-T using less communication than ML-KEM,
and if all of the lower-communication options end up broken then
presumably ML-KEM will end up broken too.

Furthermore, proponents often ignore the shorter-term benefit of ECC,
the many cases where ECC stops attackers who don't have a quantum
computer yet. Even _after_ some attackers have quantum computers
breaking some ECC keys, ECC will continue helping security for many
years. See generally https://cr.yp.to/papers/mldsa-20260601.pdf#ecc.


## Quote 63

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

Naveen Nathan <naveen@lastninja.net> writes:
> I do not support publication of this document.
> 
> Removing the seatbelt (ECC) without adequate replacement
> is a significant step backwards, and while a cryptographer
> makes the point about this, it doesn't take a cryptographer
> or anyone with understanding of the basics to come to the
> same conclusion.

This is an important counterpoint to, e.g., NSA consultant Paul Hoffman
claiming that the "credible cryptographic community" supports solo PQ.

Hoffman's claim is a wild exaggeration of the tiny fraction of the
community that has spoken up in favor of solo PQ. His claim also ignores
endless counterexamples. But the most fundamental mistake in his claim
is the notion that this is a decision to be made by the "cryptographic
community". The main way that this community generates income for itself
(see https://cr.yp.to/papers/competitions-20240113.pdf#subsection.1.3.8)
is by producing one security failure after another. One doesn't have to
be a cryptographer to see this pattern.

For people deploying PQ, keeping ECC in place as a low-cost extra layer
of security is simple common sense, reducing risks for the end users.


## Quote 64

Original messages from this author:
* https://web.archive.org/web/20260722181818/https://mailarchive.ietf.org/arch/msg/tls/UMLwDiNUf0lNNW1PIA6B01BxpoQ
* https://web.archive.org/web/20260722201005/https://mailarchive.ietf.org/arch/msg/tls/g_CafSaMNHmnWnEustXv-sTVneo
* https://web.archive.org/web/20260722202054/https://mailarchive.ietf.org/arch/msg/tls/Y8o85UQDE9uD80nMLedtbjh7_hg

Stephan Verbuecheln <stephan@verbuecheln.ch> writes:
> I also do not support publication of solo ML-KEM in TLS.
> Since I feel that everything has already been said in this discussion
> multiple times, I have nothing to add.

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


## Quote 65

Original message from this author:
* https://web.archive.org/web/20260721022404/https://mailarchive.ietf.org/arch/msg/tls/i_GeoT-1Rir9ljOioHmBJjzB5hQ

"scosol@scosol.org" <scosol@scosol.org> writes:
> For a multi-disciplinary engineer, removing cheap redundant systems is
> simple bad practice. So much so that the motivations of those
> advocating for it have to be called in to question. 
> 
> Of course I do not support the publication of this document, it's an
> insult to first principles and I can't believe people are needing to
> say it out loud.

Here scosol is Datadog's Scott Solmonson. Does IETF say "a very large
majority of those who care must agree, except that people like Scott
Solmonson can be ignored"?


## Quote 66

Original messages from this author:
* https://web.archive.org/web/20260722182339/https://mailarchive.ietf.org/arch/msg/tls/lNCTjyktdnkgQEZu_305fVWezjU
* https://web.archive.org/web/20260722182625/https://mailarchive.ietf.org/arch/msg/tls/G1tQ0EWfO7Sgy_qKOLMAXkfrptI

"Richard T. Carback III" <rick@carback.us> writes:
> I do not support publishing draft-ietf-tls-mlkem-08 at this time.
  [ ... ]
> Even with "Recommended=N", publication is not neutral. The value of
> an RFC, which is stated plainly in the announcement that opened this last
> call [1],  is that downstream bodies rely on it: this announcement
> cites liaisons from O-RAN, IEEE 802.11, and 3GPP requesting
> publication because they "rely on the IETF to provide a stable
> normative reference".  That is, they want a standard to build
> deployment on. An artifact that those bodies lobby for because it
> will shape their decisions cannot, in the same breath, be said to
> have no bearing on their decisions.
  [ ... ]
> The cost of waiting is low. The ML-KEM code points already exist in
> the registry at Recommended=N [2], so anyone who wants to implement
> pure ML-KEM can already do so and interoperate today, without the
> RFC. Thus, the substance this doc adds seems to reduce to an IETF
> endorsement, which only encourages pure-only deployment in my view.
> 
> Given that the mission of the IETF is to seek the best outcome for
> the whole Internet, the responsible default is caution (for now).
> We are in the fortunate position of having a strictly stronger,
> negligible-cost, already-Recommended=Y alternative available:
> X25519MLKEM768 [2]. This has not been true for this kind of work
> historically, with unfortunate and unavoidable fallout. Some
> examples include:
> 
>    - RSA key-transport and static-DH suites were marked
>      Recommended=N in 2018 (RFC 8447 [3]). Raccoon (2020) then
>      exploited permitted-but-discouraged DH secret reuse in
>      fielded stacks. CVE-2020-5929 did not even need a timing
>      oracle [4] and Marvin (2023) found the 25-year-old
>      Bleichenbacher timing class still live across OpenSSL,
>      GnuTLS, Java, Go, Node.js, Mbed TLS, and hardware modules [5].
> 
>    - Export-grade RSA and DH, forced into stacks by 1990s
>      regulation, were still enabling FREAK (CVE-2015-0204) and
>      Logjam (CVE-2015-4000) twenty years later [6][7].
> 
>    - The heartbeat extension gave us Heartbleed in 2014
>      (CVE-2014-0160, RFC 6520 [8]); AFAIK, the IANA
>      registry still lists heartbeat as Recommended=Y [2].
> 
> Contrast these with one of IETF's finer moments: RFC 6176
> prohibiting SSLv2 outright in 2011 [9]. Five years later DROWN
> (CVE-2016-0800) used still-deployed SSLv2 to break TLS for roughly
> a third of HTTPS servers [10]. While a "MUST NOT" did not
> decommission everything, it did substantially reduce the impact
> (and personally saved my infrastructure at the time).
  [ ... ]
> No one can predict the future, but we do know the past. Endorsing
> a pure mode now is an unnecessary risk when we have safe low-cost
> alternatives.

When there are specific objections to the impact of this spec, a common
way for the chairs and other document proponents to avoid addressing the
content of the objections is to insinuate that the document _won't_
encourage usage. Consider, e.g., the chair WGLC message saying "the IANA
registry will reflect a clear community preference for a hybrid because
Recommended: Y clearly indicates this while the standalone ML-KEM groups
defined in this draft remain Recommended: N" (as if corporate purchasing
managers look at the IANA registry!), and claiming that the draft cites
the IANA registry "to emphasize this preference" (one wonders whether
the chairs understand what the word "emphasize" means).

But the chairs and other document proponents also insinuate that the
minor cost difference between ECC+PQ and solo PQ sometimes matters for
deployability, ergo an RFC on solo PQ is required. For example, the same
chair WGLC message claimed that "We received liaison statements from
multiple SDOs including O-RAN[2], IEEE 802.11[4] and from 3GPP[3]
expressing support for the publication of draft-ietf-tls-mlkem as an
RFC".

These insinuations are irreconcilable, as Richard T. Carback III
explains in the above quote, and the first insinuation is simply wrong.
An RFC will encourage usage.

The second insinuation, the insinuation that the cost difference matters
for deployability, is unfounded and implausible. Minutes are available
from one of the liaisons mentioned by the chairs, namely IEEE; scanning
those minutes finds zero evidence of IEEE having a problem with the cost
of ECC+PQ compared to solo PQ, while

    https://mentor.ieee.org/802.11/dcn/25/11-25-2259-00-00bt-tgbt-november-plenary-2025-session-minutes.docx

shows that someone (not named in the minutes) told 802.11bt that NSA "do
not allow hybrid mechanism". Furthermore,

    https://web.archive.org/web/20260405212317/https://mentor.ieee.org/802.11/dcn/26/11-26-0652-00-00bt-ietf-request-for-pure-ml-kem-liaison.pptx

shows an NSA employee reporting to 802.11bt that a liaison statement to
IETF in favor of solo PQ would "do the trick" to "help show consensus
for publication during WGLC".

If anyone had even a single real example of an application where the
minor cost difference matters for deployability, we would have already
seen full details of that example posted for the TLS WG to consider.
Instead there are tricks aimed at producing claims of consensus, the
objective of those claims being to have IETF issue an RFC, which _of
course_ will encourage usage.

Richard Carback's quote continues by dispensing with a claim from some
proponents that the point of an RFC is interoperability. Issuing this
document as an RFC won't help interoperability; instead it will convey
IETF endorsement to typical readers.

The quote continues by explaining that solo ML-KEM is a pointless
downgrade from ECC+ML-KEM, and then by giving examples of security
damage caused by bad options, such as the Raccoon attack exploiting a
TLS feature that was deployed despite IETF marking it as Recommended N
in 2018, while IETF's outright prohibition of SSLv2 had a larger effect.

The quote concludes that solo PQ is an unnecessary risk compared to
ECC+PQ. The extra cost of ECC is low.

The entire reply from a proponent in

    https://web.archive.org/web/20260722182445/https://mailarchive.ietf.org/arch/msg/tls/EqhBS9lVvOSgOzl5Csc9aGgRsoY/

was as follows: "This is not about being able to implement --- it's
about being able to implement in an interoperable way. I do wish people
would gain some IETF experience before speaking up." This is an example
of a broader problem of non-responsiveness by proponents.


## Quote 67

Original messages from this author:
* https://web.archive.org/web/20260722182718/https://mailarchive.ietf.org/arch/msg/tls/qijfEh8nZeMj0KqwRQDOBhITzfs
* https://web.archive.org/web/20260722184400/https://mailarchive.ietf.org/arch/msg/tls/zTe-KEEBzbJ5dqjmAxdy2VL45GQ
* https://web.archive.org/web/20260722184743/https://mailarchive.ietf.org/arch/msg/tls/xTiYQnK8uS181kRlFe7xiFjdD20
* https://web.archive.org/web/20260722193602/https://mailarchive.ietf.org/arch/msg/tls/1cES_u4ZdGfPb6gQ_YkYNXgymB0

Ken Kubota <tls@kenkubota.de> writes:
> I object to the proposal to publish draft-ietf-tls-mlkem-*.
> Replacing a hybrid (double-encryption) mechanism with a non-hybrid
> (single-encryption) mechanism introduces significant and obvious risks
> without providing any corresponding benefits.

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


## Quote 68

Original message from this author:
* https://web.archive.org/web/20260722183511/https://mailarchive.ietf.org/arch/msg/tls/PvC-J2Y0aOgG2K1CewZK5TItWX0

Andreas Bartelt <ietf-lists@bartelt.name> writes:
> I do not support the publication of this document.
> 
> One of the practically relevant advantages of TLS 1.3 relative to TLS 
> 1.2 (and below) is its use of more secure defaults. Experience shows 
> that unnecessarily weakened variants such as the 
> TLS_AES_128_CCM_8_SHA256 cipher suite in TLS 1.3 will frequently show up 
> in web server configurations. This cipher suite is almost always not 
> intentionally enabled by the web server admins. IANA marking this cipher 
> suite as "not recommended" doesn't really help in practice. I'd expect 
> very similar problems with draft-ietf-tls-mlkem-08.

This quote gives an example of how little effect "not recommended" has
upon deployment.


## Quote 69

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

Roger Grimes <roger@banneretcs.com> writes:
> I do not support the publication of this document.
> 
> Too many people take every RFC, either officially "recommended" or
> not, as an "official standard".
> 
> Requiring dual encryption doesn't add that much overhead and adds a
> great layer of additional protection.
> 
> ********************************************************************************************************************************************
> *Roger A. Grimes
  [ ... ]
> *Author or co-author of 16 books and over 1600 articles on
> cybersecurity

This quote is highlighting (1) the reality of what people understand the
issuance of an RFC to mean, (2) the low cost of keeping ECC, and (3) the
added protection from keeping ECC.

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


## Quote 70

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

Kai Page <kai@quantaly.net> writes:
> I do not support the publication of this document. Both the ECDHE and 
> ML-KEM components of hybrid key agreement have important roles to play 
> in guaranteeing its security: ML-KEM obviously guards against 
> harvest-now-decrypt-later quantum attacks, and ECDHE guards against the 
> ongoing cryptanalysis of ML-KEM as well as side channels and other bugs 
> in ML-KEM implementations, which are far less mature than elliptic curve 
> implementations. A scheme without both presents a meaningfully increased 
> risk to users compared to the hybrid key agreement schemes already being 
> successfully rolled out.
> 
> If individual organizations want to use solo ML-KEM internally for 
> whatever reason, there is nothing stopping them from doing so, with or 
> without the tacit endorsement of an IETF publication. But as far as 
> globally interoperable, RFC-compliant TLS deployments go, providing 
> options that deviate from best practices exposes unsuspecting users to 
> unnecessary risks. It's for this very reason that TLS 1.3 mandates 
> ephemeral key exchange, despite the added computational effort for 
> servers to generate unique keypairs. Nobody is proposing to allow server 
> operators to disable forward secrecy, even though we're all trying our 
> hardest to prevent key compromises anyway, because ephemeral keys 
> mitigate the risks posed by static keys. In a similar vein, hybrid key 
> agreement should remain as the single published PQ migration target for 
> the foreseeable future because hybrid key agreement mitigates the risks 
> posed by solo ML-KEM key agreement.

This quote begins by explaining the different security roles of ECC and
PQ inside ECC+PQ. The PQ part tries to add security against future
quantum attacks. The ECC part reduces the damage from any security
failures in the PQ part.

The quote continues by noting the general danger of people unwittingly
using weaker options.

The quote then points out another example of defense in depth inside
TLS: namely, we try to prevent key compromises _and_ we use "forward
secrecy" to reduce the damage done by key compromises.

A proponent of solo PQ had claimed some hours earlier that ECC+PQ is
"the one time in history" that people are claiming a need for defense in
depth. That proponent never answered Kai Page's counterexample.


## Quote 71

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

Chris Miller <chris.miller@vp.net> writes:
  [ in response to Roger Grimes: ]
> I agree and therefore, I do not support the publication of this
> document.
> Chris Miller
> Verified Privacy - vp.net

This quote is adopting the Roger Grimes objections. Recall that those
are based on (1) the reality of what people understand the issuance of
an RFC to mean, (2) the low cost of keeping ECC, and (3) the added
protection from keeping ECC.

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


## Quote 72

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

Sam Smith <samsmithsemail@gmail.com> writes:
> I do not support publication of this document.
> 
> Hello from the UK, it's been a while since I was last at an IETF
> workshop wearing a different hat.
> 
> Since then, my job has partially been answering the phone when a
> journalist finds out that someone has done something stupid with a lot
> of UK medical records. Data that should be protected by reliable
> encryption in multiple ways, and often it turns out, is not protected
> in any of those ways.
  [ ... ]
> It's better all round that, even if several things go wrong, there are
> multiple levels of resilience. The effect of this draft is asking for
> trouble.

This quote is coming from a real-world cybersecurity perspective, like
the Koos Pol quote earlier, and comes to the common-sense conclusion of
advocating defense in depth.

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


## Quote 73

Original message from this author:
* https://web.archive.org/web/20260722210328/https://mailarchive.ietf.org/arch/msg/tls/MEdXIXn5hrmtp_VmMVEqylZ_-qM

Harry Halpin <hhalpin@ibiblio.org> writes:
> I do not support the publication of the document.
> 
> Overall, given the immaturity of the standards and lack of real clarity
> over safe parameters, and given the importance of TLS in encrypting most of
> the world's traffic in combination with the fairly low additional overhead
> of hybrid KEM mode for TLS, I think it makes sense to in general to
> recommend to use hybrid mode with X25519. Of course an Informational RFC is
> not a recommendation, but it can easily and will be viewed as such.
> 
> As a former W3C staff member, I do understand there is a fairly informal
> process for Informational IETF RFCs and internally they are viewed more as
> house-keeping for implementers, but one must remember for the outside
> world, including many implementers, even Informational RFCs are treated as
> de-facto standards. So additional care must be taken and a certain degree
> of conservatism should be expected.

This quote is highlighting this spec's poor tradeoff between risk and
overhead, along with the risk of an RFC being viewed as IETF endorsement
even when it's just "informational".

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

When the chairs were deciding who they wanted to disenfranchise (if they
actually made a list rather than just making up their desired "roughly
7/10" result), did they check carefully enough to notice that he was a
pre-existing WG participant?


## Quote 74

Original message from this author:
* https://web.archive.org/web/20260722211808/https://mailarchive.ietf.org/arch/msg/tls/9U4SbmRw7YCW7hOrt68CsiU50Zw

Sven Schaege <sschaege@googlemail.com> writes:
> As a cryptographer,
> 
> I do not support the publication of the draft.
> 
> Like several people before me, I view this as a security management
> problem. The extra costs of using established ECC crypto amount to a
> mere fraction of the requirements of ML-KEM and seem acceptable even
> on low-end devices.
> 
> Opting for a hybrid solution is the more conservative and, in my
> opinion, the more responsible approach.

This quote emphasizes the affordability of the conservative approach
of using ECC+PQ rather than solo PQ.

Does IETF say "a very large majority of those who care must agree,
except that people like Sven Schaege can be ignored"? His previous
posting to the TLS mailing list was in 2024, with more content than
NSA's postings.


## Quote 75

Original message from this author:
* https://web.archive.org/web/20260722214741/https://mailarchive.ietf.org/arch/msg/tls/5AHBVFSg1ELc_pSUsqcFlmcfSGs

William Whyte <wwhyte@qti.qualcomm.com> writes:
> I oppose publishing draft-ietf-tls-mlkem.
> 
> I believe that hybrid is a more conservative and prudent approach to
> security than standalone ML-KEM is, and that the use of hybrid helps
> provide protection against flaws in ML-KEM, whether those are due to
> implementation errors, future cryptanalysis, or some other source. I
> believe that it's appropriate for the TLS WG to favor approaches that
> it believes to be appropriately secure, and not to endorse approaches
> that are less secure than approaches it's already endorsed. As the
> custodian of the concept of "doing TLS security well", the WG should
> be making choices of this sort.
> 
> I also think that the material impact of this draft not being
> published by TLS is minimal but net positive. As many have noted, this
> draft can be published via the ISE as well; implementers who want to
> implement standalone ML-KEM in TLS will be able to do it
> interoperably; that will happen whether or not the TLS WG publishes
> this draft. The effect of TLS not publishing this draft will simply be
> that, at the margin, there will be some number of implementers who
> choose hybrid rather than standalone. This will be a small but real
> benefit to security of TLS-using systems.

This quote begins by emphasizing that ECC+ML-KEM reduces the damage from
security failures in ML-KEM, and that the security goal for the TLS WG
includes rejecting downgrades.

(As a side note, one proponent has conflated "downgrade" with a narrower
concept of "downgrade attack" in which a protocol is deployed and then
an attacker acting within that protocol tricks a client and server into
taking weaker options than we'd like. A smart attacker will look beyond
that narrow concept, and will consider ways that pre-deployment actions
to _change_ the protocol can end up weakening security.)

The quote continues by noting that issuing an RFC will encourage usage
by "some number of implementers" and thus weaken security, whereas not
doing so will have the opposite effect.


---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.