I agree with this summary and conclusion and I oppose the pure ML-DSA draft as written.
Here is what I hope that the WG members can explore further. Assume that there is only one way to do PQ KEM, which is ML-KEM + ECDH. This approach reduces complexity of any realistic SW stack that has to have a hybrid option. For people who worry about cycles associated with the ECDH side, please note the following. (A) Reduction of options is of great benefit to anyone. Bugs are likely in less frequently exercised code paths, and interoperability is reduced when there are options. When everyone sticks to the only one way to do PQ KEM in TLS, the benefits flow to everyone: analysis is easier, bugs are less likely, handshakes are faster, etc. (B) "I don't want to pay a penalty in cycles for ECDH". There is no material difference in payload size, given the massive size of ML-KEM v.s. ECDH. A client that does not want to compute ECDH can use ECC generator point as his share. Then the other peer's share becomes the shared secret. The same is true for the server. A peer does not need to be aware of what the other peer is doing (but it can if it wants to replace ECC operation with memcpy()). This is not a hybrid method when looked through the lens of optimization described here -- this is simply an encoding (to-be-mandated) in TLS. It's hard to argue that memcpy() transforms this method into a hybrid mode. So, there is only one way to do PQ KEM in TLS, and a PQ-only variant of this can be accomplished with a simple profile describing optimization tricks in (B). The profile can make everything fully deterministic, e.g. mandate that each side precisely sends the generator point, making the contribution to the handshake fully predictable, which also allows that all ECDH "extra" can be hardcoded in pure ML-KEM implementations. Could that work for everyone? On Fri, Feb 27, 2026 at 2:55 PM Nico Williams <[email protected]> wrote: > On Fri, Feb 27, 2026 at 10:45:02PM +0000, Blumenthal, Uri - 0553 - MITLL > wrote: > > >> - There does not seem to be any evidence that ML-KEM is weak. I think > > >> that if ML-KEM gets badly broken, it will be for unforeseeable reasons > > >> (which is a risk for any cryptographic algorithm, including prime- > > >> field ECC). > > > > > > Except that for a hybrid mode, both ML-KEM and ECC must be broken > simultaneously. > > > > ECC break under CRQC is a-given. Which should matter for PQC context. > > As has been repeated countless times. > > The fundamental disconnect is that there are: > > - participants who do not believe CRQC are happening any time soon > - participants who do believe CRQC are happening soon > (for some value of soon) > > and > > - participants who worry that NSA might have a cryptanalysis of > ML-KEM-768 that has it have a strength of, say, 2^70ish > - participants who do not worry that NSA might have a cryptanalysis of > ML-KEM > > Given that, the only aproach that will please all sides is to stick to > hybrids. > > But then there are participants who insist on pure PQ because of > performance, CNSA 2.0, etc. -- not terribly good reasons. > > I don't know how you break this impasse, but "repeat[ing] countless > times" is not a good answer. > > Cheers, > > Nico > -- > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
