[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