From pspacek@redhat.com Fri Jan 16 11:09:38 2015 X-Scanned-BY: MIMEDefang 2.68 on 10.5.11.27 CC: "Tomas Hozza" MIME-Version: 1.0 In-Reply-To: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 X-RT-Interface: API References: <54B3CFC4.50108@redhat.com> Message-ID: <54B8F16A.90907@redhat.com> content-type: text/plain; charset="utf-8" Organization: Red Hat X-RT-Original-Encoding: utf-8 Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by bugs.isc.org (Postfix) with ESMTP id 011C471B6E2 for ; Fri, 16 Jan 2015 11:09:38 +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)) (Client CN "mx1.redhat.com", Issuer "DigiCert SHA2 Extended Validation Server CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id F402D1FCB20 for ; Fri, 16 Jan 2015 11:09:34 +0000 (UTC) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0GB9WhD032624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 16 Jan 2015 06:09:32 -0500 Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.128.7]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0GB9UiA030745 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2015 06:09:31 -0500 Delivered-To: bind-suggest@bugs.isc.org Subject: Re: [ISC-Bugs #38315] provide richer options for crypto configuration in BIND User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 Return-Path: X-Original-To: bind-suggest@bugs.isc.org Date: Fri, 16 Jan 2015 12:09:30 +0100 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.ams1.isc.org To: bind-suggest@isc.org Content-Transfer-Encoding: 8bit From: "Petr Spacek" RT-Message-ID: Content-Length: 2341 On 15.1.2015 23:23, Francis Dupont via RT wrote: > On Mon Jan 12 13:44:43 2015, pspacek@redhat.com wrote: >> Unfortunately, it seems that BIND currently has very limited set of >> crypto settings. > > => it is by design because BIND follows first RFCs about DNS > (this is why MD5 is still present and BIND can't at the same time > use a certified crypto and stay DNS compliant...). > >> It would be really helpful if BIND could accept parameters like >> min-rsa-bits > > => I have a specific answer about this. > >> and min-dh-bits (or at least specify the allowed DH groups). > > => DH is used only for a very marginal feature which > was never updated (by more secure groups and/or ECDH). > >> Also, there is no >> way to specify algorithms and minimal accepted parameters/key sizes >> for HMAC algorithms. > > => first we have to follow the RFCs, e.g., for truncated HMAC, > and HMAC parameters are usually configured so under > control. I agree that theoretically user is in charge but our experience is that keys are left in place forever. An minimal-key-length option would allow us to set minimal ("secure") key length in config file snipped distributed with BIND package and raise it over time. It would alert users that they have to regenerate keys if they want to have secure system. > About RSA minimum size: I have a ticket raising it from > 512 to 1024 bits which is stalled because it could make > system tests too slow on some old hardware and > this kind of changes required a major release. > > More, the last time I did some experiments with > a FIPS capable BIND it failed to validate isc.org > because the org key had a modulo size of 1023 > (<1024) bits. So today I am not so sure it is a good > idea to raise the (default) minimum... I should clarify that I'm asking only for configuration options - in fact I don't want BIND to change its default settings. The point is to let distribution to configure this kind of settings as deemed appropriate by distro (possibly using different set of configs when in FIPS mode etc.). This is exactly what Fedora does with TLS configuration: Distro ships default set of trusted CAs, enabled algorithms, algorithm priorities, minimal key lengths and this set can change over time. I hope this clarifies the suggestion. Have a nice day! -- Petr Spacek @ Red Hat