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 <[email protected]> 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= > [email protected]> 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= >> [email protected]> 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 <[email protected]>: >>> >>>> >>>> >>>> On Tue, Jun 30, 2026 at 10:49 AM Justin Schnurbusch <schnurbusch.justin= >>>> [email protected]> 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 -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> >> >> -- >> >> Sophie Schmieg | Information Security Engineer | ISE Crypto | >> [email protected] >> >> _______________________________________________ >> TLS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
