Hello everyone, I do not support the publication of this document.
Opinions are my own and reflect practical experience with the mess when NIST didn't adopt/endorse ed25519 for quite a while. The practical result was that a certain IDS vendor who shall remain unnamed rejected all connections that had ed25519 as part of the list of signature algorithms. The workaround was to remove ed25519 from the signature algorithms list. Now the IDS vendor did issue patches to address the problem, in a quiet, mostly undocumented way. Figuring out that
the vendor elected to arbitrarily reject TLS connections based on a single parameter wasted massive amounts of time.I think that
One would think RFC8701 would have prevented these interoperability problems but it did not.
This is all a long winded way to say the the current tls-mlkem-08 draft lacks "cryptographic agility". To narrow down even further, there should be a second option available as part of the draft, in case of any issues with ML-KEM. This would prevent the
vendors from only supporting a single algorithm and hardcoding it everywhere.
Similar objections have been raised to the roughtime draft about cryptographic agility (see https://datatracker.ietf.org/doc/review-ietf-ntp-roughtime-15-secdir-lc-reddyk-2026-01-12/).
If SSL2.0 shipped with more than one algorithm in 1996, I don't see why the "pure PQ" options should be allowed to ship without supporting an alternative.
It is my opinion that if this draft is published as-is, TLS1.3 will ossify into only supporting "pure PQ" options at the vendor level causing interoperability problems later on.
Sincerely, Bruno Henc _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
