MIME-Version: 1.0
References: 
 <CAOgPGoDd=qhg-mGzB8mrFOGVKHY_9uz+_EO3P_i0_e8TG6v0Mw@mail.gmail.com>
 <3256af6a-db98-42c7-839e-e96802cae2dd@cs.tcd.ie>
 <CAOgPGoCMAXmJodSsQcg9ve2TmHd1nfOpek9nmh=BcDOpN1fvTQ@mail.gmail.com>
In-Reply-To: 
 <CAOgPGoCMAXmJodSsQcg9ve2TmHd1nfOpek9nmh=BcDOpN1fvTQ@mail.gmail.com>
From: Daniel Apon <dapon.crypto@gmail.com>
Date: Mon, 23 Mar 2026 14:52:20 -0400
Message-ID: 
 <CAPxHsSJK6jx-On6hJ5tQdYsPakAhH-_2Y8+tsndnqds5fF+Dzw@mail.gmail.com>
To: Joseph Salowey <joe@salowey.net>
Content-Type: multipart/alternative; boundary="000000000000822ba3064db589ae"
Message-ID-Hash: BEDUK6JADTCMOMX35VJCG6ETFTMWDDB7
CC: "<tls@ietf.org>" <tls@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BTLS=5D_Re=3A_Status_of_ML-KEM_WGLC?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/tls/nVeE4qhVAnLCOfGZcNloENNF34Q>

--000000000000822ba3064db589ae
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello TLS WG and chairs,

I'd like to propose a renewal for the call for adoption of pure-mlkem (
https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/) as an RFC out of
the TLS WG.

This seems to move beyond Joe's recent comments here that the current
intent is to run a specific consensus call on the changed text (regarding,
by my understanding, the Motivation & Security Consideration sections of
https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/). Accordingly,
further context and explanation is needed for this message than a simple
in-line reply.

Many years ago, I was NIST's lattice cryptographer during the (now)
decade-long process of standardizing ML-KEM. I apologize for my late
arrival. I've watched the steps within the TLS working group from afar.
Admittedly, I have not been an active participant in the draft process for
pure-mlkem in IETF's TLS WG to this point. In terms of understanding the
way in which IETF works, I refer to RFC 7282,
https://datatracker.ietf.org/doc/html/rfc7282. I'm approaching this
discussion from that document, plus what I've seen in the TLS WG mailing
list discussion.

In the sense of RFC 7282, my previous position has been one of preemptive
capitulation. In other words, "Forget it; do what you want." In the words
of RFC 7282, this simply means "That's not coming to consensus; there still
exists an outstanding unaddressed objection." To wit, I notice that the
first session of the TLS WG at IETF 125 began with a recounting of a
mailing list ban of DJB, and an first-item-issue in the WG of an apology by
the chairs to DJB of accidentally censoring a message of his. Having spent
much time on the NIST PQC Forum over the prior years, I can easily imagine
the rough context of any such situation. (Who really wants to have a bitter
fight via email messages on an Internet forum?)

I am aware there was a recent "mandatory call" for pure-mlkem that recently
failed. It might surprise those who know me to hear that I agree with that
mandatory call failing. I do not think it's the proper time for pure-mlkem
to be mandatory.
Nonetheless, there is a distinct difference between a mandatory requirement
for ML-KEM and simply an official option for ML-KEM-only.

Currently, I represent a major vendor in the space of secure
communications. For our primary communications platform, we intend to offer
ML-KEM-only as the straightforward implementation of TLS for our systems,
at $100B+ scale. (I note a prior response in this thread indicates that
gmail is doing the same.)

That is not to say that we don't intend to have hybrid systems. In
particular, for many of our systems, we are actively exploring systems that
hybridize in an amortized way between ECC (e.g. X25519) and lattice-based
cryptography (ML-KEM-1024). That is, sometimes the significantly smaller
bandwidth of Curve25519 based ciphertexts is inherently necessary for
current systems.


So, this gets to my *main first objection* to the current state of
discussion (as held at the 125 meeting):

As a vendor, I believe both in the (current) security of X25519 and the
(long-term) security of ML-KEM, while being cognizant of the quantum threat
and HNDL. However, the efficiency profiles differ dramatically, and
different systems have different needs.
In contexts of challenging communication environments, we require the low
bandwidth of X25519 in order to have reliable communications.
Yet on the other hand, when considering a basic TLS-based system -- e.g. a
webserver connected to high-speed fiber with convenient access to a
reliable PKI, we believe that hybridizing between ECC+ML-KEM is the *worst
of both worlds.*

In particular, consider the performance profiles of these two schemes:
X25519 is noticeably slower to compute in parallel, while smaller in
bandwidth; ML-KEM is noticeably faster to compute in parallel, while higher
in bandwidth.
*In the most common/applicable use-case of TLS 1.3* -- i.e. high-bandwidth
traffic with millions of billions of connections, over reliable
infrastructure -- bandwidth is significantly less of a problem, and
computation constraints are the major concern.
Simply put, for TLS 1.3, pure-mlkem is the obviously correct solution if
you want high-performance solutions -- modulo security considerations
(let's turn to that now.)


My *second objection* to the state of the discussion regards the call for
CFRG/IRTF to render a fresh opinion on the cryptography of ML-KEM to the
TLS WG:

There has been a full decade of entirely open, international analysis and
debate over the security of quantum-resistant cryptography through the NIST
PQC process.
ML-KEM was fully vetted through this process (despite various detractors
that may feel otherwise).

Yet, the discussion in the TLS WG is not cryptographically detailed in the
nature. *No new cryptanalyses have been offered.* Just some grumbling.
Do we expect that a call to the CFRG will report something significantly
different in terms of number theory and computational analyses that NIST's
decade-long, international, open, and highly visible process did not? I
think that seems wildly unlikely.


My *third objection* to the discussion regards the talk of "Hard No"s to
prior WGLC's for pure-mlkem:

Certainly, there can be many "absolutely not!"s in the discussion of
whether to adopt this particular draft. However, that seems to run counter
to my understanding of  RFC 7282 in terms of the chairs' opinion on whether
rough consensus has been achieved. Again, I am not calling for a mandatory
use of ML-KEM-only; and indeed, I plan to use ECC in various systems (with
different performance constraints attached to them than the typical TLS
use-cases).

However, to /deny/ the option for ML-KEM-only to be used in TLS 1.3 would
seem to be a shocking repudiation of the decade-long, international effort
to that led to that cryptographic standard. Is it really an acceptable
outcome that a more visible, international process led to the
standardization /of the primitive,/ and yet -- in the most obvious use-case
in protocols (TLS 1.3 -- which has been the motivating protocol in every
lecture I've given in university grad courses for years now) -- it should
be fundamentally /disallowed/?


My *fourth objection*, following up:

At the 125 meeting, someone commented that "well, hey -- IETF standardized
the codepoints for ML-KEM. Isn't that enough?" No!
Many vendors will only support ML-KEM-only TLS if there is, specifically,
an RFC from IETF specifying such.
A very common goal in industry these days is to ensure "*no vendor-lock-in*=
"
for various products.
However, if this WG decides to disallow an RFC on ML-KEM-only TLS, then
many vendors will not produce products conforming to the natural outcome of
the NIST PQC process.

This would induce a punishing market effect on the broader vendor ecosystem
from a relatively obscure conversation in this WG's mailing list.


So, my general call is for the following:
1) Adopt hybrid-ECC-MLKEM for TLS 1.3
2) Adopt ML-KEM-only for TLS 1.3
2b) I strongly encourage neutral language in the RFC.
2c) "Proponents of hybrid" is not quite accurate, as there are not
"opponents of hybrid," but there *is* a significant vendor-community that
is *also* a proponent of ML-KEM-only, for specific systems.


Finally, I've had advice from a wise man who's active in this WG and many
others: "Don't come, fly over, and drop bombs, then never continue the
conversation again."
Understood! I'm happy to be here until the cows come home.
I also intend to share the (alarming) status of the current discussion with
others in the vendor community that want /an option/ for ML-KEM-only in TLS
1.3. This is *not* an effort to "ballot-stuff," but a genuine attempt to
make others aware that the conversation has gone so far here, without
sufficient representative input, that a standards/RFC outcome is near that
is entirely unexpected by many vendors.

Kind regards,
--Daniel Apon



On Mon, Mar 23, 2026 at 11:52=E2=80=AFAM Joseph Salowey <joe@salowey.net> w=
rote:

>
>
> On Sun, Mar 22, 2026 at 11:04=E2=80=AFAM Stephen Farrell <
> stephen.farrell@cs.tcd.ie> wrote:
>
>>
>> Hi Joe,
>>
>> On 22/03/2026 17:49, Joseph Salowey wrote:
>> > ML-KEM WGLC Update
>> >
>> > We are working through issues brought up during the working group last
>> > call. We believe addressing these issues is necessary to determine if =
we
>> > have rough consensus to move forward. We expect the author to address
>> the
>> > following points:
>> >
>> > * Key Reuse
>> > * Text for preferring Hybrids
>> > * Whether to include motivations (see Liaison Statement)
>> >
>> > We expect resolving these issues will take a few weeks after which we
>> will
>> > run a targeted consensus call to see if text changes are acceptable to
>> the
>> > working group.
>>
>> The above seems to me unclear and hard to understand.
>>
>> Are you saying that the 2nd WGLC failed due to a lack of rough
>> consensus? (Or not?)
>>
>>
> [Joe] The chairs have determined that there is no rough consensus, but
> people have requested changes.  The chairs have asked the author to see i=
f
> changes to the draft make a difference.
>
>
>> Either way, I don't know what you mean by a "targeted consensus
>> call" - if the 2nd WGLC failed, then surely another WGLC will be
>> needed or the draft is just stalled. If the 2nd WGLC succeeded,
>> then (that'd be a surprise and) I don't get why some other consensus
>> call would be needed, nor for what.
>>
>>
> [Joe]  The intent here is to run a specific consensus call on the changed
> text.  If you suggested changes in the draft in the previous WGLCs then w=
e
> ask you to review and state whether the changes have helped (or not).  If
> you did not recommend changes, then your position will remain the same,
> unless you state that you are reconsidering.
>
>
>> So I'm confused, sorry.
>>
>> I do get that sometimes the result of a WGLC is "go ahead after
>> fixing these nits" but I don't see how that applies in a situation
>> with the fairly fundamental controversies we've seen related to
>> this draft.
>>
>> Cheers,
>> S.
>>
>>
>>
>> > Thanks,
>> >
>> > Sean and Joe
>> >
>> >
>> > _______________________________________________
>> > TLS mailing list -- tls@ietf.org
>> > To unsubscribe send an email to tls-leave@ietf.org
>>
>> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org


On Mon, Mar 23, 2026 at 11:52=E2=80=AFAM Joseph Salowey <joe@salowey.net> w=
rote:

>
>
> On Sun, Mar 22, 2026 at 11:04=E2=80=AFAM Stephen Farrell <
> stephen.farrell@cs.tcd.ie> wrote:
>
>>
>> Hi Joe,
>>
>> On 22/03/2026 17:49, Joseph Salowey wrote:
>> > ML-KEM WGLC Update
>> >
>> > We are working through issues brought up during the working group last
>> > call. We believe addressing these issues is necessary to determine if =
we
>> > have rough consensus to move forward. We expect the author to address
>> the
>> > following points:
>> >
>> > * Key Reuse
>> > * Text for preferring Hybrids
>> > * Whether to include motivations (see Liaison Statement)
>> >
>> > We expect resolving these issues will take a few weeks after which we
>> will
>> > run a targeted consensus call to see if text changes are acceptable to
>> the
>> > working group.
>>
>> The above seems to me unclear and hard to understand.
>>
>> Are you saying that the 2nd WGLC failed due to a lack of rough
>> consensus? (Or not?)
>>
>>
> [Joe] The chairs have determined that there is no rough consensus, but
> people have requested changes.  The chairs have asked the author to see i=
f
> changes to the draft make a difference.
>
>
>> Either way, I don't know what you mean by a "targeted consensus
>> call" - if the 2nd WGLC failed, then surely another WGLC will be
>> needed or the draft is just stalled. If the 2nd WGLC succeeded,
>> then (that'd be a surprise and) I don't get why some other consensus
>> call would be needed, nor for what.
>>
>>
> [Joe]  The intent here is to run a specific consensus call on the changed
> text.  If you suggested changes in the draft in the previous WGLCs then w=
e
> ask you to review and state whether the changes have helped (or not).  If
> you did not recommend changes, then your position will remain the same,
> unless you state that you are reconsidering.
>
>
>> So I'm confused, sorry.
>>
>> I do get that sometimes the result of a WGLC is "go ahead after
>> fixing these nits" but I don't see how that applies in a situation
>> with the fairly fundamental controversies we've seen related to
>> this draft.
>>
>> Cheers,
>> S.
>>
>>
>>
>> > Thanks,
>> >
>> > Sean and Joe
>> >
>> >
>> > _______________________________________________
>> > TLS mailing list -- tls@ietf.org
>> > To unsubscribe send an email to tls-leave@ietf.org
>>
>> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>

--000000000000822ba3064db589ae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hello TLS WG and chairs,<br><br>I&#39;d l=
ike to propose a renewal for the call for adoption of=C2=A0pure-mlkem=C2=A0=
(

<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/">https://=
datatracker.ietf.org/doc/draft-ietf-tls-mlkem/</a>) as an RFC out of the TL=
S WG.<br><br>This seems to move beyond Joe&#39;s recent comments here that =
the current intent is to run a specific consensus call on the changed text =
(regarding, by my understanding, the Motivation &amp; Security Consideratio=
n sections of=C2=A0<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-t=
ls-mlkem/">https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/</a>). Acc=
ordingly, further context and explanation is needed for this message than a=
 simple in-line reply.<br><br>Many years ago, I was NIST&#39;s lattice=C2=
=A0cryptographer during=C2=A0the (now) decade-long process of standardizing=
 ML-KEM. I apologize for my late arrival. I&#39;ve watched the steps within=
 the TLS working group from afar.<br>Admittedly, I have not been an active =
participant in the draft process for pure-mlkem=C2=A0in IETF&#39;s TLS WG t=
o this point.=C2=A0In terms of understanding the way in which IETF works, I=
 refer to RFC 7282,=C2=A0<a href=3D"https://datatracker.ietf.org/doc/html/r=
fc7282">https://datatracker.ietf.org/doc/html/rfc7282</a>. I&#39;m approach=
ing this discussion from that document, plus what I&#39;ve seen in the TLS =
WG mailing list discussion.<br><br>In the sense of RFC 7282, my previous po=
sition has been one of preemptive capitulation. In other words, &quot;Forge=
t it; do what you want.&quot; In the words of RFC 7282, this simply means &=
quot;That&#39;s not coming to consensus; there still exists an outstanding =
unaddressed objection.&quot; To wit, I notice that the first session of the=
 TLS WG at IETF 125 began with a recounting of a mailing list ban of DJB, a=
nd an first-item-issue in the WG of an apology by the chairs to DJB of acci=
dentally censoring a message of his. Having spent much time on the NIST PQC=
 Forum over the prior years, I can easily imagine the rough context of any =
such situation. (Who really wants to have a bitter fight via email messages=
 on an Internet forum?)<br><br>I am aware there was a recent &quot;mandator=
y call&quot; for pure-mlkem=C2=A0that recently failed. It might surprise th=
ose who know me to hear that I agree with that mandatory call failing. I do=
 not think it&#39;s the proper time for pure-mlkem to be mandatory.<br>None=
theless, there is a distinct difference between a mandatory requirement for=
 ML-KEM and simply an official option for ML-KEM-only.<br><br>Currently, I =
represent a major vendor in the space of secure communications. For our pri=
mary communications platform, we intend to offer ML-KEM-only as the straigh=
tforward implementation of TLS for our systems, at $100B+ scale. (I note a =
prior response in this thread indicates that gmail is doing the same.)<br><=
br>That is not to say that we don&#39;t intend to have hybrid systems. In p=
articular, for many of our systems, we are actively exploring systems that =
hybridize in an amortized way between ECC (e.g. X25519) and lattice-based c=
ryptography (ML-KEM-1024). That is, sometimes the significantly smaller ban=
dwidth of Curve25519 based ciphertexts is inherently necessary for current =
systems.<br><br><br>So, this gets to my <u><i>main first objection</i></u> =
to the current state of discussion (as held at the 125 meeting):<br><br>As =
a vendor, I=C2=A0believe both in the (current) security of X25519 and the (=
long-term) security of ML-KEM, while being cognizant of the quantum threat =
and HNDL. However, the efficiency profiles differ dramatically, and differe=
nt systems have different needs.<br>In contexts of challenging communicatio=
n environments, we require the low bandwidth of X25519 in order to have rel=
iable communications.<br>Yet on the other hand, when considering a basic TL=
S-based system -- e.g. a webserver connected to high-speed fiber with conve=
nient access to a reliable PKI, we believe that hybridizing between ECC+ML-=
KEM is the *worst of both worlds.*<br><br>In particular, consider the perfo=
rmance profiles of these two schemes: X25519 is noticeably slower to comput=
e in parallel, while smaller in bandwidth; ML-KEM is noticeably faster to c=
ompute in parallel, while higher in bandwidth.<br><u>In the most common/app=
licable use-case of TLS 1.3</u> -- i.e. high-bandwidth traffic with million=
s of billions of connections, over reliable infrastructure -- bandwidth is =
significantly less of a problem, and computation constraints are the major =
concern.<br>Simply put, for TLS 1.3,=C2=A0pure-mlkem=C2=A0is the obviously =
correct solution if you want high-performance solutions -- modulo security =
considerations (let&#39;s turn to that now.)<br><br><br>My <u><i>second obj=
ection</i></u> to the state of the discussion regards the call for CFRG/IRT=
F to render a fresh opinion on the cryptography of ML-KEM to the TLS WG:<br=
><br>There has been a full decade of entirely open, international analysis =
and debate over the security of quantum-resistant cryptography through the =
NIST PQC process.<br>ML-KEM was fully vetted through this process (despite =
various detractors that may feel otherwise).<br><br>Yet, the discussion in =
the TLS WG is not cryptographically detailed in the nature. <u>No new crypt=
analyses have been offered.</u> Just some grumbling.<br>Do we expect that a=
 call to the CFRG will report something significantly different in terms of=
 number theory and computational analyses that NIST&#39;s decade-long, inte=
rnational, open, and highly visible process did not? I think that seems wil=
dly unlikely.<br><br><br>My <u><i>third objection</i></u> to the discussion=
 regards the talk of &quot;Hard No&quot;s to prior WGLC&#39;s for=C2=A0pure=
-mlkem:<br><br>Certainly, there can be many &quot;absolutely not!&quot;s in=
 the discussion of whether to adopt this particular draft. However, that se=
ems to run counter to my understanding of=C2=A0

RFC 7282 in terms of the chairs&#39; opinion on whether rough consensus has=
 been achieved. Again, I am not calling for a mandatory use of ML-KEM-only;=
 and indeed, I plan to use ECC in various systems (with different performan=
ce constraints attached to them than the typical TLS use-cases).<br><br>How=
ever, to /deny/ the option for ML-KEM-only to be used in TLS 1.3 would seem=
 to be a shocking repudiation of the decade-long, international effort to t=
hat led to that cryptographic standard. Is it really an acceptable outcome =
that a more visible, international process led to the standardization /of t=
he primitive,/ and yet -- in the most obvious use-case in protocols (TLS 1.=
3 -- which has been the motivating protocol in every lecture I&#39;ve given=
 in university grad courses for years now) -- it should be fundamentally /d=
isallowed/?<br><br><br>My <u><i>fourth objection</i></u>, following up:<br>=
<br>At the 125 meeting, someone commented that &quot;well, hey -- IETF stan=
dardized the codepoints for ML-KEM. Isn&#39;t that enough?&quot; No!<br>Man=
y vendors will only support ML-KEM-only TLS if there is, specifically, an R=
FC from IETF specifying such.<br>A very common goal in industry these days =
is to ensure &quot;<u>no vendor-lock-in</u>&quot; for various products.<br>=
However, if this WG decides to disallow an RFC on ML-KEM-only TLS, then man=
y vendors will not produce products conforming to the natural outcome of th=
e NIST PQC process.<br><br>This would induce a punishing market effect on t=
he broader vendor ecosystem from a relatively obscure conversation in this =
WG&#39;s mailing list.<br><br><br>So, my general call is for the following:=
<br>1) Adopt hybrid-ECC-MLKEM=C2=A0for TLS 1.3<br>2) Adopt ML-KEM-only for =
TLS 1.3<br>2b) I strongly encourage neutral language in the RFC.<br>2c) &qu=
ot;Proponents of hybrid&quot; is not quite accurate, as there are not &quot=
;opponents of hybrid,&quot; but there *is* a significant vendor-community t=
hat is *also* a proponent of ML-KEM-only, for specific systems.<br><br><br>=
Finally, I&#39;ve had advice from a wise man who&#39;s active in this WG an=
d many others: &quot;Don&#39;t come, fly over, and drop bombs, then never c=
ontinue the conversation again.&quot;<br>Understood! I&#39;m happy to be he=
re until the cows come home.<br>I also intend to share the (alarming) statu=
s of the current discussion with others in the vendor community that want /=
an option/ for ML-KEM-only in TLS 1.3. This is *not* an effort to &quot;bal=
lot-stuff,&quot; but a genuine attempt to make others aware that the conver=
sation has gone so far here, without sufficient representative input, that =
a standards/RFC outcome is near that is entirely unexpected by many vendors=
.<br><br>Kind regards,<br>--Daniel Apon<br><br><br></div><br><div class=3D"=
gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On=
 Mon, Mar 23, 2026 at 11:52=E2=80=AFAM Joseph Salowey &lt;<a href=3D"mailto=
:joe@salowey.net">joe@salowey.net</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><br></di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On S=
un, Mar 22, 2026 at 11:04=E2=80=AFAM Stephen Farrell &lt;<a href=3D"mailto:=
stephen.farrell@cs.tcd.ie" target=3D"_blank">stephen.farrell@cs.tcd.ie</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Hi Joe,<br>
<br>
On 22/03/2026 17:49, Joseph Salowey wrote:<br>
&gt; ML-KEM WGLC Update<br>
&gt; <br>
&gt; We are working through issues brought up during the working group last=
<br>
&gt; call. We believe addressing these issues is necessary to determine if =
we<br>
&gt; have rough consensus to move forward. We expect the author to address =
the<br>
&gt; following points:<br>
&gt; <br>
&gt; * Key Reuse<br>
&gt; * Text for preferring Hybrids<br>
&gt; * Whether to include motivations (see Liaison Statement)<br>
&gt; <br>
&gt; We expect resolving these issues will take a few weeks after which we =
will<br>
&gt; run a targeted consensus call to see if text changes are acceptable to=
 the<br>
&gt; working group.<br>
<br>
The above seems to me unclear and hard to understand.<br>
<br>
Are you saying that the 2nd WGLC failed due to a lack of rough<br>
consensus? (Or not?)<br>
<br></blockquote><div><br></div><div>[Joe] The chairs have determined that =
there is no rough consensus, but people have requested changes.=C2=A0 The c=
hairs have asked the author to see if changes to the draft make a differenc=
e.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Either way, I don&#39;t know what you mean by a &quot;targeted consensus<br=
>
call&quot; - if the 2nd WGLC failed, then surely another WGLC will be<br>
needed or the draft is just stalled. If the 2nd WGLC succeeded,<br>
then (that&#39;d be a surprise and) I don&#39;t get why some other consensu=
s<br>
call would be needed, nor for what.<br>
<br></blockquote><div><br></div><div>[Joe] =C2=A0The intent here is to run =
a specific consensus call on the changed text.=C2=A0 If you suggested chang=
es in the draft in the previous WGLCs then we ask you to review and state w=
hether the changes have helped (or not).=C2=A0 If you did not recommend cha=
nges, then your position will remain the same, unless you state that you ar=
e reconsidering.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">
So I&#39;m confused, sorry.<br>
<br>
I do get that sometimes the result of a WGLC is &quot;go ahead after<br>
fixing these nits&quot; but I don&#39;t see how that applies in a situation=
<br>
with the fairly fundamental controversies we&#39;ve seen related to<br>
this draft.<br>
<br>
Cheers,<br>
S.<br>
<br>
<br>
<br>
&gt; Thanks,<br>
&gt; <br>
&gt; Sean and Joe<br>
&gt; <br>
&gt; <br>
&gt; _______________________________________________<br>
&gt; TLS mailing list -- <a href=3D"mailto:tls@ietf.org" target=3D"_blank">=
tls@ietf.org</a><br>
&gt; To unsubscribe send an email to <a href=3D"mailto:tls-leave@ietf.org" =
target=3D"_blank">tls-leave@ietf.org</a><br>
<br>
</blockquote></div></div>
_______________________________________________<br>
TLS mailing list -- <a href=3D"mailto:tls@ietf.org" target=3D"_blank">tls@i=
etf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:tls-leave@ietf.org" targe=
t=3D"_blank">tls-leave@ietf.org</a></blockquote></div></div><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">On Mon, Mar 23, 2026 at 11:52=E2=80=AFAM Joseph Salowey &lt;<a href=3D"ma=
ilto:joe@salowey.net">joe@salowey.net</a>&gt; wrote:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><br>=
</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">=
On Sun, Mar 22, 2026 at 11:04=E2=80=AFAM Stephen Farrell &lt;<a href=3D"mai=
lto:stephen.farrell@cs.tcd.ie" target=3D"_blank">stephen.farrell@cs.tcd.ie<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
br>
Hi Joe,<br>
<br>
On 22/03/2026 17:49, Joseph Salowey wrote:<br>
&gt; ML-KEM WGLC Update<br>
&gt; <br>
&gt; We are working through issues brought up during the working group last=
<br>
&gt; call. We believe addressing these issues is necessary to determine if =
we<br>
&gt; have rough consensus to move forward. We expect the author to address =
the<br>
&gt; following points:<br>
&gt; <br>
&gt; * Key Reuse<br>
&gt; * Text for preferring Hybrids<br>
&gt; * Whether to include motivations (see Liaison Statement)<br>
&gt; <br>
&gt; We expect resolving these issues will take a few weeks after which we =
will<br>
&gt; run a targeted consensus call to see if text changes are acceptable to=
 the<br>
&gt; working group.<br>
<br>
The above seems to me unclear and hard to understand.<br>
<br>
Are you saying that the 2nd WGLC failed due to a lack of rough<br>
consensus? (Or not?)<br>
<br></blockquote><div><br></div><div>[Joe] The chairs have determined that =
there is no rough consensus, but people have requested changes.=C2=A0 The c=
hairs have asked the author to see if changes to the draft make a differenc=
e.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Either way, I don&#39;t know what you mean by a &quot;targeted consensus<br=
>
call&quot; - if the 2nd WGLC failed, then surely another WGLC will be<br>
needed or the draft is just stalled. If the 2nd WGLC succeeded,<br>
then (that&#39;d be a surprise and) I don&#39;t get why some other consensu=
s<br>
call would be needed, nor for what.<br>
<br></blockquote><div><br></div><div>[Joe] =C2=A0The intent here is to run =
a specific consensus call on the changed text.=C2=A0 If you suggested chang=
es in the draft in the previous WGLCs then we ask you to review and state w=
hether the changes have helped (or not).=C2=A0 If you did not recommend cha=
nges, then your position will remain the same, unless you state that you ar=
e reconsidering.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">
So I&#39;m confused, sorry.<br>
<br>
I do get that sometimes the result of a WGLC is &quot;go ahead after<br>
fixing these nits&quot; but I don&#39;t see how that applies in a situation=
<br>
with the fairly fundamental controversies we&#39;ve seen related to<br>
this draft.<br>
<br>
Cheers,<br>
S.<br>
<br>
<br>
<br>
&gt; Thanks,<br>
&gt; <br>
&gt; Sean and Joe<br>
&gt; <br>
&gt; <br>
&gt; _______________________________________________<br>
&gt; TLS mailing list -- <a href=3D"mailto:tls@ietf.org" target=3D"_blank">=
tls@ietf.org</a><br>
&gt; To unsubscribe send an email to <a href=3D"mailto:tls-leave@ietf.org" =
target=3D"_blank">tls-leave@ietf.org</a><br>
<br>
</blockquote></div></div>
_______________________________________________<br>
TLS mailing list -- <a href=3D"mailto:tls@ietf.org" target=3D"_blank">tls@i=
etf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:tls-leave@ietf.org" targe=
t=3D"_blank">tls-leave@ietf.org</a><br>
</blockquote></div>

--000000000000822ba3064db589ae--