Hi Francis, finally I finished somehow working version. I moved it to ISC gitlab branch : I made changes to tests to make it pass with MD5 algorithm disabled and enabled from the same source. This is not final version, because I found some problems. First is stronger requirement on minimal DSA keys that I had to change. Second is change from all default hmac-md5 keys make problem, I had to specify algorithm in -y parameters of dig and nsupdate. Also in nsupdate key statement. I will create issues for them on gitlab. Could you please look at it if such approach is possible? On 01/27/2018 12:34 AM, Francis Dupont via RT wrote: > On Thu Jan 25 21:30:17 2018, pemensik@redhat.com wrote: >> Unfinished and untested preview at >> https://github.com/pemensik/bind9/tree/feature/runtime-md5-disable > > => still did not get the time to look at this... > >> On 01/20/2018 05:45 PM, Francis Dupont via RT wrote: >>> I summary here recommendations for building bind9: >>> >>> configure flags: >>> >>> - --with-ecdsa: it should be autodetected so just check >>> it is on in the report and/or config.status >> No support for this in 9.11.2, I think we want it. > > => ECDSA is supported in 9.10 and newer so I don't understand > your comment. I am sorry I was just tired and swapped ECDSA and EdDSA support in versions. Please ignore that. > >>> - --with-eddsa: support is only in OpenSSL 1.1 so it is >>> unlikely you get it. >> This is actually true, Fedora 26 already supports OpenSSL 1.1. This >> would be enabled if available. It is supported only in 9.12 however, >> Fedora still has 9.11.2 version where this option is available. This is >> not relevant to RHEL 7, but I think we want it in Fedora. I will check >> backport possibility. > > => I believed there was no FIPS certified code based on OpenSSL 1.1... > Anyway EdDSA is not FIPS approved so even it is better than ECDSA > it is hard to recommend it in production today... According to FIPS presentation on Devconf [2] EdDSA might be allowed in future. Of course for now it is not FIPS ceritified. Its support is not yet in any supported RHEL version AFAIK. I think there might be something soon. We can enable it as experimental feature on Fedora and disable it on RHEL build, until it is certified. I have to backport runtime MD5 disable to version 9.9 used in RHEL 7, because already released version has issue with it. That version is still linked against OpenSSL 1.0. > >>> lib/isc/include/pk11/site.h >>> >>> - PK11_DH_DISABLE could be the same story (in worse >>> because there are some predefined groups). It is used >>> only for TKEY and required MD5. So at the end it will >>> be disable statically or dynamically in FIPS mode... >> I am aware this is directly linked to md5. I think is there any reason >> it does not support any other digest algorithm? Is it only lack of >> demand for it? > > => mostly lack of demand. I tried to update it to ECDH at IETF > but failed for various reasons. > >>> - PK11_PAD_HMAC_KEYS must be off as it fools the >>> check on short keys for HMAC. >> Last time I checked this in softhsm with openssl 1.1, padding with zeros >> did not change results of tests. Is there anything I am missing there. > > => the purpose of this flag is to fool HMAC implementations > which put a lower threshold on key lengths so some tests > (including the second part of the new sanity check) pass. > it should not be set for a code used in production. > And of course padding a short key with zeros does not change > the result but my point is it does not increase the entropy too. > Note that as far as I know HMAC in FIPS mode should reject > short keys. If you have this problem again the solution is not > to leave HMAC lower functions to fail, nor of course to by pass > the check but to refuse too short keys at configuration / > command line decoding time. > A last point: TSIG rfc2845bis has now a SHOULD about > minimal key length (added by me with the support of > co-authors/contributors). This is one of issues I have met. I think it should be more simple to change limits of useable keys. Especially in tests, where it uses short keys only to save CPU on testing (I think). > >>> code using crypto: >>> >>> - OpenSSL code should not use engines (this is a requirement >>> proper to the Security Policy for Red Hat OpenSSL, i.e. the >>> OpenSSL FIPS module allows engines to offload crypto >>> to a HSM). There is a USE_ENGINE ifdef which disables >>> engine code, you should try it so ENGINE_set_default() is >>> never called. >> Interesting. I were planning to use pkcs11 engine in future instead of >> native pkcs11 code. I think I will have to talk more with our crypto >> people to have clear requirements. > > => in the past we had a PKCS#11 OpenSSL engine and it was > a nightmare to support. This was the reason I wrote the native > PKCS#11 support and it was so successful it was decided > to promote and integrate it into bind9. > > Note that to come back to the Security Policy it explicitly prohibits > calls to the ENGINE_set_default() function so IMHO the use of > a HSM (make sense because if you have a HSM you don't need > OpenSSL and the "one crypto only" rule applies). > > Again if you have questions about the PKCS#11 native support > I am ready to answer. > [1] https://gitlab.isc.org/pemensik/bind9/tree/feature/master/runtime-md5-disable [2] https://devconfcz2018.sched.com/event/DJYH/fips-140-2-compliance-for-developers -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@redhat.com PGP: 65C6C973