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 <paul= [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]
