Re: BIND 9.18.6 disables RSASHA1 at runtime?
I would propose one line per protocol for disabled methods. This would
allow for easier log parsing
On 2022-09-13 06:28, Petr Špaček wrote:
On 02. 09. 22 15:49, Anand Buddhdev wrote: 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.
Can you propose log line?
Should it be one line per algorithm? Or one line with all disabled? Or
one one with all enabled? What log level? Log category? It it okay it
will be almost always logging GOST? ...
So many questions to get log line covering < 2 % of all signed domains,
which will be obsolete over time anyway (hopefully).
--
Petr Špaček--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.18.6 disables RSASHA1 at runtime?
On 02. 09. 22 15:49, Anand Buddhdev wrote:
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.
Can you propose log line?
Should it be one line per algorithm? Or one line with all disabled? Or
one one with all enabled? What log level? Log category? It it okay it
will be almost always logging GOST? ...
So many questions to get log line covering < 2 % of all signed domains,
which will be obsolete over time anyway (hopefully).
--
Petr Špaček
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.18.6 disables RSASHA1 at runtime?
Mark Andrews writes: > What records in paypal.com do you or your customers actually depend upon > being signed? Paypal’s web servers depend on CAs not the DNS to provide > trust anchors. It's not their SMTP servers as paypalcorp.com is not signed. OK, let's just hope no CA runs Redhat then. Bjørn -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.18.6 disables RSASHA1 at runtime?
> On 5 Sep 2022, at 18:41, Bjørn Mork wrote: > > Petr Menšík writes: > >> It is suitable for all other algorithms so I disagree that >> without algorithms 5 and 7 it is not usable at all. Majority of >> secured domains use stronger algorithms already. > > Would it be the same if it worked for a majority of TLDs? Say "nz" as > an arbitrary example. Would still work fine for a majority of users. It > would probably take me some time before I noticed. After all, I rarely > have a need to look up "nz" domains. And when it occasionally failed I'd > probably never would have blamed Redhat. > > IMHO BIND without RSASHA1 is useless as a validating resolver as long as > there are RSASHA1 signed zones out there. At least as long as this is > still allowed. And it is. Hence the MUST validate. It does validate. Remember the results of validation are secure, insecure, or bogus. The point of the change is ensure that lookups DO NOT FAIL because the OS has removed / disabled support for RSASHA1. Without the change lookups failed with SERVFAIL unless you explicitly said to disable RSASHA1 and NSEC3RSASHA1. With the change they validate as insecure. > The classical example of a failing domain is > https://dnsviz.net/d/paypal.com/dnssec/ > Maybe acceptable for you? Definitely not for me or my customers. I > want DNSSEC validation on that domain. I'd certainly prefer a stronger > algorithm. But that's not an option, is it? What records in paypal.com do you or your customers actually depend upon being signed? Paypal’s web servers depend on CAs not the DNS to provide trust anchors. It's not their SMTP servers as paypalcorp.com is not signed. Yes, I’d like Paypal to have moved to something that is not RSASHA1 based for DNSSEC but at the moment, for all practical uses, whether the zone validates as secure or insecure doesn’t matter. > So, yes, I prefer to be forced to acknowledge this issue. And refusing > to start without some form of explicit adminstrator action is the only > way that works in my experience. Not enough admins read logs ;-) > > > > Bjørn > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.18.6 disables RSASHA1 at runtime?
Petr, care to prepare a MR for this? After all, it's RedHat who is making us all to go through this mess. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 5. 9. 2022, at 9:56, Petr Menšík wrote: > > I think it might report at least single line with a list of successfuly > initialized algorithms. So it would not report RSASHA1 is not available, but > a list of algorithms which are available in this build AND runtime > environment. I think such list would be short enough. signature.asc Description: Message signed with OpenPGP -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.18.6 disables RSASHA1 at runtime?
Petr Menšík writes: > It is suitable for all other algorithms so I disagree that > without algorithms 5 and 7 it is not usable at all. Majority of > secured domains use stronger algorithms already. Would it be the same if it worked for a majority of TLDs? Say "nz" as an arbitrary example. Would still work fine for a majority of users. It would probably take me some time before I noticed. After all, I rarely have a need to look up "nz" domains. And when it occasionally failed I'd probably never would have blamed Redhat. IMHO BIND without RSASHA1 is useless as a validating resolver as long as there are RSASHA1 signed zones out there. At least as long as this is still allowed. And it is. Hence the MUST validate. The classical example of a failing domain is https://dnsviz.net/d/paypal.com/dnssec/ Maybe acceptable for you? Definitely not for me or my customers. I want DNSSEC validation on that domain. I'd certainly prefer a stronger algorithm. But that's not an option, is it? So, yes, I prefer to be forced to acknowledge this issue. And refusing to start without some form of explicit adminstrator action is the only way that works in my experience. Not enough admins read logs ;-) Bjørn -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.18.6 disables RSASHA1 at runtime?
On 9/2/22 14:23, Bjørn Mork wrote: Mark Andrews writes: 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? Because RSASHA1 validation still is a MUST in RFC8624? MD5 is and ED is not. I don't know if disabled EC curves is a real world problem, but ECDSAP256SHA256 is also a MUST and should get the same treatment. IMHO you should not allow the server to start up with a non-compliant configuration without making sure the adminstrator is aware of the problem. A log warning is sort of a minimum. Personally I'd prefer the server to die by default. It is unsuitable as a validating resolver and forcing adminstrators to find that out the hard way is not very nice. Bjørn I do not think all servers should fail to start on CentOS Stream 9, RHEL9 and derivates. Yes, I have hit too it does not report at all which algorithms are ready to use. But DEFAULT crypto policy on those distributions simply do not allow validation of SHA-1 based signatures to succeed. It is suitable for all other algorithms so I disagree that without algorithms 5 and 7 it is not usable at all. Majority of secured domains use stronger algorithms already. I think it might report at least single line with a list of successfuly initialized algorithms. So it would not report RSASHA1 is not available, but a list of algorithms which are available in this build AND runtime environment. I think such list would be short enough. Administrators should be aware of those issues by reading release notes on affected distributions. They should not be surprised so much. Regards, Petr -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.18.6 disables RSASHA1 at runtime?
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
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.18.6 disables RSASHA1 at runtime?
Mark Andrews writes: > 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? Because RSASHA1 validation still is a MUST in RFC8624? MD5 is and ED is not. I don't know if disabled EC curves is a real world problem, but ECDSAP256SHA256 is also a MUST and should get the same treatment. IMHO you should not allow the server to start up with a non-compliant configuration without making sure the adminstrator is aware of the problem. A log warning is sort of a minimum. Personally I'd prefer the server to die by default. It is unsuitable as a validating resolver and forcing adminstrators to find that out the hard way is not very nice. Bjørn -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.18.6 disables RSASHA1 at runtime?
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? -- Mark Andrews > On 2 Sep 2022, at 20:37, Anand Buddhdev wrote: > > On 01/09/2022 23:19, Mark Andrews wrote: > > Hi Mark, > >> Yes. You will need to restart the server. > > Okay, I'm trying out 9.18.6 on an Oracle Linux 9 server. When starting BIND, > it doesn't log anything about disabling RSASHA1. But when I query it for > ietf.org/SOA, I get an unvalidated response. BIND also logs: > > 02-Sep-2022 10:27:13.839 dnssec: validating ietf.org/SOA: no valid signature > found > > I think it's fine for BIND to disable RSASHA1, but it might be better to log > this when starting, so that it's clear to an operator. > > Regards, > Anand > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.18.6 disables RSASHA1 at runtime?
On 01/09/2022 23:19, Mark Andrews wrote: Hi Mark, Yes. You will need to restart the server. Okay, I'm trying out 9.18.6 on an Oracle Linux 9 server. When starting BIND, it doesn't log anything about disabling RSASHA1. But when I query it for ietf.org/SOA, I get an unvalidated response. BIND also logs: 02-Sep-2022 10:27:13.839 dnssec: validating ietf.org/SOA: no valid signature found I think it's fine for BIND to disable RSASHA1, but it might be better to log this when starting, so that it's clear to an operator. Regards, Anand -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.18.6 disables RSASHA1 at runtime?
Yes. You will need to restart the server. That all said if you are signing zones using RSASHA1 or NSEC3RSASHA1 you should transition to a newer algorithm if you want to have your zone validated by as many as possible. -- Mark Andrews > On 1 Sep 2022, at 22:59, Anand Buddhdev wrote: > > Hi BIND developers, > > The release notes for 9.18.6 say: > > "The DNSSEC algorithms RSASHA1 and NSEC3RSASHA1 are now automatically > disabled on systems where they are disallowed by the security policy (e.g. > Red Hat Enterprise Linux 9)." > > Does this happen at runtime when BIND starts? > > If an administrator updates the security policy on an EL9 system and allows > SHA1, will BIND 9.18.6 then be able to validate zones signed with RSASHA1? > > Regards, > Anand > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
