On Tue, 14 Apr 2020, Andrew Cagney wrote: [ added swan-dev list]
Subject: Re: RE: Re: [Swan] Info on DSA and ECDSA support Would dropping the test be better?
So we have an interesting situation here. With the KDF code moving into NSS, there is nothing left to FIPS validate libreswan for. So in theory, we could remove all the #ifdef FIPS code. Except, for the use of ciphers, NSS does not enforce this since the application should know if the use is appropriate or not. Using MD5 for non-authentication, non-integrity is fine and is used (eg IKEv1 Vendor ID's are often MD5's of strings). So we would need to leave some of the FIPS checks in anyway. Than, if we do not run in FIPS mode, we still would want to enforce almost all restrictions and requirements that come in from FIPS anyway, since most of them realy make good sense. But where do we draw the line? Eg checking for too small RSA (or ECDSA) keys seems a good thing. But checking whether some elliptic curve parameter is valid or not, seems to be something that is better done by NSS. But if we let NSS do it, are we still protected when not running on a FIPS mode machine ? For fedora, I changed the compile to no longer build with USE_FIPSCHECK, but I think that option was badly overloaded. It handles both the startup pluto binary integrity check and the various FIPS requirements. I think the code for the binary check can be removed once we support the (hopefully final) IKEv1 Quick Mode KDF using NSS. But most of the "FIPS" checks for things like small keys, should be left in the code base, possibly as a compile time option, or changed into a "config setup" option so people can disable these checks. Although it would be a little weird to have fips=no in libreswan, and still have NSS reject things based on FIPS if the machine is running in FIPS mode. Thoughts? Paul
The RSA code can be traced back to: commit 50a40f8492b1a2849e2643c9be75436eeab611e4 Date: Sat Apr 21 17:49:01 2018 -0400 FIPS: reject RSA keys < 3072 bits - Patch by Matt Rogers This patch was forgotten and dormant in the fips_key_size branch If NSS is running in FIPS mode, it should also have rejected any operations with a < 3072 RSA bit, but we might as well reject it at load time instead of at use time. This comes across as a nice-to-have, but with the cost of us constantly having to update the logic. On Tue, 14 Apr 2020 at 17:54, Wewegama, Kavinda <[email protected]> wrote: Hi Paul, I just wanted to follow-up on the FIPS fixes for ECDSA for which I issued a pull request on GitHub (https://github.com/libreswan/libreswan/pull/321) to see if you had any feedback. Thanks. -Kavinda __________________________________________________________________________________________________________________________________________________ From: Wewegama, Kavinda Sent: Friday, March 27, 2020 5:35 PM To: Paul Wouters <[email protected]> Cc: Andrew Cagney <[email protected]>; Cesar Pereida <[email protected]>; [email protected] <[email protected]> Subject: Re: EXTERNAL: RE: Re: [Swan] Info on DSA and ECDSA support Hi Paul, I have attempted a fix for this and issued a pull request: https://github.com/libreswan/libreswan/pull/321 Thanks. -Kavinda __________________________________________________________________________________________________________________________________________________ From: Paul Wouters <[email protected]> Sent: Tuesday, March 24, 2020 12:05 AM To: Wewegama, Kavinda <[email protected]> Cc: Andrew Cagney <[email protected]>; Cesar Pereida <[email protected]>; [email protected] <[email protected]> Subject: EXTERNAL: RE: Re: [Swan] Info on DSA and ECDSA support On Tue, 24 Mar 2020, Wewegama, Kavinda wrote: > I have used ECDSA successfully with X.509 certificates *without* FIPS mode enabled. There are issues, however, when FIPS mode is enabled: https://github.com/libreswan/libreswan/issues/318 Thanks for the report, I will look into it. Paul
_______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
