On Sun, Mar 22, 2026 at 11:56 PM Loganaden Velvindron <[email protected]> wrote:
> 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 ? > The question is not about the security of the code but rather the security of the algorithm. -Ekr > > 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]
