[TLS] Re: Improving the quality of the discussion on the TLS email list

--===============2094247304095108996==
Content-Type: multipart/alternative; boundary="0000000000007e823f0657b32a6b"

--0000000000007e823f0657b32a6b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

It seems like the point you want to make, when condensed to be more
succinctly is that compute overhead of the handshake itself might be so
small that a factor of three does not constitute a major overhead. Indeed
the cost of compute overhead tends to vary substantially between network
architectures, with bandwidth usually far outweighing the cost of compute.
However, this is not the case for all networks, in particular connections
within a datacenter are usually compute constrained, not network latency
constrained. Deidre's point that there are situations where the hybrid has
non-negligible overhead is therefore simply true, at least for some use
cases.

But more importantly, this question is beside the point. Key exchange
algorithms in TLS are negotiated in a downgrade protected manner, and with
current stacks preferring (usually exclusively) hybrids over pure, the cost
or lack thereof of a hybrid is not an objection that should be seen as
material to standardization to begin with. So the good news is that all
your TLS connections will continue to use a hybrid, without you having to
pay a dime, with zero risk of a downgrade. You do not even having to change
your TLS configuration, as the hybrid is, as noted, default in all relevant
stacks. When using Chrome, you can check by hitting F12 and looking at the
security tab, where it should state which key exchange algorithm was
negotiated. Unless you deliberately change the defaults, and find a server
which will offer pure ML-KEM, this will always read X25519MLKEM768. Similar
functionality exists in other browsers, too, and they too go with
X25519MLKEM768 unless specifically configured otherwise by yourself.

The algorithm choices are part of the key derivation function call, and so
cannot be modified by an attacker without either forging a signature or
having the participants notice and subsequently fail the handshake (an
attacker with the power to modify traffic can always cause the handshake to
fail, so this is not a DOS vector).

As for conduct on the mailing list, my personal preference would be the
usage of smaller messages, especially when discussing overhead :). This
means that when using an LLM to draft a message, it is usually more
efficient to just send the prompt, instead of the usually fairly verbose
output of the LLM.

On Tue, Jul 28, 2026 at 2:16=E2=80=AFPM Paul Romer <romerp=3D40bc.edu@dmarc=
.ietf.org>
wrote:

> I started reading messages on the TLS list several weeks ago after a
> blog post by Daniel Bernstein surfaced on Hacker News calling
> attention to the then-pending decision about whether to publish
> "ML-KEM Post-Quantum Key Agreement for TLS 1.3" as an RFC.
>
> On the basis of what I read, I concluded that my status as a newcomer
> would disqualify me from participating in that decision. I withheld my
> comments until the decision was made.
>
> I share the concern that many members voice: the group discussion is
> dysfunctional. I'm writing now because I fear that suggestions about
> how to do better are not informed by an accurate diagnosis of the
> problem and that the measures being considered will make the
> underlying problem worse.
>
>
>
> # 1. Science as the Model for How To Reach a Consensus
>
> The oral tradition I absorbed as an undergraduate included a
> description of science that was attributed to Enrico Fermi: "Science
> is a process for reaching consensus." At the time, I vigorously
> disagreed. This description seemed to open the door to all kinds of
> unscientific ways to reach a consensus. But over time, I've come to
> appreciate it, provided we make explicit the assumption that consensus
> is voluntary. I'd rephrase it as:
>
>     **Science is the only social system that has ever achieved broad
> consensus without coercion.**
>
> Billions of people share a consensus that the earth is a spheroid, not
> a flat disk. To be sure, there are deniers. There are always deniers.
> But the consensus among billions is astonishing.
>
> My diagnosis of the problems with the TLS Working Group draws on my
> understanding of how scientists reach consensus.
>
> A. Participants agree on two principles:
>     - Evidence is the ultimate arbiter of truth.
>     - There are objective rules for logical inference.
>
> B. In their discourse, scientists exchange several types of "good"
> messages:
>     1. Good messages almost always focus on specifics that allow a
> direct connection to evidence.
>     2. Some good messages contribute new evidence and use logic to
> summarize the implications of the augmented body of evidence.
>     3. Other good messages challenge misstatements about the evidence
> cited by others.
>     4. Still other good messages uncover flaws in the logic used to
> draw implications from the available evidence.
>     5. When someone contributes a message that is subsequently shown
> to be false or misleading, this contributor sends a particularly
> important type of follow-up message that acknowledges the flaws in the
> contributor's message and recognizes the accuracy of the analysis by
> others.
>
> The striking thing about this list is that although it has many
> talented members, it receives few good messages. In what follows, I'll
> give specific examples, of missing messages: a message of type 2 and a
> message of type 4 that no one sent even though there surely were
> members who understood the points that these two messages convey.
> Because no one responded, an error persisted.
>
> More moderation will not get you the messages that this list needs.
> The missing messages suggest that a concern about what is permitted
> may already be encouraging people to self-censor. There are too many
> messages that contribute noise, but there are safer ways to limit the
> harm they do.
>
>
>
> # 2. Specifics
>
> Participants in scientific discussions focus doggedly on narrow
> assertions about specifics. This is how the community sustains its
> commitment to the principle that evidence is the ultimate arbiter of
> truth.
>
> In that spirit, I will focus on a specific email exchange from
> February 2026 that consists of an assertion and a response. Both are
> specific enough that one can assess whether they are accurate and on
> point.
>
> On 27 February 2026, Tibor Jager wrote:
>
>     "the use of hybrid crypto comes with negligible overhead,
>     as for ML-KEM + ECC."
>
> https://mailarchive.ietf.org/arch/msg/tls/4PcWkID3bs4M_-He_OL0jy5CyZY/
>
> That same day, Deirdre Connolly replied:
>
>     "X25519 is almost twice as slow as MLKEM768 (
>     https://blog.cloudflare.com/pq-2025/#ml-kem-versus-x25519)"
>
> https://mailarchive.ietf.org/arch/msg/tls/dSP0hWuwt_zVuMhZmGpMmftPJS4/
>
>
>
> # 3. Red Herrings and Intent
>
> According to Wikipedia, a red herring misleads or distracts from a
> relevant or important question. Someone can inject a red herring
> intentionally or inadvertently.
>
> Section 4 gives an example of a message of type 4 that finds fault
> with the logic of the response by Ms. Connolly. It shows that her
> response is a red herring. A simple arithmetic argument shows that the
> factor of 2 that she cites has zero bearing on the assertion by Mr.
> Jager.
>
> Section 5 has a message of type 2 that adds new evidence, in this
> case, evidence drawn from the source that Ms. Connolly cites. This new
> evidence supports Mr. Jager's assertion.
>
> Under the norms of science, the appropriate response to a red herring
> is to show how it misleads and correct it. This does not require any
> discussion about the intent of the person who contributed it. In fact,
> it would be a huge mistake to respond by launching an inquisition into
> intent. The red herring has already derailed the work of the group. An
> inquiry into intent compounds the damage by wasting time and energy
> that should be devoted to the work of the group, agreeing on specific
> assertions that are true.
>
> One clear sign of the dysfunction in this group is the many emails
> devoted to a discussion of intent. It is easy to understand the appeal
> of a system of moderation that could filter them out, but there are
> other possible responses, including the lighter touch of social
> pressure that discourages contributions that are off point. In section
> 6, "Reaching Consensus", I suggest another way to filter out cheap
> talk: require the author to use evidence and logic to reach a
> conclusion and ignore any messages that do not live up to this
> standard. This is an instance of what has come to be known as proof of
> work.
>
> One advantage of this particular type of proof of work is that it
> respects the sharp distinction that must be drawn between a good
> message that says "these facts and logic show that your assertion is
> wrong" and a bad message that says "many of us don't like what you are
> saying so please stop saying it."
>
> The way to get someone to stop making an assertion is to marshal
> evidence and logic which show that it is wrong. If you can't do this,
> you are the one who should stop.
>
> Filtering out the unhelpful messages should be a lower priority than
> soliciting more good ones that bring evidence and logic to bear on a
> narrow, specific question. This group needs more messages of type 2, 3
> and 4 to make sure that errors do not persist. The persistence of
> error is what undermines consensus.
>
> You may not agree with what I propose here, but until the group can
> articulate a principled distinction between good messages and
> unhelpful ones, it is dangerous to start down the path toward some
> vague notion of more stringent moderation, as many seemed inclined to
> do:
>
>     Poll: Should chairs be more draconian in doing moderation?
> y/n/no-opinion 65/2/7
>     https://notes.ietf.org/notes-ietf-126-tls
>
>     (Versions: Thu, Jul 23, 2026 3:42 AM - Thu, Jul 23, 2026 7:27 PM.
>     The question was subsequently edited to read "moderate more
> actively" in place of
>     "be more draconian." I imagine that the "draconian" version was
> what people were
>     responding to when they were polled.)
>
> The missing responses are the evidence for my claim that the current
> system of moderation is already encouraging people to self-censor.
>
>
>
> # 4. Clarifying the Red Herring
>
> Here's the first message that someone could have sent as a response to
> Ms. Connolly:
>
>     Ms. Connolly's response to Mr. Jager is a red herring. The factor
> of 2 that she cites has no bearing on the assertion by Mr. Jager that
> she quotes.
>
>     To establish this, define some variables:
>
>     xm =3D CPU seconds for the key-exchange computations required by
> X25519MLKEM768.
>
>     m =3D CPU seconds for the key-exchange computations required by MLKEM=
768.
>
>     x =3D CPU seconds for the key-exchange computations required by X2551=
9.
>
>     Ms. Connolly notes that r=3Dx/m=E2=89=882. The value that Mr. Jager r=
efers
> to as overhead is xm-m. As a rough approximation, xm will be equal to
> x+m so we can write
>
>           r =E2=89=88 (xm-m)/m.
>
>     For any given value of r, (xm-m) and m can vary together between
> zero and infinity.
>
>     Less formally, for a given value r=E2=89=882, the extra time required=
 to
> do the X25519 key-exchange, x, might be huge--2 hours of CPU time--in
> which case the time to do the MLKEM768 calculations will also be
> huge--1 hour of CPU time. In this case, running MLKEM768 instead of
> X25519MLKEM768 would save two hours of CPU time.
>
>      Or, the time x required for the X25519 calculations might be
> tiny--2 nanoseconds--in which case the time for MLKEM768 would also be
> small--1 nanosecond. In this case, using MLKEM768 instead of
> X25519MLKEM768 would save a negligible 2 nanoseconds of CPU time.
>
>     The reference to r=3Dx/m=E2=89=882 derails the discussion by getting =
the
> reader to stop paying attention to the relevant comparison (MLKEM768
> versus X25519MLKEM768) and focus instead on an irrelevant comparison
> (X25519 versus MLKEM768).
>
>
>
> # 5. Evidence That Supports Mr. Jager's Assertion
>
> Many people have asserted, as Mr. Jager does, that the additional CPU
> time required to run X25519 during a TLS 1.3 handshake is negligible.
> It might still have been helpful to respond to the message from Ms.
> Connolly by taking other measurements from her source and using them
> to support Mr. Jager's assertion that the CPU time is negligible.
>
> Here is a second message that does just that:
>
>     The table that Ms. Connolly cited in her response to Mr. Jager
> includes measurements that support his claim.
>     (https://blog.cloudflare.com/pq-2025/#ml-kem-versus-x25519)
>
>     The table does not provide data on xm, but we can estimate this
> value using the approximation xm =E2=89=88 x + m. This holds because what
> X25519MLKEM768 does is run both the X25519 and the MLKEM768
> key-exchange protocols. What Mr. Jager calls the overhead from
> X25519MLKEM768 is the extra CPU cycles required for X25519, which will
> be approximately equal to x.
>
>     If you invert the values from the Cloudflare table to get
> measurements with units of CPU seconds per TLS connection, the key
> observation is
>
>       Algorithm: X25519
>       Client seconds per op: 1/19000 =3D 5.3 * 10^(-5) seconds per TLS
> 1.3 connection
>       Server seconds per op: 1/19000 =3D 5.3 * 10^(-5) seconds per TLS
> 1.3 connection
>
>     The benefit from downgrading to MLKEM768 is the sum of the seconds
> saved on the client and the seconds saved on the server.
>
>     To convert this benefit into dollars, start with a conservative
> estimate of the AWS rental cost of a vCPU. The rate for a t4g.nano is
> $0.0042 per hour of wall time but this permits only occasional bursts
> of CPU. Unlimited mode costs $0.04 per vCPU hour for Graviton and
> $0.05 per vCPU hour for x86. A vCPU hour provides access to only one
> of the two hyper-threads that run on a physical core, so double the
> x86 price to get $0.10 per hour as the hourly rental rate for a core.
>
>      In dollars, the benefit B associated with x fewer CPU seconds is
>
>           B =3D x * ($0.1 per hour) * (1/3600 hours per second)
>              =3D $2.9 * 10^(-9)
>
>     In an absolute sense, a benefit on the order of $10^(-9) is negligibl=
e.
>
>     Any cost-benefit calculation has both a cost and a benefit. To
> assess the benefit relative to the cost, we can use the concept of
> "willingness to pay" to get an estimate of the cost. Suppose that I
> make 100 TLS 1.3 connections per day. (This is a "Feynman estimate"
> that restricts the possibilities to powers of 10. I make more than 10
> connections per day and fewer than 1000, so the answer I'll use is
> 100.)
>
>      I am willing to pay at least $10 to make sure that for the next
> 12 months, all my TLS 1.3 connections are covered by X25519MLKEM768
> instead of MLKEM768. This implies that a lower bound on the cost I'd
> suffer from the reduction in security of a downgrade to MLKEM768 is
> $10 / (365 * 100) =3D $2.7 * 10^(-4).
>
>     To summarize:
>         - Benefit from downgrading:
>               B =3D $2.9 * 10^(-9)
>
>         - Cost of downgrading:
>               C =3D $2.7 * 10^(-4)
>
>     Because the benefit is smaller by five orders of magnitude, it is
> negligible relative to the cost.
>
>
>
> # 6. Reaching Consensus
>
> If you disagree with my estimates, look for mistakes in my
> calculations. If I made any, show the correct calculation. If I agree,
> I'll say so.
>
> Make your own assumptions. Get your own data. You don't have to use
> the values from the table provided by Cloudflare. Fire up OpenSSL 3.5
> and use it to get estimates for x, m, and xm on your hardware. Try
> measuring CPU usage using wall time or CPU time. (On macOS, unless you
> are running lots of other apps concurrently, I found that they are
> very similar.)
>
> Once several group members provide estimates, I'm willing to bet that
> a consensus will emerge about the order of magnitude of the two
> critical values:
>     - B, the benefit from the downgrade to MLKEM768
>     - C, the cost in forgone security from the downgrade
>
> When I say consensus, I mean agreement among people who have made a
> credible attempt to estimate B and C. Coming up with credible
> estimates is an example of proof of work. It is a good way to identify
> the messages that matter. The others can safely be ignored.
>
> The consensus to seek is like the consensus that the earth is a
> spheroid. You have to ignore the deniers who can generate an endless
> word salad of inconsistencies, whataboutism, red herrings, and
> negative-attention-getting-behavior.
>
>
> # 7. Next Steps
>
> Once there is a consensus on the size of B and C, it would be
> revealing to consider these questions:
>
>     7.1. Given how central Mr. Jager's assertion about the magnitude
> of B is to the choice between X25519MLKEM768 and MLKEM768, why didn't
> anyone respond to the red herring that prevented any consideration of
> what he said?
>
>     7.2. Does Ms. Connolly now recognize that as a simple matter of
> arithmetic, the factor of 2 that she cited in her response to Mr.
> Jager tells us nothing about his assertion?
>
>     7.3. Do all members of the TLS Working Group now agree that Mr.
> Jager's assertion is true? To wit, when someone downgrades from the
> protocol that the group recommends, X25519MLKEM768, to the new
> MLKEM768 alternative, the benefit measured in CPU cycles saved is
> negligible both in an absolute sense and relative to the cost of the
> forgone security induced by the downgrade.
>
> The discussion of questions 7.1 and 7.2 will be of interest mainly to
> members of the group, but question 7.3 matters to people who have to
> make a decision about which PQ key-exchange protocol to adopt. As
> things stand, they now have reason to treat the TLS Working Group as a
> hesitant, unreliable advisor that for inexplicably, refuses to answer
> question 7.3. A pivot to more active moderation could further
> undermine their trust in the group.
>
> The proven way to build trust is to have an open discussion that
> addresses specific questions and converges to a clearly stated
> consensus about the answer. Question 7.3 might be a good place to
> start.
>
>
>
>
> # References
>
>     - I have never been able to confirm whether Fermi made the
> statement I attribute to him in section 1.
>
>     - The characterization offered here of the discussions that
> sustain science relies on _The Knowledge Machine_ by Michael Strevens.
>
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>


--=20

Sophie Schmieg | Information Security Engineer | ISE Crypto |
[email protected]

--0000000000007e823f0657b32a6b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It seems like the point you want to make, when condensed t=
o be more succinctly=C2=A0is that compute overhead of the handshake itself =
might be so small that a factor of three does not constitute a major overhe=
ad. Indeed the cost of compute overhead tends to vary substantially between=
 network architectures, with bandwidth usually far outweighing the cost of =
compute. However, this is not the case for all networks, in particular conn=
ections within a datacenter are usually compute constrained, not network la=
tency constrained. Deidre&#39;s point that there are situations where the h=
ybrid has non-negligible overhead is therefore simply true, at least for so=
me use cases.<div><br><div>But more importantly, this question is beside th=
e point. Key exchange algorithms in TLS are negotiated in a downgrade prote=
cted manner, and with current stacks preferring (usually exclusively) hybri=
ds over pure, the cost or lack thereof of a hybrid is not an objection that=
 should be seen as material to standardization to begin with. So the good n=
ews is that all your TLS connections will continue to use a hybrid, without=
 you having to pay a dime, with zero risk of a downgrade. You do not even h=
aving to change your TLS configuration, as the hybrid is, as noted, default=
 in all relevant stacks. When using Chrome, you can check by hitting F12 an=
d looking at the security tab, where it should state which key exchange alg=
orithm was negotiated. Unless you deliberately change the defaults, and fin=
d a server which will offer pure ML-KEM, this will always read X25519MLKEM7=
68. Similar functionality exists in other browsers, too, and they too go wi=
th X25519MLKEM768 unless specifically configured otherwise by yourself.</di=
v><div><br></div><div>The algorithm choices are part of the key derivation =
function call, and so cannot be modified by an attacker without either forg=
ing a signature or having the participants notice and subsequently fail the=
 handshake (an attacker with the power to modify traffic can always cause t=
he handshake to fail, so this is not a DOS vector).</div><div><br></div><di=
v>As for conduct on the mailing list, my personal preference would be the u=
sage of smaller messages, especially when discussing overhead :). This mean=
s that when using an LLM to draft a message, it is usually more efficient t=
o just send the prompt, instead of the usually fairly verbose output of the=
 LLM.</div></div></div><br><div class=3D"gmail_quote gmail_quote_container"=
><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 28, 2026 at 2:16=E2=80=
=AFPM Paul Romer &lt;romerp=3D<a href=3D"mailto:[email protected]">40=
[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">I started reading messages on the TLS list several wee=
ks ago after a<br>
blog post by Daniel Bernstein surfaced on Hacker News calling<br>
attention to the then-pending decision about whether to publish<br>
&quot;ML-KEM Post-Quantum Key Agreement for TLS 1.3&quot; as an RFC.<br>
<br>
On the basis of what I read, I concluded that my status as a newcomer<br>
would disqualify me from participating in that decision. I withheld my<br>
comments until the decision was made.<br>
<br>
I share the concern that many members voice: the group discussion is<br>
dysfunctional. I&#39;m writing now because I fear that suggestions about<br=
>
how to do better are not informed by an accurate diagnosis of the<br>
problem and that the measures being considered will make the<br>
underlying problem worse.<br>
<br>
<br>
<br>
# 1. Science as the Model for How To Reach a Consensus<br>
<br>
The oral tradition I absorbed as an undergraduate included a<br>
description of science that was attributed to Enrico Fermi: &quot;Science<b=
r>
is a process for reaching consensus.&quot; At the time, I vigorously<br>
disagreed. This description seemed to open the door to all kinds of<br>
unscientific ways to reach a consensus. But over time, I&#39;ve come to<br>
appreciate it, provided we make explicit the assumption that consensus<br>
is voluntary. I&#39;d rephrase it as:<br>
<br>
=C2=A0 =C2=A0 **Science is the only social system that has ever achieved br=
oad<br>
consensus without coercion.**<br>
<br>
Billions of people share a consensus that the earth is a spheroid, not<br>
a flat disk. To be sure, there are deniers. There are always deniers.<br>
But the consensus among billions is astonishing.<br>
<br>
My diagnosis of the problems with the TLS Working Group draws on my<br>
understanding of how scientists reach consensus.<br>
<br>
A. Participants agree on two principles:<br>
=C2=A0 =C2=A0 - Evidence is the ultimate arbiter of truth.<br>
=C2=A0 =C2=A0 - There are objective rules for logical inference.<br>
<br>
B. In their discourse, scientists exchange several types of &quot;good&quot=
; messages:<br>
=C2=A0 =C2=A0 1. Good messages almost always focus on specifics that allow =
a<br>
direct connection to evidence.<br>
=C2=A0 =C2=A0 2. Some good messages contribute new evidence and use logic t=
o<br>
summarize the implications of the augmented body of evidence.<br>
=C2=A0 =C2=A0 3. Other good messages challenge misstatements about the evid=
ence<br>
cited by others.<br>
=C2=A0 =C2=A0 4. Still other good messages uncover flaws in the logic used =
to<br>
draw implications from the available evidence.<br>
=C2=A0 =C2=A0 5. When someone contributes a message that is subsequently sh=
own<br>
to be false or misleading, this contributor sends a particularly<br>
important type of follow-up message that acknowledges the flaws in the<br>
contributor&#39;s message and recognizes the accuracy of the analysis by<br=
>
others.<br>
<br>
The striking thing about this list is that although it has many<br>
talented members, it receives few good messages. In what follows, I&#39;ll<=
br>
give specific examples, of missing messages: a message of type 2 and a<br>
message of type 4 that no one sent even though there surely were<br>
members who understood the points that these two messages convey.<br>
Because no one responded, an error persisted.<br>
<br>
More moderation will not get you the messages that this list needs.<br>
The missing messages suggest that a concern about what is permitted<br>
may already be encouraging people to self-censor. There are too many<br>
messages that contribute noise, but there are safer ways to limit the<br>
harm they do.<br>
<br>
<br>
<br>
# 2. Specifics<br>
<br>
Participants in scientific discussions focus doggedly on narrow<br>
assertions about specifics. This is how the community sustains its<br>
commitment to the principle that evidence is the ultimate arbiter of<br>
truth.<br>
<br>
In that spirit, I will focus on a specific email exchange from<br>
February 2026 that consists of an assertion and a response. Both are<br>
specific enough that one can assess whether they are accurate and on<br>
point.<br>
<br>
On 27 February 2026, Tibor Jager wrote:<br>
<br>
=C2=A0 =C2=A0 &quot;the use of hybrid crypto comes with negligible overhead=
,<br>
=C2=A0 =C2=A0 as for ML-KEM + ECC.&quot;<br>
<br>
<a href=3D"https://mailarchive.ietf.org/arch/msg/tls/4PcWkID3bs4M_-He_OL0jy=
5CyZY/" rel=3D"noreferrer" target=3D"_blank">https://mailarchive.ietf.org/a=
rch/msg/tls/4PcWkID3bs4M_-He_OL0jy5CyZY/</a><br>
<br>
That same day, Deirdre Connolly replied:<br>
<br>
=C2=A0 =C2=A0 &quot;X25519 is almost twice as slow as MLKEM768 (<br>
=C2=A0 =C2=A0 <a href=3D"https://blog.cloudflare.com/pq-2025/#ml-kem-versus=
-x25519" rel=3D"noreferrer" target=3D"_blank">https://blog.cloudflare.com/p=
q-2025/#ml-kem-versus-x25519</a>)&quot;<br>
<br>
<a href=3D"https://mailarchive.ietf.org/arch/msg/tls/dSP0hWuwt_zVuMhZmGpMmf=
tPJS4/" rel=3D"noreferrer" target=3D"_blank">https://mailarchive.ietf.org/a=
rch/msg/tls/dSP0hWuwt_zVuMhZmGpMmftPJS4/</a><br>
<br>
<br>
<br>
# 3. Red Herrings and Intent<br>
<br>
According to Wikipedia, a red herring misleads or distracts from a<br>
relevant or important question. Someone can inject a red herring<br>
intentionally or inadvertently.<br>
<br>
Section 4 gives an example of a message of type 4 that finds fault<br>
with the logic of the response by Ms. Connolly. It shows that her<br>
response is a red herring. A simple arithmetic argument shows that the<br>
factor of 2 that she cites has zero bearing on the assertion by Mr.<br>
Jager.<br>
<br>
Section 5 has a message of type 2 that adds new evidence, in this<br>
case, evidence drawn from the source that Ms. Connolly cites. This new<br>
evidence supports Mr. Jager&#39;s assertion.<br>
<br>
Under the norms of science, the appropriate response to a red herring<br>
is to show how it misleads and correct it. This does not require any<br>
discussion about the intent of the person who contributed it. In fact,<br>
it would be a huge mistake to respond by launching an inquisition into<br>
intent. The red herring has already derailed the work of the group. An<br>
inquiry into intent compounds the damage by wasting time and energy<br>
that should be devoted to the work of the group, agreeing on specific<br>
assertions that are true.<br>
<br>
One clear sign of the dysfunction in this group is the many emails<br>
devoted to a discussion of intent. It is easy to understand the appeal<br>
of a system of moderation that could filter them out, but there are<br>
other possible responses, including the lighter touch of social<br>
pressure that discourages contributions that are off point. In section<br>
6, &quot;Reaching Consensus&quot;, I suggest another way to filter out chea=
p<br>
talk: require the author to use evidence and logic to reach a<br>
conclusion and ignore any messages that do not live up to this<br>
standard. This is an instance of what has come to be known as proof of<br>
work.<br>
<br>
One advantage of this particular type of proof of work is that it<br>
respects the sharp distinction that must be drawn between a good<br>
message that says &quot;these facts and logic show that your assertion is<b=
r>
wrong&quot; and a bad message that says &quot;many of us don&#39;t like wha=
t you are<br>
saying so please stop saying it.&quot;<br>
<br>
The way to get someone to stop making an assertion is to marshal<br>
evidence and logic which show that it is wrong. If you can&#39;t do this,<b=
r>
you are the one who should stop.<br>
<br>
Filtering out the unhelpful messages should be a lower priority than<br>
soliciting more good ones that bring evidence and logic to bear on a<br>
narrow, specific question. This group needs more messages of type 2, 3<br>
and 4 to make sure that errors do not persist. The persistence of<br>
error is what undermines consensus.<br>
<br>
You may not agree with what I propose here, but until the group can<br>
articulate a principled distinction between good messages and<br>
unhelpful ones, it is dangerous to start down the path toward some<br>
vague notion of more stringent moderation, as many seemed inclined to<br>
do:<br>
<br>
=C2=A0 =C2=A0 Poll: Should chairs be more draconian in doing moderation?<br=
>
y/n/no-opinion 65/2/7<br>
=C2=A0 =C2=A0 <a href=3D"https://notes.ietf.org/notes-ietf-126-tls" rel=3D"=
noreferrer" target=3D"_blank">https://notes.ietf.org/notes-ietf-126-tls</a>=
<br>
<br>
=C2=A0 =C2=A0 (Versions: Thu, Jul 23, 2026 3:42 AM - Thu, Jul 23, 2026 7:27=
 PM.<br>
=C2=A0 =C2=A0 The question was subsequently edited to read &quot;moderate m=
ore<br>
actively&quot; in place of<br>
=C2=A0 =C2=A0 &quot;be more draconian.&quot; I imagine that the &quot;draco=
nian&quot; version was<br>
what people were<br>
=C2=A0 =C2=A0 responding to when they were polled.)<br>
<br>
The missing responses are the evidence for my claim that the current<br>
system of moderation is already encouraging people to self-censor.<br>
<br>
<br>
<br>
# 4. Clarifying the Red Herring<br>
<br>
Here&#39;s the first message that someone could have sent as a response to<=
br>
Ms. Connolly:<br>
<br>
=C2=A0 =C2=A0 Ms. Connolly&#39;s response to Mr. Jager is a red herring. Th=
e factor<br>
of 2 that she cites has no bearing on the assertion by Mr. Jager that<br>
she quotes.<br>
<br>
=C2=A0 =C2=A0 To establish this, define some variables:<br>
<br>
=C2=A0 =C2=A0 xm =3D CPU seconds for the key-exchange computations required=
 by<br>
X25519MLKEM768.<br>
<br>
=C2=A0 =C2=A0 m =3D CPU seconds for the key-exchange computations required =
by MLKEM768.<br>
<br>
=C2=A0 =C2=A0 x =3D CPU seconds for the key-exchange computations required =
by X25519.<br>
<br>
=C2=A0 =C2=A0 Ms. Connolly notes that r=3Dx/m=E2=89=882. The value that Mr.=
 Jager refers<br>
to as overhead is xm-m. As a rough approximation, xm will be equal to<br>
x+m so we can write<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 r =E2=89=88 (xm-m)/m.<br>
<br>
=C2=A0 =C2=A0 For any given value of r, (xm-m) and m can vary together betw=
een<br>
zero and infinity.<br>
<br>
=C2=A0 =C2=A0 Less formally, for a given value r=E2=89=882, the extra time =
required to<br>
do the X25519 key-exchange, x, might be huge--2 hours of CPU time--in<br>
which case the time to do the MLKEM768 calculations will also be<br>
huge--1 hour of CPU time. In this case, running MLKEM768 instead of<br>
X25519MLKEM768 would save two hours of CPU time.<br>
<br>
=C2=A0 =C2=A0 =C2=A0Or, the time x required for the X25519 calculations mig=
ht be<br>
tiny--2 nanoseconds--in which case the time for MLKEM768 would also be<br>
small--1 nanosecond. In this case, using MLKEM768 instead of<br>
X25519MLKEM768 would save a negligible 2 nanoseconds of CPU time.<br>
<br>
=C2=A0 =C2=A0 The reference to r=3Dx/m=E2=89=882 derails the discussion by =
getting the<br>
reader to stop paying attention to the relevant comparison (MLKEM768<br>
versus X25519MLKEM768) and focus instead on an irrelevant comparison<br>
(X25519 versus MLKEM768).<br>
<br>
<br>
<br>
# 5. Evidence That Supports Mr. Jager&#39;s Assertion<br>
<br>
Many people have asserted, as Mr. Jager does, that the additional CPU<br>
time required to run X25519 during a TLS 1.3 handshake is negligible.<br>
It might still have been helpful to respond to the message from Ms.<br>
Connolly by taking other measurements from her source and using them<br>
to support Mr. Jager&#39;s assertion that the CPU time is negligible.<br>
<br>
Here is a second message that does just that:<br>
<br>
=C2=A0 =C2=A0 The table that Ms. Connolly cited in her response to Mr. Jage=
r<br>
includes measurements that support his claim.<br>
=C2=A0 =C2=A0 (<a href=3D"https://blog.cloudflare.com/pq-2025/#ml-kem-versu=
s-x25519" rel=3D"noreferrer" target=3D"_blank">https://blog.cloudflare.com/=
pq-2025/#ml-kem-versus-x25519</a>)<br>
<br>
=C2=A0 =C2=A0 The table does not provide data on xm, but we can estimate th=
is<br>
value using the approximation xm =E2=89=88 x + m. This holds because what<b=
r>
X25519MLKEM768 does is run both the X25519 and the MLKEM768<br>
key-exchange protocols. What Mr. Jager calls the overhead from<br>
X25519MLKEM768 is the extra CPU cycles required for X25519, which will<br>
be approximately equal to x.<br>
<br>
=C2=A0 =C2=A0 If you invert the values from the Cloudflare table to get<br>
measurements with units of CPU seconds per TLS connection, the key<br>
observation is<br>
<br>
=C2=A0 =C2=A0 =C2=A0 Algorithm: X25519<br>
=C2=A0 =C2=A0 =C2=A0 Client seconds per op: 1/19000 =3D 5.3 * 10^(-5) secon=
ds per TLS<br>
1.3 connection<br>
=C2=A0 =C2=A0 =C2=A0 Server seconds per op: 1/19000 =3D 5.3 * 10^(-5) secon=
ds per TLS<br>
1.3 connection<br>
<br>
=C2=A0 =C2=A0 The benefit from downgrading to MLKEM768 is the sum of the se=
conds<br>
saved on the client and the seconds saved on the server.<br>
<br>
=C2=A0 =C2=A0 To convert this benefit into dollars, start with a conservati=
ve<br>
estimate of the AWS rental cost of a vCPU. The rate for a t4g.nano is<br>
$0.0042 per hour of wall time but this permits only occasional bursts<br>
of CPU. Unlimited mode costs $0.04 per vCPU hour for Graviton and<br>
$0.05 per vCPU hour for x86. A vCPU hour provides access to only one<br>
of the two hyper-threads that run on a physical core, so double the<br>
x86 price to get $0.10 per hour as the hourly rental rate for a core.<br>
<br>
=C2=A0 =C2=A0 =C2=A0In dollars, the benefit B associated with x fewer CPU s=
econds is<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 B =3D x * ($0.1 per hour) * (1/3600 hour=
s per second)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D $2.9 * 10^(-9)<br>
<br>
=C2=A0 =C2=A0 In an absolute sense, a benefit on the order of $10^(-9) is n=
egligible.<br>
<br>
=C2=A0 =C2=A0 Any cost-benefit calculation has both a cost and a benefit. T=
o<br>
assess the benefit relative to the cost, we can use the concept of<br>
&quot;willingness to pay&quot; to get an estimate of the cost. Suppose that=
 I<br>
make 100 TLS 1.3 connections per day. (This is a &quot;Feynman estimate&quo=
t;<br>
that restricts the possibilities to powers of 10. I make more than 10<br>
connections per day and fewer than 1000, so the answer I&#39;ll use is<br>
100.)<br>
<br>
=C2=A0 =C2=A0 =C2=A0I am willing to pay at least $10 to make sure that for =
the next<br>
12 months, all my TLS 1.3 connections are covered by X25519MLKEM768<br>
instead of MLKEM768. This implies that a lower bound on the cost I&#39;d<br=
>
suffer from the reduction in security of a downgrade to MLKEM768 is<br>
$10 / (365 * 100) =3D $2.7 * 10^(-4).<br>
<br>
=C2=A0 =C2=A0 To summarize:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Benefit from downgrading:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 B =3D $2.9 * 10^(-9)<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Cost of downgrading:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 C =3D $2.7 * 10^(-4)<br>
<br>
=C2=A0 =C2=A0 Because the benefit is smaller by five orders of magnitude, i=
t is<br>
negligible relative to the cost.<br>
<br>
<br>
<br>
# 6. Reaching Consensus<br>
<br>
If you disagree with my estimates, look for mistakes in my<br>
calculations. If I made any, show the correct calculation. If I agree,<br>
I&#39;ll say so.<br>
<br>
Make your own assumptions. Get your own data. You don&#39;t have to use<br>
the values from the table provided by Cloudflare. Fire up OpenSSL 3.5<br>
and use it to get estimates for x, m, and xm on your hardware. Try<br>
measuring CPU usage using wall time or CPU time. (On macOS, unless you<br>
are running lots of other apps concurrently, I found that they are<br>
very similar.)<br>
<br>
Once several group members provide estimates, I&#39;m willing to bet that<b=
r>
a consensus will emerge about the order of magnitude of the two<br>
critical values:<br>
=C2=A0 =C2=A0 - B, the benefit from the downgrade to MLKEM768<br>
=C2=A0 =C2=A0 - C, the cost in forgone security from the downgrade<br>
<br>
When I say consensus, I mean agreement among people who have made a<br>
credible attempt to estimate B and C. Coming up with credible<br>
estimates is an example of proof of work. It is a good way to identify<br>
the messages that matter. The others can safely be ignored.<br>
<br>
The consensus to seek is like the consensus that the earth is a<br>
spheroid. You have to ignore the deniers who can generate an endless<br>
word salad of inconsistencies, whataboutism, red herrings, and<br>
negative-attention-getting-behavior.<br>
<br>
<br>
# 7. Next Steps<br>
<br>
Once there is a consensus on the size of B and C, it would be<br>
revealing to consider these questions:<br>
<br>
=C2=A0 =C2=A0 7.1. Given how central Mr. Jager&#39;s assertion about the ma=
gnitude<br>
of B is to the choice between X25519MLKEM768 and MLKEM768, why didn&#39;t<b=
r>
anyone respond to the red herring that prevented any consideration of<br>
what he said?<br>
<br>
=C2=A0 =C2=A0 7.2. Does Ms. Connolly now recognize that as a simple matter =
of<br>
arithmetic, the factor of 2 that she cited in her response to Mr.<br>
Jager tells us nothing about his assertion?<br>
<br>
=C2=A0 =C2=A0 7.3. Do all members of the TLS Working Group now agree that M=
r.<br>
Jager&#39;s assertion is true? To wit, when someone downgrades from the<br>
protocol that the group recommends, X25519MLKEM768, to the new<br>
MLKEM768 alternative, the benefit measured in CPU cycles saved is<br>
negligible both in an absolute sense and relative to the cost of the<br>
forgone security induced by the downgrade.<br>
<br>
The discussion of questions 7.1 and 7.2 will be of interest mainly to<br>
members of the group, but question 7.3 matters to people who have to<br>
make a decision about which PQ key-exchange protocol to adopt. As<br>
things stand, they now have reason to treat the TLS Working Group as a<br>
hesitant, unreliable advisor that for inexplicably, refuses to answer<br>
question 7.3. A pivot to more active moderation could further<br>
undermine their trust in the group.<br>
<br>
The proven way to build trust is to have an open discussion that<br>
addresses specific questions and converges to a clearly stated<br>
consensus about the answer. Question 7.3 might be a good place to<br>
start.<br>
<br>
<br>
<br>
<br>
# References<br>
<br>
=C2=A0 =C2=A0 - I have never been able to confirm whether Fermi made the<br=
>
statement I attribute to him in section 1.<br>
<br>
=C2=A0 =C2=A0 - The characterization offered here of the discussions that<b=
r>
sustain science relies on _The Knowledge Machine_ by Michael Strevens.<br>
<br>
_______________________________________________<br>
TLS mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blank">tls@i=
etf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:[email protected]" targe=
t=3D"_blank">[email protected]</a><br>
</blockquote></div><div><br clear=3D"all"></div><div><br></div><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div=
><div dir=3D"ltr"><div><div dir=3D"ltr"><div style=3D"line-height:1.5em;pad=
ding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif;fo=
nt-size:small"><span style=3D"border-width:2px 0px 0px;border-style:solid;b=
order-color:rgb(213,15,37);padding-top:2px;margin-top:2px"><br>Sophie Schmi=
eg=C2=A0|</span><span style=3D"border-width:2px 0px 0px;border-style:solid;=
border-color:rgb(51,105,232);padding-top:2px;margin-top:2px">=C2=A0Informat=
ion Security Engineer=C2=A0|</span><span style=3D"border-width:2px 0px 0px;=
border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2p=
x">=C2=A0ISE Crypto=C2=A0|</span><span style=3D"border-width:2px 0px 0px;bo=
rder-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2p=
x">=C2=A0<a href=3D"mailto:[email protected]" target=3D"_blank">sschmieg@=
google.com</a></span></div><div><span style=3D"border-width:2px 0px 0px;bor=
der-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px=
"><br></span></div><span style=3D"color:rgb(0,0,0);font-family:&quot;Times =
New Roman&quot;;font-size:medium"></span></div></div></div></div></div></di=
v></div></div></div></div>

--0000000000007e823f0657b32a6b--


--===============2094247304095108996==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVExTIG1haWxp
bmcgbGlzdCAtLSB0bHNAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB0
bHMtbGVhdmVAaWV0Zi5vcmcK

--===============2094247304095108996==--