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

"Blumenthal, Uri - 0553 - MITLL" <[email protected]> Mon, 13 Jul 2026 14:05:08 +0000
Newsgroups gmane.ietf.tls
Message-ID <[email protected]>
I’m with Paul and Soatok.

This “unproductive expenditure of time” has been dragging on long enough.

—
Regards,
Uri

Secure Resilient Systems and Technologies

MIT Lincoln Laboratory

On Jul 13, 2026, at 09:17, Soatok Dreamseeker <[email protected]> wrote:

.









ZjQcmQRYFpfptBannerEnd





I support adding the same sentence(s) to all relevant drafts, or none of them. I do not support an incomplete subset of the drafts being considered, for the same reason Paul stated.

On Mon, Jul 13, 2026 at 9:04 AM Paul Wouters <[email protected] > wrote:

On Sun, 12 Jul 2026, Stephen Farrell wrote:



> The above seems sensible. IIRC 4086 was AD sponsored, which'd have

> been my initial take on how to process a successor, but it's quite

> arguable that a WG could be better now, esp since we have new fancy

> crypto here and there (e.g. ppm) where some new issues might arise.

> A WG is probably more likely to result in such issues being thought

> through.



A year (or two?) ago, the SEC ADs looked at having some people create a

4086bis, as we kept running into drafts that would reference 4086 but it

was so outdated it was better not to reference that but instead say "use

your OS secure random source". Only the SSHM WG purposefully did not

include a reference to it (and I believe they wrote a few lines of text

in their RFCs basically saying "just use your OS RNG, these are better

that your homegrown stuff". The SEC ADs at the time didn't feel we got a

good segment of volunteers with modern OS knowledge together for them to

write a 4086bis, so yes perhaps a WG would be a better approach.



That said, a 4086bis would mostly target people who are not very

familiar with cryptographic requirements. I feel any algorithm document

specification would be implemented by people who should know enough on

cryptographically strong random sources to not need such sentences, and

I'm perfectly fine not adding anything to either mlkem drafts.



I do think this discussion is more a red herring against pure mlkem than a

real argument for text being really needed into these drafts. But provided

both drafts get equal treatment getting the same sentence(s) added on

randomness to avoid conspiracy theories and bad faith citations of the

differences, I think this is okay to do. Which does means we would have

to do this quickly as the hybrid mlkem is now in the RFC Editor queue.



Paul



_______________________________________________

TLS mailing list -- [email protected]

To unsubscribe send an email to [email protected]



_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
smime.p7s (application/pkcs7-signature, 5.8 KB) - not displayed