[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

[Rob Sayre <[e-mail]>]

Since I am not lazy, I put it into Grammarly.

"Thanks. I will wear this score as a badge of honor for having some dude on
the internet go through the literal motions of tone policing my blog post."

But I think your style would call for using "literally" in there somewhere.

That doesn't make your point any better, but it does keep it consistent.

thanks,
Rob


On Wed, Jul 1, 2026 at 3:40 PM Sophie Schmieg <[e-mail]> wrote:

> Thanks. I will wear this score as a badge of honor of having some dude on
> the internet go through the literal motions of tone policing my blog post.
>
> On Wed, Jul 1, 2026 at 2:58 PM Rob Sayre <[e-mail]> wrote:
>
>> > score it for over-use of "literal" and "literally" as a tool for
>> dismissiveness.
>>
>> Counting literal/literally in the excerpts I pulledCounting
>> literal/literally in the excerpts I pulled
>>
>> Full-text count from the article: six instances — five "literally," one
>> "literal." Here they are, scored on whether each is doing rhetorical
>> dismissiveness vs. carrying actual meaning.
>> The dismissive ones (the tic you're asking about):
>> "
>> the literal author of the scheme" — pure appeal-to-authority intensifier.
>> "The author of the scheme" says the same thing. Dismissiveness score: high.
>> It's there to make disagreement feel absurd.
>>
>> "literally computers failing at their one job and not computing very
>> well" — comedic deflation. Doing tone work, not information work. High, but
>> it's self-aware enough that it mostly lands.
>>
>> "The flag has literally zero meaning" — intensifier on an
>> already-absolute ("zero"). Redundant; the "literally" exists only to
>> preclude pushback. High.
>>
>> "literally any practical cryptographic algorithm in existence is
>> vulnerable" — universal-claim armor. The "literally" pre-empts "well, what
>> about—". Medium-high, though the claim is close enough to true that it's
>> earned.
>>
>> The defensible ones:
>>
>> "3329 is literally the smallest prime that fits that bill" — here
>> "literally" is nearly correct usage: it means exactly this, no rounding.
>> Low.
>>
>> "it literally just counts from 2 to 4" — borderline. "Just" already does
>> the diminishing; "literally" is belt-and-suspenders. Medium.
>>
>> Overall score: 6.5/10 for dismissiveness-via-literally. Not egregious by
>> blog standards, but there's a detectable pattern where "literally" clusters
>> around exactly the points where she's most eager to shut down the
>> conspiracy reading — the author, the fault-attack ubiquity, the meaningless
>> flag. It's rhetorically load-bearing in a way that a stricter editor would
>> thin out, because each one is quietly converting "I'm confident about this"
>> into "you'd be ridiculous to doubt this." The math sections don't need it
>> and mostly don't use it; the debunking sections lean on it. That
>> correlation is the tell.
>>
>> thanks,
>> Rob
>>
>> On Wed, Jul 1, 2026 at 2:52 PM Sophie Schmieg <sschmieg=
>> [e-mail]> wrote:
>>
>>> As I mentioned in my blog post [1], MTI is a joke, invented to create
>>> more discussion in IETF mailing lists. There is no RFC police, and nobody
>>> can force anyone to implement an algorithm (other than, as David Benjamin
>>> noted, the null algorithm as that is the state of the uninitialized TLS
>>> stack). The flag you are looking for is the IANA recommended flag. And
>>> hybrids are recommended, pure ML-KEM is not.
>>>
>>> In general, the question here is not whether or not hybrid key exchange
>>> algorithms should be used or even should be used as default, it is whether
>>> anybody is allowed to not use a hybrid in a standardized fashion, if both
>>> sides of the connection agree to do so. (Insert meme: I consent/I consent/I
>>> don't).
>>>
>>> Hybrid key exchanges are recommended by the IETF, all browsers are
>>> implementing them by default, all server stacks that I'm aware of implement
>>> them by default. Meanwhile pure ML-KEM is afaik only implemented behind
>>> flags, in any browser or server stack I know of. Objecting this draft on
>>> the basis that hybrid is more secure and should be the default choice shows
>>> lack of understanding of the situation, likely caused by certain
>>> technically correct, but highly misleading statements one might have
>>> encountered on social media.
>>>
>>> [1] https://keymaterial.net/2025/11/27/ml-kem-mythbusting/
>>>
>>> On Wed, Jul 1, 2026 at 2:22 PM Justin Schnurbusch <schnurbusch.justin=
>>> [e-mail]> wrote:
>>>
>>>> Yes, you got that correct.
>>>>
>>>> The thing is that it seems to me (absolutely subjective) that there
>>>> needs to be a definitely secure baseline due to the nature of humans.
>>>>
>>>> Especially due to the fact that the hybrid implementations are slightly
>>>> less performant - some might take this as an argument to say "We don't do
>>>> hybrid here, look at the performance!" We all around this list know that
>>>> these performance differences are absolutely negligible - but that may be
>>>> not case everywhere.
>>>>
>>>> And, regarding the fact that the intended status of this draft is
>>>> informational, in combination with a MTI hybrid and a currently secure
>>>> baseline, I would support the publication of this draft.
>>>>
>>>> Kind regards
>>>> Justin
>>>>
>>>>
>>>> Am 30. Juni 2026 19:53:48 MESZ schrieb Eric Rescorla <[e-mail]>:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 30, 2026 at 10:49 AM Justin Schnurbusch
>>>>> <schnurbusch.justin=[e-mail]> wrote:
>>>>>
>>>>>> I do not support the publication of this document as it seems to me
>>>>>> that the implementations "in the field" need a currently secure baseline as
>>>>>> a mandatory border.
>>>>>>
>>>>>> A more baseline-mandatory approach with an optional component seems
>>>>>> more reasonable to me.
>>>>>>
>>>>>
>>>>> I'd like to make sure I understand your position: Are you saying that
>>>>> if some hybrid (e.g., X25519-MLKEM) were MTI, you would support this draft?
>>>>>
>>>>> -Ekr
>>>>>
>>>>> _______________________________________________
>>>> TLS mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>
>>>
>>> --
>>>
>>> Sophie Schmieg | Information Security Engineer | ISE Crypto |
>>> [e-mail]
>>>
>>> _______________________________________________
>>> TLS mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>
>
> --
>
> Sophie Schmieg | Information Security Engineer | ISE Crypto |
> [e-mail]
>
>