Feedback-ID: i6d3949ed:Fastmail
From: Nadim Kobeissi <nadim@symbolic.software>
Message-Id: <3DE4E550-3AF2-45E5-B8C1-121ADB2B7E12@symbolic.software>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6F8C245C-C51A-4349-A977-DE864ADA5E8C"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
Date: Sun, 22 Feb 2026 13:01:23 +0100
In-Reply-To: <446c7ab1-ed34-462f-bb60-33be4dd554e9@email.android.com>
To: Izzy Grosof <izzy.grosof@northwestern.edu>
References: <446c7ab1-ed34-462f-bb60-33be4dd554e9@email.android.com>
Message-ID-Hash: R3X47LWALPLVSZU2AAA6ZPMD7AYSACJR
CC: "TLS@ietf.org" <tls@ietf.org>,
 Rich Salz <rsalz=40akamai.com@dmarc.ietf.org>,
 Paul Wouters <paul=40nohats.ca@dmarc.ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BTLS=5D_Re=3A_WG_Last_Call=3A_draft-ietf-tls-mlkem-05_=28Ends_20?=
	=?utf-8?q?26-02-27=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/tls/m1y70-W030FLrQGRxQg3OSSx2M8>


--Apple-Mail=_6F8C245C-C51A-4349-A977-DE864ADA5E8C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Izzy=E2=80=99s views mirror mine.

Nadim Kobeissi
Symbolic Software =E2=80=A2 https://symbolic.software

> On 22 Feb 2026, at 2:49=E2=80=AFAM, Izzy Grosof =
<izzy.grosof@northwestern.edu> wrote:
>=20
> 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.
>=20
> 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.
>=20
> That being said, I would love to see a quantitative probabilistic =
analysis that lays out the claimed advantages of non-hybrid ML-KEM.
>=20
>=20
> On Feb 21, 2026 18:57, Eric Rescorla <ekr@rtfm.com> wrote:
> Unfortunately, this model is too simplistic and thus leads to absurd
> conclusions.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> -Ekr
>=20
> [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.
>=20
>=20
>=20
>=20
> On Sat, Feb 21, 2026 at 3:37=E2=80=AFPM Izzy Grosof =
<izzy.grosof@northwestern.edu <mailto:izzy.grosof@northwestern.edu>> =
wrote:
> My research area is probabilistic performance modeling, so naturally I =
think about all of this through a probabilistic model.=20
>=20
> 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.
>=20
> 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.=20
>=20
> 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%.
>=20
> 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.
>=20
> 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.=20
>=20
> 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.
>=20
> 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.=20
>=20
> I appreciate the question, I realize that a probabilistic model isn't =
everyone's starting point.
>=20
>=20
> On Feb 21, 2026 16:31, "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com =
<mailto:sfluhrer@cisco.com>> wrote:
> I fully realize that this will not change anyone's opinion, but I feel =
compelled to ask.
>=20
> 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?
>=20
> 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.
>=20
> 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.
>=20
> 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?
>=20
>=20
> From: Izzy Grosof <izzy.grosof@northwestern.edu =
<mailto:izzy.grosof@northwestern.edu>>
> Sent: Saturday, February 21, 2026 4:24 PM
> To: Deirdre Connolly <durumcrustulum@gmail.com =
<mailto:durumcrustulum@gmail.com>>
> Cc: Nadim Kobeissi <nadim@symbolic.software>; TLS@ietf.org =
<mailto:TLS@ietf.org> <tls@ietf.org <mailto:tls@ietf.org>>; Rich Salz =
<rsalz=3D40akamai.com@dmarc.ietf.org =
<mailto:40akamai.com@dmarc.ietf.org>>; Paul Wouters =
<paul=3D40nohats.ca@dmarc.ietf.org <mailto:40nohats.ca@dmarc.ietf.org>>
> Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends =
2026-02-27)
>=20
> 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:=20
>=20
> "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."
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> "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.
>=20
> On Feb 20, 2026 19:51, Izzy Grosof <izzy.grosof@northwestern.edu =
<mailto:izzy.grosof@northwestern.edu>> 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?
>=20
> 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?
>=20
> As a compromise, the clarifying line that I'm suggesting could say =
something like:
>=20
> "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."
>=20
> A line like this addresses the scenario that you're describing, I =
believe, by removing any perceived advantage to classical-only.
>=20
> On Feb 20, 2026 15:21, Deirdre Connolly <durumcrustulum@gmail.com =
<mailto:durumcrustulum@gmail.com>> 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=E2=80=94 basically saying non-hybrid should not be =
deployed until it is too late
>=20
> On Fri, Feb 20, 2026, 4:15=E2=80=AFPM Nadim Kobeissi =
<nadim@symbolic.software> wrote:
> Wait, wasn=E2=80=99t the whole point of adding a PQ primitive to =
mitigate SNDL?
>=20
> Both hybrid and PQ-only key agreement should mitigate SNDL. ECC-only =
key agreement is the only scheme that=E2=80=99s vulnerable to SNDL as =
far as I'm aware. Please correct me if I=E2=80=99m wrong.
>=20
> Nadim Kobeissi
> Symbolic Software =E2=80=A2 https://symbolic.software =
<https://urldefense.com/v3/__https://symbolic.software__;!!Dq0X2DkFhyF93Hk=
jWTBQKhk!Uf4nfZhJqaAjKdsbw9YrmYmf_PjTf8RbqF1-wL30JtJS4yPBcMTdGrbkuCGM8wdYp=
PUun72UFFN8hQdYAGpEyJGB6n5R_VmrhT4$>
>=20
> On 20 Feb 2026, at 10:13=E2=80=AFPM, Deirdre Connolly =
<durumcrustulum@gmail.com <mailto:durumcrustulum@gmail.com>> wrote:
>=20
> > non-hybrid ML-KEM should not be deployed in a user-facing manner =
until a CRQC has been publicly demonstrated.=20
>=20
> 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=20
>=20
> On Fri, Feb 20, 2026, 4:04=E2=80=AFPM Izzy Grosof =
<izzy.grosof@northwestern.edu <mailto:izzy.grosof@northwestern.edu>> =
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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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 -- tls@ietf.org <mailto:tls@ietf.org>
> To unsubscribe send an email to tls-leave@ietf.org =
<mailto:tls-leave@ietf.org>
>=20
>=20
> _______________________________________________
> TLS mailing list -- tls@ietf.org <mailto:tls@ietf.org>
> To unsubscribe send an email to tls-leave@ietf.org =
<mailto:tls-leave@ietf.org>
>=20
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org


--Apple-Mail=_6F8C245C-C51A-4349-A977-DE864ADA5E8C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" =
content=3D"text/html; charset=3Dutf-8"></head><body =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;">Izzy=E2=80=99s views mirror mine.<br =
id=3D"lineBreakAtBeginningOfMessage"><div>
<meta charset=3D"UTF-8"><br>Nadim Kobeissi<br>Symbolic Software =
=E2=80=A2&nbsp;https://symbolic.software<br>
</div>
<div><br><blockquote type=3D"cite"><div>On 22 Feb 2026, at 2:49=E2=80=AFAM=
, Izzy Grosof &lt;izzy.grosof@northwestern.edu&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div>

<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">

<div>
<div dir=3D"auto">
<div>
<div>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.</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">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.</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">That being said, I would love to see a quantitative =
probabilistic analysis that lays out the claimed advantages of =
non-hybrid ML-KEM.</div>
<br>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Feb 21, 2026 18:57, Eric Rescorla =
&lt;ekr@rtfm.com&gt; wrote:<br type=3D"attribution">
<blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
<div>
<div dir=3D"ltr">Unfortunately, this model is too simplistic and thus =
leads to absurd<br>
conclusions.<br>
<br>
Taking your numbers as-is, consider another algorithm, A1 (e.g., =
HQC),<br>
with the same confidence in security of ML-KEM, namely a 10% chance =
of<br>
a classical break, but because it's based on a different problem, =
that<br>
outcome is independent of a classical break in ML-KEM. In that<br>
situation, the chance of a break for ML-KEM/ECC hybrid is 1% and the<br>
chance of a break for ML-KEM/ECC/A1 hybrid is .1% (the chance of a<br>
joint break of ML-KEM and A1), implying that we should add A1 [0].&nbsp; =
We<br>
can extend the logic to another algorithm A2, and so on. This<br>
obviously isn't the right answer.<br>
<br>
The right way to do this analysis is to set not only the probability<br>
of each outcome for each strategy but *also* (1) the cost of each<br>
strategy and (2) the value of each outcome and then compute the<br>
expected value under each strategy (this is just standard decision<br>
theory). Failing to do this can cause you to get boxed into =
strategies<br>
that marginally improve the chance of a better outcome but don't<br>
improve the expected value.<br>
<br>
Obviously, a lot depends on how you estimate these costs and values<br>
and I'm not taking a position here on how they should be set; =
however,<br>
if you want to apply this kind of decision theory that's where you<br>
have to start.<br>
<br>
-Ekr<br>
<br>
[0] I recognize that the absolute difference between 1% and .1% is<br>
small, but we can adjust the numbers to make the difference large, =
and<br>
as you said, the basic logic of the argument doesn't depend on the<br>
numbers.<br>
<br>
<br>
</div>
<div dir=3D"ltr">
<div dir=3D"ltr"><br>
</div>
<br>
<div class=3D"elided-text">
<div dir=3D"ltr">On Sat, Feb 21, 2026 at 3:37=E2=80=AFPM Izzy Grosof =
&lt;<a =
href=3D"mailto:izzy.grosof@northwestern.edu">izzy.grosof@northwestern.edu<=
/a>&gt; wrote:<br>
</div>
<blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb( =
204 , 204 , 204 );padding-left:1ex">
<div>
<div dir=3D"auto">
<div dir=3D"auto">My research area is probabilistic performance =
modeling, so naturally I think about all of this through a probabilistic =
model.&nbsp;</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">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.</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">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.&nbsp;</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">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%.</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">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.</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">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.&nbsp;</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">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.</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">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.&nbsp;</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">I appreciate the question, I realize that a =
probabilistic model isn't everyone's starting point.</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto"><br>
<div class=3D"elided-text">On Feb 21, 2026 16:31, "Scott Fluhrer =
(sfluhrer)" &lt;<a =
href=3D"mailto:sfluhrer@cisco.com">sfluhrer@cisco.com</a>&gt; wrote:<br =
type=3D"attribution">
<blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb( =
204 , 204 , 204 );padding-left:1ex">
<div dir=3D"ltr">
<div style=3D"font-size: 11pt;">
I fully realize that this will not change anyone's opinion, but I feel =
compelled to ask.</div>
<div style=3D"font-size: 11pt;">
<br>
</div>
<div style=3D"font-size: 11pt;">
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?</div>
<div style=3D"font-size: 11pt;">
<br>
</div>
<div style=3D"font-size: 11pt;">
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.</div>
<div style=3D"font-size: 11pt;">
<br>
</div>
<div style=3D"font-size: 11pt;">
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.</div>
<div style=3D"font-size: 11pt;">
<br>
</div>
<div style=3D"font-size: 11pt;">
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?</div>
<div><br>
</div>
<div style=3D"font-family: calibri, arial, helvetica, sans-serif; =
font-size: 12pt;">
<br>
</div>
<hr style=3D"display:inline-block;width:98%">
<div style=3D"font-family: calibri, arial, helvetica, sans-serif; =
font-size: 12pt;">
<b>From:</b>&nbsp;Izzy Grosof &lt;<a =
href=3D"mailto:izzy.grosof@northwestern.edu">izzy.grosof@northwestern.edu<=
/a>&gt;<br>
<b>Sent:</b>&nbsp;Saturday, February 21, 2026 4:24 PM<br>
<b>To:</b>&nbsp;Deirdre Connolly &lt;<a =
href=3D"mailto:durumcrustulum@gmail.com">durumcrustulum@gmail.com</a>&gt;<=
br>
<b>Cc:</b>&nbsp;Nadim Kobeissi &lt;nadim@symbolic.software&gt;; <a =
href=3D"mailto:TLS@ietf.org">
TLS@ietf.org</a> &lt;<a href=3D"mailto:tls@ietf.org">tls@ietf.org</a>&gt;;=
 Rich Salz &lt;rsalz=3D<a =
href=3D"mailto:40akamai.com@dmarc.ietf.org">40akamai.com@dmarc.ietf.org</a=
>&gt;; Paul Wouters &lt;paul=3D<a =
href=3D"mailto:40nohats.ca@dmarc.ietf.org">40nohats.ca@dmarc.ietf.org</a>&=
gt;<br>
<b>Subject:</b>&nbsp;[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 =
(Ends 2026-02-27)
</div>
<div style=3D"font-family: calibri, arial, helvetica, sans-serif; =
font-size: 12pt;">
<br>
</div>
<div style=3D"direction:ltr">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:&nbsp;</div>
<div style=3D"direction:ltr"><br>
</div>
<div style=3D"direction:ltr">"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."</div>
<div style=3D"direction:ltr"><br>
</div>
<div style=3D"direction:ltr">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.</div>
<div style=3D"direction:ltr"><br>
</div>
<div style=3D"direction:ltr">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.</div>
<div style=3D"direction:ltr"><br>
</div>
<div style=3D"direction:ltr">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.</div>
<div style=3D"direction:ltr"><br>
</div>
<div style=3D"direction:ltr">"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.</div>
<div><br>
</div>
<div>On Feb 20, 2026 19:51, Izzy Grosof &lt;<a =
href=3D"mailto:izzy.grosof@northwestern.edu">izzy.grosof@northwestern.edu<=
/a>&gt; wrote:</div>
<div style=3D"direction:ltr">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?</div>
<div style=3D"direction:ltr"><br>
</div>
<div style=3D"direction:ltr">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?</div>
<div style=3D"direction:ltr"><br>
</div>
<div style=3D"direction:ltr">As a compromise, the clarifying line that =
I'm suggesting could say something like:</div>
<div style=3D"direction:ltr"><br>
</div>
<div style=3D"direction:ltr">"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."</div>
<div style=3D"direction:ltr"><br>
</div>
<div style=3D"direction:ltr">A line like this addresses the scenario =
that you're describing, I believe, by removing any perceived advantage =
to classical-only.</div>
<div><br>
</div>
<div>On Feb 20, 2026 15:21, Deirdre Connolly &lt;<a =
href=3D"mailto:durumcrustulum@gmail.com">durumcrustulum@gmail.com</a>&gt; =
wrote:</div>
<div style=3D"direction:ltr">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=E2=80=94
 basically saying non-hybrid should not be deployed until it is too =
late</div>
<div><br>
</div>
<div style=3D"direction:ltr">On Fri, Feb 20, 2026, 4:15=E2=80=AFPM Nadim =
Kobeissi &lt;nadim@symbolic.software&gt; wrote:</div>
<blockquote style=3D"margin:0px 0px 0px =
0.8ex;padding-left:1ex;border-left:1px solid rgb( 204 , 204 , 204 )">
<div>Wait, wasn=E2=80=99t the whole point of adding a PQ primitive to =
mitigate SNDL?</div>
<div><br>
</div>
<div>Both hybrid and PQ-only key agreement should mitigate SNDL. =
ECC-only key agreement is the only scheme that=E2=80=99s vulnerable to =
SNDL as far as I'm aware. Please correct me if I=E2=80=99m wrong.</div>
<div><br>
Nadim Kobeissi<br>
Symbolic Software =E2=80=A2 <a =
href=3D"https://urldefense.com/v3/__https://symbolic.software__;!!Dq0X2DkF=
hyF93HkjWTBQKhk!Uf4nfZhJqaAjKdsbw9YrmYmf_PjTf8RbqF1-wL30JtJS4yPBcMTdGrbkuC=
GM8wdYpPUun72UFFN8hQdYAGpEyJGB6n5R_VmrhT4$">
https://symbolic.software</a></div>
<div><br>
</div>
<blockquote>
<div>On 20 Feb 2026, at 10:13=E2=80=AFPM, Deirdre Connolly &lt;<a =
href=3D"mailto:durumcrustulum@gmail.com">durumcrustulum@gmail.com</a>&gt; =
wrote:</div>
<div><br>
</div>
<div style=3D"direction:ltr">&gt;&nbsp;non-hybrid ML-KEM should not be =
deployed in a user-facing manner until a CRQC has been publicly =
demonstrated.&nbsp;</div>
<div style=3D"direction:ltr"><br>
</div>
<div style=3D"direction:ltr">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&nbsp;</div>
<div><br>
</div>
<div style=3D"direction:ltr">On Fri, Feb 20, 2026, 4:04=E2=80=AFPM Izzy =
Grosof &lt;<a =
href=3D"mailto:izzy.grosof@northwestern.edu">izzy.grosof@northwestern.edu<=
/a>&gt; wrote:</div>
<blockquote style=3D"margin:0px 0px 0px =
0.8ex;padding-left:1ex;border-left:1px solid rgb( 204 , 204 , 204 )">
<div style=3D"direction:ltr;font-family:'aptos' , , , 'calibri' , =
'helvetica' , sans-serif;font-size:12pt">
&gt; This seems like a tremendous waste of time. The chairs should =
exclude from<br>
their consensus determination mail from people who are not limiting =
their<br>
comments to clarifying text and are instead relitigating the same<br>
previously discussed arguments. There is no reason to believe the =
same<br>
people going off topic now, will not simply go off topic on yet =
another<br>
WGLC.</div>
<div style=3D"direction:ltr;font-family:'aptos' , , , 'calibri' , =
'helvetica' , sans-serif;font-size:12pt">
<br>
</div>
<div style=3D"direction:ltr;font-family:'aptos' , , , 'calibri' , =
'helvetica' , sans-serif;font-size:12pt">
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.</div>
<div style=3D"direction:ltr;font-family:'aptos' , , , 'calibri' , =
'helvetica' , sans-serif;font-size:12pt">
<br>
</div>
<div style=3D"direction:ltr;font-family:'aptos' , , , 'calibri' , =
'helvetica' , sans-serif;font-size:12pt">
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.</div>
<div style=3D"direction:ltr;font-family:'aptos' , , , 'calibri' , =
'helvetica' , sans-serif;font-size:12pt">
<br>
</div>
<div style=3D"direction:ltr;font-family:'aptos' , , , 'calibri' , =
'helvetica' , sans-serif;font-size:12pt">
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.</div>
<div style=3D"direction:ltr;font-family:'aptos' , , , 'calibri' , =
'helvetica' , sans-serif;font-size:12pt">
<br>
</div>
<div style=3D"direction:ltr;font-family:'aptos' , , , 'calibri' , =
'helvetica' , sans-serif;font-size:12pt">
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.</div>
<div style=3D"direction:ltr;font-family:'aptos' , , , 'calibri' , =
'helvetica' , sans-serif;font-size:12pt">
<br>
</div>
<div style=3D"direction:ltr;font-family:'aptos' , , , 'calibri' , =
'helvetica' , sans-serif;font-size:12pt">
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.</div>
<div>_______________________________________________<br>
TLS mailing list -- <a href=3D"mailto:tls@ietf.org">tls@ietf.org</a><br>
To unsubscribe send an email to <a =
href=3D"mailto:tls-leave@ietf.org">tls-leave@ietf.org</a></div>
</blockquote>
</blockquote>
<div><br>
</div>
</blockquote>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
_______________________________________________<br>
TLS mailing list -- <a href=3D"mailto:tls@ietf.org">tls@ietf.org</a><br>
To unsubscribe send an email to <a =
href=3D"mailto:tls-leave@ietf.org">tls-leave@ietf.org</a><br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>

_______________________________________________<br>TLS mailing list -- =
tls@ietf.org<br>To unsubscribe send an email to =
tls-leave@ietf.org<br></div></blockquote></div><br></body></html>=

--Apple-Mail=_6F8C245C-C51A-4349-A977-DE864ADA5E8C--