On Mon, 23 Mar 2026 at 02:08, Eric Rescorla <[email protected]> wrote: > > > > On Sun, Mar 22, 2026 at 2:56 PM Filippo Valsorda <[email protected]> > wrote: >> >> 2026-03-22 22:23 GMT+01:00 Muhammad Usama Sardar >> <[email protected]>: >> >> Hi Joe and Sean, >> >> I have the same concern as Stephen. Please precisely specify the binary >> outcome of the WGLC. >> >> Moreover, please add the following to the list: >> >> Bring an attestation of ML-KEM from Crypto Review Panel [0] of CFRG >> >> >> I’m sorry, what is a Crypto Review Panel “attestation,” what is it expected >> to bring over the multi-year, international NIST competition, and why would >> an IRTF opinion be blocking for an IETF document? > > > FWIW, I agree with you in the specific case of ML-KEM. > > To the broader question, I think that the IETF should avoid adopting > algorithms > that haven't seen a sufficient level of vetting. This could be provided by > CFRG > or, as you observe, by a multi-year international NIST competition. > There are also open source projects like OpenBSD which have integrated sntrup761 in hybrid mode within OpenSSH for a long time.
With security companies like Qualys constantly trying to find new vulnerabilities in openssh, I'm pretty sure that they would have found a vulnerability in x25519sntrup761 kex codebase by now ? NIST is a good option, but maybe we could get the perspective of folks like Markus Friedl (openssh) or Damien Miller (openssh) in the Crypto Review Panel ? > -Ekr > > _______________________________________________ > 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]
