[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 20 26-07-08)

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]