I agree with Richard that there is too much focus on NIST in this thread. The
strength with IETF is that IETF does not follow any specific national
regulation. It is impossible to follow all national regulations. That IETF uses
a lot of of NIST algorithms is not because IETF has to, but because NIST
algorithms typically are very good and selected in many yaer open projects with
leading cryptographers from around the world. Similar to how X25519 and X448
was selected by CFRG.
Cheers,
John
From: Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu>
Date: Thursday, 6 June 2024 at 02:24
To: Richard Barnes <r...@ipv.sx>, tls@ietf.org <tls@ietf.org>
Subject: [TLS]Re: [EXT] Re: Is NIST actually prohibiting X25519?
NIST cannot prohibit a curve, or an algorithm. But they may not approve it –
and for customers that require approved technology and algorithms, it would
prevent them from using anything that’s not explicitly approved.
--
V/R,
Uri
There are two ways to design a system. One is to make it so simple there are
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
- C. A. R. Hoare
From: Richard Barnes <r...@ipv.sx>
Date: Wednesday, June 5, 2024 at 20:20
To: tls@ietf.org <tls@ietf.org>
Subject: [EXT] [TLS]Re: Is NIST actually prohibiting X25519?
As with the earlier thread, this message is off-topic for this list.
Regardless of what NIST does, the TLS protocol does and will support a variety
of curves. On Wed, Jun 5, 2024 at 20: 14 D. J. Bernstein <djb@ cr. yp. to>
wrote: Andrei
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside the Laboratory.
ZjQcmQRYFpfptBannerEnd
As with the earlier thread, this message is off-topic for this list.
Regardless of what NIST does, the TLS protocol does and will support a variety
of curves.
On Wed, Jun 5, 2024 at 20:14 D. J. Bernstein
<d...@cr.yp.to<mailto:d...@cr.yp.to>> wrote:
Andrei Popov writes:
> This is a complicated compliance question. I'm not qualified to
> comment on this option.
I think it's worth investigating, considering the following NIST quote:
Their associated key agreement schemes, X25519 and X448, will be
considered for inclusion in a subsequent revision to SP 800-56A. The
CMVP does not intend to enforce compliance with SP 800-56A until
these revisions are complete.
https://web.archive.org/web/20200810165057/https://csrc.nist.gov/projects/cryptographic-module-validation-program/notices<https://web.archive.org/web/20200810165057/https:/csrc.nist.gov/projects/cryptographic-module-validation-program/notices>
Does anyone have any documents showing that NIST has reneged on the
above announcement? Possibilities:
* Yes: then I'd appreciate a pointer so that concerned members of the
community can tell NIST what they think about this and, hopefully,
get NIST to change course.
* No: then the announcement and consistent handling of this by NIST
would be another reason for IETF to not be dragged down by the
current limitations of NIST SP 800-56A.
If nobody has ever tried asking NIST to approve an X25519 solution as
per the above announcement, surely that would be a useful experiment,
creating a path towards simplifying subsequent TLS WG discussions.
---D. J. Bernstein
_______________________________________________
TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org>
To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
