Bug #38315 for bind9-public: provide richer options for crypto configuration in BIND

Hello, I would like to ask you for help with crypto consolidation project: Red Hat is trying to consolidate crypto configuration on Linux systems to one place. As you can see in https://bugzilla.redhat.com/show_bug.cgi?id=1179925, we have tried to write a script which translates system-wide crypto policy into a named.conf snippet (with the aim to forbid old/deprecated/insecure algorithms and so on). Unfortunately, it seems that BIND currently has very limited set of crypto settings. It would be really helpful if BIND could accept parameters like min-rsa-bits and min-dh-bits (or at least specify the allowed DH groups). Also, there is no way to specify algorithms and minimal accepted parameters/key sizes for HMAC algorithms. Maybe an option to specify algorithm white-lists instead of black-lists would be nice way how to avoid surprises after upgrade. What do you think about it? Would it be possible to implement something like that? Have a nice day! -- Petr Spacek @ Red Hat

---

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

---