On Sat, Feb 21, 2026 at 5:49 PM Izzy Grosof <[email protected]> wrote:
> I agree that the model I proposed is simplistic. As I and others have > discussed in other messages, a key part of the argument for hybrid ML-KEM > is the fact that classical ECC both has very low overhead compared to > ML-KEM due to its tiny key size, and that the relevant software is already > well-developed. The triple-hybrid you describe lacks these advantages. > It's true that there's some additional cost to developing the triple hybrid, but if the risk of breakage and the cost of breakage is high enough, there is still a positive EV. To be clear, I agree that the triple hybrid is a bad idea, and in fact that's why I raised it, but my point is that you can only get to that conclusion by weighing the costs of the various strategies and the risk involved, but that's precisely what's contested, so the analysis you're providing doesn't really help us get there, If charted on a plot of failure probability versus keysize, non-hybrid > ML-KEM does not lie on the Pareto-optimal frontier - either classical-ECC > (best keysize, sacrificing failure probability) or hybrid ML-KEM (best > failure probability, larger keysize) are best. With triple-hybrid added to > the chart, double hybrid is still on that frontier. > No, that's not correct. Triple hybrid has a better failure probability and an even larger keysize. -Ekr > That being said, I would love to see a quantitative probabilistic analysis > that lays out the claimed advantages of non-hybrid ML-KEM. > > > On Feb 21, 2026 18:57, Eric Rescorla <[email protected]> wrote: > > Unfortunately, this model is too simplistic and thus leads to absurd > conclusions. > > Taking your numbers as-is, consider another algorithm, A1 (e.g., HQC), > with the same confidence in security of ML-KEM, namely a 10% chance of > a classical break, but because it's based on a different problem, that > outcome is independent of a classical break in ML-KEM. In that > situation, the chance of a break for ML-KEM/ECC hybrid is 1% and the > chance of a break for ML-KEM/ECC/A1 hybrid is .1% (the chance of a > joint break of ML-KEM and A1), implying that we should add A1 [0]. We > can extend the logic to another algorithm A2, and so on. This > obviously isn't the right answer. > > The right way to do this analysis is to set not only the probability > of each outcome for each strategy but *also* (1) the cost of each > strategy and (2) the value of each outcome and then compute the > expected value under each strategy (this is just standard decision > theory). Failing to do this can cause you to get boxed into strategies > that marginally improve the chance of a better outcome but don't > improve the expected value. > > Obviously, a lot depends on how you estimate these costs and values > and I'm not taking a position here on how they should be set; however, > if you want to apply this kind of decision theory that's where you > have to start. > > -Ekr > > [0] I recognize that the absolute difference between 1% and .1% is > small, but we can adjust the numbers to make the difference large, and > as you said, the basic logic of the argument doesn't depend on the > numbers. > > > > > On Sat, Feb 21, 2026 at 3:37 PM Izzy Grosof <[email protected]> > wrote: > > My research area is probabilistic performance modeling, so naturally I > think about all of this through a probabilistic model. > > Let's establish the timeline of deployment that we're interested in - > let's say the next 40 years. This timeline covers both how long we expect > the cryptosystems being deployed now to remain in use, and the duration for > which a SNDL attack to expose secrets that are still important. Feel free > to choose a different duration and go through the argument yourself. > > The important questions are: what is the probability of a security failure > of ML-KEM in the next 40 years, and what is the probability of a security > failure of classical ECC in the next 40 years? In the case of ML-KEM, most > of the probability of failure comes from classical attacks such as a > cryptographic breakthrough or implementation flaw, like you mentioned, > while for classical ECC, it mostly comes from a CRQC becoming available on > that timeline. > > I'd estimate the probability of ML-KEM falling due to implementation fault > or cryptographic breakthrough in the next 40 years at around 10%, and of > breaking ECC via a CRQC at also around 10%, and that these two events are > roughly independent. If you disagree with these numbers, don't worry - my > argument simply depends on these probabilities both being significantly > less than 100%. > > Under the probabilities I listed, the chance of a break under > classical-only is 10%, under ML-KEM-only is 10%, and that hybrid is 1%. > Hybrid is substantially less likely to be broken, and thus neither of the > alternatives is acceptable. > > If you run your own numbers you'll find that hybrid is preferable by far > unless you believe either that the events in which ECC-only and ML-KEM-only > are broken are near-perfectly correlated, or one event is near-guaranteed > to occur. I believe neither, so hybrid ML-KEM is the only acceptable > option. > > To flesh out the argument more, we'd need to switch from single-cutoff > probability of failure to consider the probability of failure year-by-year > as a stochastic processes, and also to analyze the distribution of partial > breaks leading to a decrease in security without it vanishing altogether, > and also the relative importance of live, real-time breaks versus SNDL > breaks. > > While this would flesh out the argument, and would certainly be > worthwhile, it wouldn't change the core conclusion: hybrid is better, > because a double break is less likely than a single break. > > I appreciate the question, I realize that a probabilistic model isn't > everyone's starting point. > > > On Feb 21, 2026 16:31, "Scott Fluhrer (sfluhrer)" <[email protected]> > wrote: > > I fully realize that this will not change anyone's opinion, but I feel > compelled to ask. > > In opposing the ML-KEM draft, are you saying that there is a significant > chance that ML-KEM be compromised (either due to a cryptographic > breakthrough, an implementation flaw or a side channel), and that chance is > high enough that we ought to try to forbid anyone from using it? > > If so, then one would have to conclude that the current hybrid being > proposed (ML-KEM + ECC) has a significant chance of not meeting its > security goal of being PQ secure. > > If we believed that to be the case, I would think that we would also need > to reject the hybrid draft, and work on something we think is secure. > > If you still make the claim that "ML-KEM only is bad, ML-KEM+ECC is good", > could you please point out the flaw in my reasoning? > > > ------------------------------ > *From:* Izzy Grosof <[email protected]> > *Sent:* Saturday, February 21, 2026 4:24 PM > *To:* Deirdre Connolly <[email protected]> > *Cc:* Nadim Kobeissi <[email protected]>; [email protected] <[email protected]>; > Rich Salz <[email protected]>; Paul Wouters <paul= > [email protected]> > *Subject:* [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends > 2026-02-27) > > To refine my previous wording, I believe that a recommendation is > insufficient, and that a full requirement is needed. To that end, I > recommend the language: > > "Non-hybrid ML-KEM MUST not be deployed as a TLS cryptosystem prior to the > public demonstration of a security break of the classical component of > hybrid ML-KEM via a quantum computer. However, this is not a reason to > prefer classical pre-quantum cryptosystems over non-hybrid ML-KEM: hybrid > ML-KEM should be used instead." > > However, I want to clarify: while the above language is necessary for me > to support the draft, it is not sufficient. I oppose the current document, > and I would continue to oppose it if this was the only change made. > > Many other issues have been articulated which I agree are blocking > problems, such as the lack of a compelling reason to employ non-hybrid > ML-KEM over hybrid ML-KEM, as described by Nadim, as well as the other > problems described by Nadim, as well as problems described by others. > > The balance of the probabilities of security breaches due to > classical-only vs. non-hybrid ML-KEM vs. hybrid ML-KEM overwhelmingly > favors hybrid ML-KEM. The document should articulate clear and compelling > reasoning security benefits of non-hybrid ML-KEM over hybrid ML-KEM, or it > should not be published. > > "If all other cryptosystems are banned, this is the best cryptosystem" is > not a clear and compelling security benefit. The same can be said of > literally any cryptosystem. > > On Feb 20, 2026 19:51, Izzy Grosof <[email protected]> wrote: > To clarify, are you concerned about a scenario in which someone is willing > to deploy either classical-only or ML-KEM-only, but is unwilling to deploy > the hybrid-ML-KEM system, and so with a recommendation against ML-KEM-only > prior to a CRQC demonstration and towards hybrid-ML-KEM, instead chooses > classical-only, becoming open to Save Now Decrypt Later? > > In this scenario, this provider is already refusing to deploy the best > option prior to a CRQC demonstration, namely hybrid-ML-KEM. Should we not > attempt to convince this provider to support hybrid-ML-KEM via this > clarifying text, rather than omit a clear indication of the best course of > action? > > As a compromise, the clarifying line that I'm suggesting could say > something like: > > "Non-hybrid ML-KEM should not be deployed prior to the public > demonstration of a security break of the classical component of hybrid > ML-KEM via a quantum computer. However, this is not a reason to prefer > classical pre-quantum cryptosystems over non-hybrid ML-KEM: hybrid ML-KEM > should be used instead." > > A line like this addresses the scenario that you're describing, I believe, > by removing any perceived advantage to classical-only. > > On Feb 20, 2026 15:21, Deirdre Connolly <[email protected]> wrote: > To clarify, saying either hybrid or non-hybrid key agreement should not be > deployed until a CRQC has been demonstrated fails to address the primary > passive attack against TLS key agreement, and applies to both hybrid and > non-hybrid— basically saying non-hybrid should not be deployed until it is > too late > > On Fri, Feb 20, 2026, 4:15 PM Nadim Kobeissi <[email protected]> > wrote: > > Wait, wasn’t the whole point of adding a PQ primitive to mitigate SNDL? > > Both hybrid and PQ-only key agreement should mitigate SNDL. ECC-only key > agreement is the only scheme that’s vulnerable to SNDL as far as I'm aware. > Please correct me if I’m wrong. > > Nadim Kobeissi > Symbolic Software • https://symbolic.software > <https://urldefense.com/v3/__https://symbolic.software__;!!Dq0X2DkFhyF93HkjWTBQKhk!Uf4nfZhJqaAjKdsbw9YrmYmf_PjTf8RbqF1-wL30JtJS4yPBcMTdGrbkuCGM8wdYpPUun72UFFN8hQdYAGpEyJGB6n5R_VmrhT4$> > > On 20 Feb 2026, at 10:13 PM, Deirdre Connolly <[email protected]> > wrote: > > > non-hybrid ML-KEM should not be deployed in a user-facing manner until a > CRQC has been publicly demonstrated. > > This fails to mitigate Store Now Decrypt Later attacks which are > considered a live threat to present TLS traffic, whether using hybrid or > non-hybrid PQ key agreement > > On Fri, Feb 20, 2026, 4:04 PM Izzy Grosof <[email protected]> > wrote: > > > This seems like a tremendous waste of time. The chairs should exclude > from > their consensus determination mail from people who are not limiting their > comments to clarifying text and are instead relitigating the same > previously discussed arguments. There is no reason to believe the same > people going off topic now, will not simply go off topic on yet another > WGLC. > > To offer a substantive comment on topic, focused on clarifying the text of > the proposal, it seems that the two main use cases for non-hybrid ML-KEM > are either to plan ahead for the future development of a CRQC, or to deploy > once a CRQC has been developed, and there is agreement that CRQCs do not > currently exist. > > I therefore propose to add a line to the document which states that > non-hybrid ML-KEM should not be deployed in a user-facing manner until a > CRQC has been publicly demonstrated. Concretely, non-hybrid ML-KEM should > not be deployed in a user-facing manner until the classical component of > the relevant hybrid cryptosystem (e.g. an elliptic curve cryptosystem) has > been demonstrated to be broken (e.g. a concrete decryption demonstration) > via a quantum computer. > > I believe this additional line would be amenable both to people who think > that this demonstrated break of classical systems will come relatively > soon, and so non-hybrid ML-KEM will soon be relevant, and people who think > this break will not come for a while, and so hybrid ML-KEM will stay > preferable for a long time. To be clear, this additional line clarifying > the proposal does not block developers from creating non-hybrid ML-KEM > software, but only recommends against deploying that software prematurely. > > My research area is the performance modeling of computing systems, so a > stochastic model of future security degradation is natural to me, both of > classical cryptosystems via quantum computer and of ML-KEM via classical > attacks. Hybrid cryptosystems should be used until the times comes when it > is sufficiently cheap/quick/easy to break classical cryptosystems via > quantum attacks that no substantial security benefit is provided by > including the hybrid component. There is a distribution of how long this > will take, and different people will have different estimates of this > distribution. I think it is relatively uncontroversial that there is a > substantial probability that classical cryptography is not broken (or > substantially degraded in security) for tens of years. We should provide > guidance which clarifies our stance relative to this timeline. > > Finally, I want to point out that a wide variety of institutions have some > expiry date on the duration for which they want their information to stay > secret. For example, the US government has automatic declassification > procedures after 25, 50, and 75 years. We should clarify the text of this > document in a way that benefits readers interested in this form of > limited-duration security in the 10-100 year time scale, by clarifying that > non-hybrid ML-KEM should only be deployed to users after a demonstrated > full decryption of the relevant classical cryptosystem. > _______________________________________________ > 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] > > >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
