[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

[Benjamin Kaduk <[e-mail]>]

(not quoting the message due to the no-derivative-works boilerplate and lack of time to consult legal counsel or otherwise analyze whether doing so would subject me to personal liability)

Dan,

I don't think John is concerned with a beefy modern CPU on a beefy network connection.  Can you repeat your analysis for a scenario involving a 16-bit CPU operating at a 100 MHz clock speed and with a 5 kBps network connection?  Other IETF protocols attempting to support devices constrained on that scale have jumped through hoops to find cryptographic techniques that can achieve (mostly-)reasonable security properties while limiting the cryptographic primitives needed, such as shoehorning AES-CMAC into a hole that it only mostly fills, so as to allow the device to only have an AES implementation and not need a secure hash implementation as well, to preserve space on the ROM.  In these scenarios, where the communication endpoints are known at device deployment and do not need to rely on the protocols' MTI algorithms to achieve interoperability, it is often plausible to omit implementations of crytographic primitives.  So in this example scenario a device manufacturer seeking to achieve protection against quantum-computer attacks on their TLS-protected data would have an incentive to drop the ECC implementation to save on code size.  Yes, they would be facing a security tradeoff by doing so and incur risk from using pure-ML-KEM rather than hybrid, but *in this scenario* the analysis is not as one-side as you present it to be.

Also, John is at least trying to engage with you on the technical facts, so tossing out phrases like "benchmarking crime" seems unnecessarily confrontational.

Thanks,

Ben