Izzy’s views mirror mine. Nadim Kobeissi Symbolic Software • https://symbolic.software
> On 22 Feb 2026, at 2:49 AM, 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. > > 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. > > 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] > <mailto:[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] > <mailto:[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] > <mailto:[email protected]>> > Sent: Saturday, February 21, 2026 4:24 PM > To: Deirdre Connolly <[email protected] > <mailto:[email protected]>> > Cc: Nadim Kobeissi <[email protected]>; [email protected] > <mailto:[email protected]> <[email protected] <mailto:[email protected]>>; Rich Salz > <[email protected] <mailto:[email protected]>>; > Paul Wouters <[email protected] > <mailto:[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] > <mailto:[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] > <mailto:[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] > <mailto:[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] > <mailto:[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] <mailto:[email protected]> > To unsubscribe send an email to [email protected] <mailto:[email protected]> > > > _______________________________________________ > TLS mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] <mailto:[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]
