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

[Sophie Schmieg <[e-mail]>]

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]