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

[Rob Sayre <[e-mail]>]

> 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]
>