> On 6 Nov 2023, at 21:44, Watson Ladd <watsonbl...@gmail.com> wrote: > > > > On Mon, Nov 6, 2023, 10:07 AM Kris Kwiatkowski <k...@amongbytes.com > <mailto:k...@amongbytes.com>> wrote: >> So, based on FIPS 140-3 I.G., section C.K., resolution 5, [1]. "SP800-186 >> does not impact the curves permitted under SP 800-56Arev3. Curves that are >> included in SP 800-186 but not included in SP 800-56Arev3 are not approved >> for key agreement. E.g., the ECDH X25519 and X448 key agreement schemes >> (defined in RFC 7748) that use Curve25519 and Curve448, respectively, are >> not compliant to SP 800-56Arev3…”. This may potentially be a problem, right? >> >> I think to support FIPS requirements properly, we need both shares to be >> generated by FIPS approved methods. > > > Why do we need FIPS hybrids? The argument for hybrids is that we don't trust > the code/algorithms that's new. FIPS certification supposedly removes that > concern so can just use the approved PQ implementation.
I don’t know that we need hybrids, but NIST certification alone does not obviate the concern about them. They’re just new and different and we have (relatively) little experience with them. That said, protocols that can negotiate algorithms, like TLS or IKE or SSH can support several algorithms and avoid broken ones through configuration. This is not some long-term signature thing. Yoav
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
