I do not understand the content of this objection. There already is an alternative for PQ support in TLS, namely MLKEM + ECC hybrids, defined in:
https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ It's just not specified in this document. -Ekr On Tue, Jul 7, 2026 at 10:03 PM Bruno Henc <[email protected]> wrote: > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
