BIND 9.18.6 disables RSASHA1 at runtime?

Anand Buddhdev anandb at ripe.net
Fri Sep 2 13:49:42 UTC 2022


On 02/09/2022 13:53, Mark Andrews wrote:

Hi Mark,

> We don’t log rsamd5 is disabled now ec or ed curves when they are
> not  supported by the crypto provider. Why should rsasha1 based algs be 
special?

The problem I see with 9.18.6 is that at startup, it is checking to see 
if it can validate RSASHA1 signatures, and if it can't, it is disabling 
the algorithm *silently*. I understand the reasoning, but I disagree 
with it being disabled silently. If BIND is disabling something as 
important as this at runtime, at the very least, a log entry about it 
would go a long way towards helping system administrators. Here's my 
reasoning:

There is a difference between RSAMD5 and RSASHA1. RFC 8624 clearly 
forbids RSAMD5 for all uses, with "MUST NOT". It's fine for BIND to skip 
validation for any zone signed with this algorithm.

RSASHA1 is quite different. The RFC recommends not signing with it, but 
validation is still a must. Similarly, it forbids publishing SHA1 
digests in DS records, but requires validation using them.

Now, on RedHat Linux 9 and its clones, SHA1 is disabled by *policy*. The 
named.conf from the BIND package in this distro (version 9.16.23) 
includes the file:

/etc/crypto-policies/back-ends/bind.config

and this file contains:

disable-algorithms "." {
RSAMD5;
RSASHA1;
NSEC3RSASHA1;
DSA;
};
disable-ds-digests "." {
SHA-1;
GOST;
};

This is explicit declaration that SHA1 has been disabled.

But if one builds BIND >= 9.18.6 from pristine sources, the 
configuration file is not going to include this snippet, and BIND is 
going to silently disable SHA1. I strongly feel that BIND should log this.

Regards,
Anand


More information about the bind-users mailing list