Paul Wouters wrote: >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".
I agree with this. Having read through RFC 4086 again after some time, I think referencing it in RFC 9846 was a mistake. >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. The more I think about it, the more I believe it may be better to make RFC 4086 historic and publish a new BCP that simply recommends: “Use your operating system’s secure random source” and explains the rationale behind this guidance. >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. I agree. >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. I think something short and neutral, such as: “Note that the random m value is recoverable by the client.” would be sufficient. I do not think publication should be delayed over this. Cheers, John Preuß Mattsson From: Paul Wouters <[email protected]> Date: Monday, 13 July 2026 at 15:04 To: Stephen Farrell <[email protected]> Cc: [email protected] <[email protected]> Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08) 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]
