Sophie's point as that Google-based connections (which is what she is concerned about) will not use pure ML-KEM without nontrivial and deliberate configuration, which will be rare.
On the other hand, if ML-KEM is compromised, then hybrid ML-KEM+ECC will not be secure after q-day. That is a point that the 'hybrid-only' proponents want to ignore; ECC security appears to have an end date, and while we don't know when that is, it may well be in the next several years. At that point, the security of ML-KEM and ML-KEM+ECC becomes equivalent, and all the horrible scenarios they imagine if ML-KEM is used will also become a reality with hybrid. ________________________________ From: Stephen Farrell <[email protected]> Sent: Tuesday, July 7, 2026 4:11 PM To: Sophie Schmieg <[email protected]>; [email protected] <[email protected]> Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08) Hiya, On 07/07/2026 19:49, Sophie Schmieg wrote: > I think it is important to emphasize that, even if > one assumes a total compromise of pure ML-KEM there exists no risk to the > public internet from this draft. I find the above unconvincing. The dual-ec fiasco also involved paying commercial entities to implement the borked alg as well as the odd code additions in the Juniper case. Were there a backdoor in ML-KEM (which I do not think is the case) then it could be exploited, and the existence of this putative RFC would increase the liklihood of successful exploitation. Cheers, S. PS: To recap, I no longer object to this draft now the WG has preferred the hybrid, but I think better to be precise about the pros and cons.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
