MIME-Version: 1.0 In-Reply-To: X-RT-Original-Encoding: utf-8 Message-ID: X-RT-Interface: Web References: <20180116174037.GA74508@isc.org> <4230b306-87ec-ca1b-b1f2-4ae2c59f9ffc@redhat.com> X-Mailer: MIME-tools 5.508 (Entity 5.508) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: binary Content-Disposition: inline RT-Send-CC: Content-Length: 4399 On Wed Jan 17 20:37:01 2018, pemensik@redhat.com wrote: > Thank you Ondrej. Hello Francis, Hello Evan. > > Unfortunately I am not happy with this fix at all. It completely > missed > our intention and actually moved us even farther from solving our > issue. => my interpretation of the FIPS mode according to the Guidance document is that in FIPS mode not-approved crypto must not be used and this applies to applications ("user" in FIPS terms) too. So I can see 3 different solutions, none perfect of course: 1- build one bind package with MD5, DSA and DH disabled (DSA because it uses old and unsafe parameters, DH for the same reason and because its only usage implies MD5). It should work well in both FIPS mode enabled or disabled, the only obvious drawback is it does not work (in fact it impossible to configure) with TSIG HMAC-MD5. Note command usages are updated too so attempts to use MD5 raise understandable errors. I don't consider old rndc versions because rndc should come with named and do not accept old configs using MD5 at both sides is IMHO a good thing as soon as error messages are clear about the problem. 2- build two packages. 3- Disable FIPS mode when MD5 is enabled at initialization time, or build bind with internal MD5 code. In both case they make bind behaves as without FIPS but I am not a big fan of them because they clearly defeat the FIPS mode idea. > Once FIPS mode is enabled in target system, crypto library disables > support for MD5. Any try to use md5 will result in error. => it does not make sense: either MD5 is supported or it is not. > Only difference we would like archieve behavior similar to defined > PK11_MD5_DISABLE in pk11/site.h. => the PK11_MD5_DISABLE feature comes from an old (2008) ticket opened by Adam Tkac from Red Hat about FIPS mode support. At that time the FIPS code was the OpenSSL FIPS object module and it was clear that a bind using it should not have MD5 support. It was never released but it leads to remove first MD5 dependencies and after defaults. When HSMs without MD5 support appeared the site.h file was added to allows them to be used. For different reasons, for instance recommendations of early OpenSSL FIPS guides, it was chosen to disable MD5 by an option at build time. BTW it provides a strong guarantee that MD5 code cannot be called: as it is not in the binary it is not reachable. Of course you can object that it is to make security before usability... If you have an usage for it the -P flag was reserved in all command arguments at that time for switching to FIPS mode per application. > That means any request to use MD5 will fail like it was > not supported at all. => note this applies to configuration / command line arguments, etc, not to the MD5 low level crypto. Or with other words the PK11_MD5_DISABLE approach is the right one and your concern is it is a built time vs. run time. > Because we support older version 9.9 which does not contain different > than HMAC-MD5 rndc key support, we cannot remove whole support from > the build. => argh! Partially my fault as I was late to convince my colleagues to go far from MD5. As far as I know 9.9 is EOL in June. > Current RT #46764 patch committed with id > 614d838acf4e4b61523a044fde014d8ee7f60e70 would not help us. In fact, > we > would have to revert that in our code to support FIPS mode. => it is in #ifndef PK11_MD5_DISABLE code so anyway you have to address it. IMHO you should keep it downgrading to a sanity check: if it is reached something went really wrong before. And it includes better error messages. > I am sorry I was not clear enough from the start. This patch would > prevent us starting named in FIPS mode. => prevent to start a named (or any command using crypto) which wants to freely use MD5. > We would like to use --with-openssl-hash in the future. => BTW another heritage of the old FIPS mode work with in addition the fact that OpenSSL is clearly faster (visible different with NSEC3 iterated hash). It was recently made the default when bind is built with OpenSSL. > Our current > problem is with --enable-native-pkcs11 variant. => as no HSM implements a consistent subset of PKCS#11 I am afraid the idea of to provide a bind package with native PKCS#11 will never work. BTW only SoftHSMv2 with OpenSSL backend (and not in FIPS mode) can run all the system tests...