Very explicitly, this is not the main RFC for incorporating PQ crypto into TLS 1.3. This is an RFC with recommendation to implement = N about how to do pure ML-KEM if you must for some reason, in a standards-compliant way.
That blog post is written in a way that implies otherwise, namely that pure ML-KEM is being favored over hybrids for TLS 1.3. This is explicitly false.
Moreover many parts are technically false. In particular, the claim that hybrids are negligible cost in all circumstances is false in low-spec hardware, as it necessitates both a SHA2 and SHA3 implementation.
Comments
Another poster has already given a link to the technical arguments of DJB,
https://blog.cr.yp.to/20260221-structure.html
where he combats very well your argument.
For me, his argumentation seems far more grounded in reality than what you have said.
Very explicitly, this is not the main RFC for incorporating PQ crypto into TLS 1.3. This is an RFC with recommendation to implement = N about how to do pure ML-KEM if you must for some reason, in a standards-compliant way.
That blog post is written in a way that implies otherwise, namely that pure ML-KEM is being favored over hybrids for TLS 1.3. This is explicitly false.
Moreover many parts are technically false. In particular, the claim that hybrids are negligible cost in all circumstances is false in low-spec hardware, as it necessitates both a SHA2 and SHA3 implementation.
https://mailarchive.ietf.org/arch/msg/tls/_9i3uIVDQ3pDRswpm9...
if the proposal was ml-kem+ecc hybrid that removed sha2 and replaced it with sha3, no one would be objecting