Hiya,
Again, I don't think this threat applies but the logic is worth getting right... On 07/07/2026 22:21, Sophie Schmieg wrote:
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 getyou around one of the opt-ins, but leave the second one in place.
I agree with the above.
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.
That seems, to me, naive. One of the things I took from the 2013 Snowden stuff was that such an adversary might assert influence such that the influenced parties (implementers/vendors/those who configure servers) weren't aware that their collective actions might enable attacks. That could certainly seem like conspiracy-thinking, but between dual-ec, crypto AG and the relevant history, we do have examples of such attacks being attempted. The point here (for me) is not to oppose publication of this draft, but to ack that were ML-KEM backdoor'd, (again, I think not), then the RFC existing would, to some extent, improve the attack. I don't find that a reason to oppose publication, but we ought be careful of the arguments for progressing the draft - ISTM those arguments absolutely do depend on ML-KEM not being backdoor'd. Cheers, S.
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.
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
