this is not an accurate picture of what is happening. Hybrid KEMs are already widely supported within the IETF, and are supported in an RFC with "recommended to implement = yes".

This is about a separate RFC with "recommended to implement = no".

If the IETF was trying to have these positions swapped, it would be consistent with DJBs post. It is not though. His post does not seem to be grounded in reality.

▲

adrian_b 3 days ago | parent [-]

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.

▲

mswphd 3 days ago | parent [-]

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

	▲	adgjlsfhk1 3 days ago \| parent [-]
		if the proposal was ml-kem+ecc hybrid that removed sha2 and replaced it with sha3, no one would be objecting