X-RT-Original-Encoding: utf-8 MIME-Version: 1.0 X-Original-To: bind9-public@bugs.isc.org In-Reply-To: To: bind9-public@isc.org, fdupont@isc.org Content-Transfer-Encoding: 8bit Message-ID: <4466933a-10f1-8af0-f4f9-8b1b2c12cd5a@redhat.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Date: Fri, 9 Mar 2018 14:47:33 +0100 Subject: Re: [ISC-Bugs #46764] check MD5 and SHA1 support at startup X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Fri, 09 Mar 2018 13:47:40 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Fri, 09 Mar 2018 13:47:40 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'pemensik@redhat.com' RCPT:'' X-Scanned-BY: MIMEDefang 2.78 on 10.11.54.6 X-Spam-Status: No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD autolearn=disabled version=3.4.1 From pemensik@redhat.com Fri Mar 9 13:47:53 2018 From: "Petr Menšík" Content-Language: en-US References: <54fce405-5c8b-8c7e-9c20-f1c13d726283@redhat.com> content-type: text/plain; charset="utf-8" X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mx.pao1.isc.org Return-Path: X-RT-Interface: Email Delivered-To: bind9-public@bugs.isc.org Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.pao1.isc.org", Issuer "COMODO RSA Organization Validation Secure Server CA" (not verified)) by bugs.isc.org (Postfix) with ESMTPS id AFEEED78B1C for ; Fri, 9 Mar 2018 13:47:53 +0000 (UTC) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id D9A483AB045; Fri, 9 Mar 2018 13:47:50 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 70EB88D6FB; Fri, 9 Mar 2018 13:47:40 +0000 (UTC) Received: from menpad.brq.redhat.com (unknown [10.40.205.63]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5F3B1215CDAA; Fri, 9 Mar 2018 13:47:35 +0000 (UTC) X-RT-Incoming-Encryption: Not encrypted RT-Message-ID: Content-Length: 5608 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