Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 In-Reply-To: References: <54fce405-5c8b-8c7e-9c20-f1c13d726283@redhat.com> Message-ID: MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: binary X-RT-Interface: Web X-Mailer: MIME-tools 5.508 (Entity 5.508) RT-Send-CC: Content-Length: 3799 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. > > - --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... > > 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). > > 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.