X-RT-Incoming-Encryption: Not encrypted Subject: Re: [ISC-Bugs #46764] check MD5 and SHA1 support at startup In-Reply-To: X-Scanned-BY: MIMEDefang 2.79 on 10.5.11.15 From pemensik@redhat.com Wed Jan 17 20:37:00 2018 X-Spam-Status: No, score=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD autolearn=disabled version=3.4.1 References: <20180116174037.GA74508@isc.org> content-type: text/plain; charset="utf-8" Date: Wed, 17 Jan 2018 21:36:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 X-RT-Original-Encoding: utf-8 CC: "Tomas Hozza" From: "Petr Menšík" Content-Transfer-Encoding: 8bit To: bind9-public@isc.org, fdupont@isc.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 17 Jan 2018 20:36:56 +0000 (UTC) X-RT-Interface: Email X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mx.pao1.isc.org Delivered-To: bind9-public@bugs.isc.org X-Original-To: bind9-public@bugs.isc.org Return-Path: Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 35382D78B0D for ; Wed, 17 Jan 2018 20:37:00 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 3B2AD3AB001; Wed, 17 Jan 2018 20:36:57 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1B595C0568E1; Wed, 17 Jan 2018 20:36:56 +0000 (UTC) Received: from menpad.brq.redhat.com (unknown [10.43.2.33]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 258C692D1B; Wed, 17 Jan 2018 20:36:48 +0000 (UTC) Message-ID: <4230b306-87ec-ca1b-b1f2-4ae2c59f9ffc@redhat.com> MIME-Version: 1.0 Content-Language: en-US RT-Message-ID: Content-Length: 4523 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. I would start with clarification what is our problem. Red Hat supports running in FIPS mode, where only crypto libraries change based on runtime control. It is not required to install FIPS enabled system from customized image. It is not required to maintain one FIPS version of BIND and one non-FIPS. Support for that is built-in into the software and core libraries. How it is enabled on Red Hat Enterprise Linux is at manual page [1]. Our requirement is that all applications should work with all supported digest algorithms in normal mode. That includes MD5 in BIND. Any HMAC algorithm including HMAC-MD5 has to be supported in this mode. Once FIPS mode is enabled in target system, crypto library disables support for MD5. Any try to use md5 will result in error. That is clear I think. In the current code such use would generate fatal error and program would abort. Of course we want to prevent that. But we do not want to prevent starting BIND in FIPS mode. We want to be able to run named the same way like in normal mode. Only difference we would like archieve behavior similar to defined PK11_MD5_DISABLE in pk11/site.h. That means any request to use MD5 will fail like it was not supported at all. When I say fail, I mean single failed request, without crashing or terminating whole daemon. It would be nice if it prevented start with configuration containing MD5 key when MD5 is not available. But we want to be able process any other requests signed by different enabled algorithms. If only HMAC-SHA256 key is used in configuration, named has to start like usual. 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. I would backport support for more secure algorithms into it. Removing support for the only single algorithm supported before would cause too much confusion. Increase chance of upgrade failures. That is why disabling MD5 in whole build is not option for us. We want to remove its support only in FIPS mode. If that is named or named-pkcs11 variant is not important. We want single build able to support and not support MD5 calls, depending on runtime detection and/or configuration only. The most simple way seems to be changing PK11_MD5_DISABLE define to variable or function, that would be initialized once after start. Instead of conditional compilation, conditional branches would be used. I think it is important to mention, I am not asking you to make it all for me or Red Hat. I am looking for a way to make it maintainable for us. That usually means find a solution that you consider good enough to inclusion into the code base. Now or later. Or at least most of it. 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. I am sorry I was not clear enough from the start. This patch would prevent us starting named in FIPS mode. We want it possible. Our current workaround is to disable control channel using "controls {};" in named.conf. With this patch, it would not even start. We would like failure on the start only when MD5 algorithm was requested in configuration. In all other cases, we want it to start. We would like to use --with-openssl-hash in the future. Our current problem is with --enable-native-pkcs11 variant. But purpose of FIPS mode is to move all hashing functions into certified libraries, out from end applications code. That way we can avoid certification of every single application we provide. We would use --with-openssl-hash to do that. We cannot change it until it can reject MD5 without fatal errors. [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-federal_standards_and_regulations#sec-Enabling-FIPS-Mode On 01/17/2018 08:23 PM, Ondrej Sury via RT wrote: >> Please close the ticket if no further work is required. > > Since this was merged into public codebase, I am moving this to public queue and adding Petr Menšík as a Requestor as he was the initiator of the original bug report. > > Petr could you please look at the proposed solution and comment on that? > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@redhat.com PGP: 65C6C973