The point is that convincing one vendor to do so would not suffice. Both the client *and* the server need to make a positive choice to use pure ML-KEM, otherwise nothing will happen. The whole point of the negotiation is that you require two opt-ins. Paying someone off might get you around one of the opt-ins, but leave the second one in place. And if you can pay off both sides, then I would suggest to the parties writing those checks to just access the raw plaintext of the connection, that seems substantially cheaper if both sides are under their control, compared to going through the motions of creating a fake standard.
On Tue, Jul 7, 2026 at 1:12 PM Stephen Farrell <[email protected]> wrote: > > 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. > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
