Re: DNSSec mess with SHA1
I would like to add decision to not allow SHA1 signatures verification were done on openssl component in RHEL9. It was not proposed by bind maintainer and because the crypto library prevents that operation, there is a little bind package made by any vendor can do. Unless they want to support their own SHA1 implementation. Of course you can configure DEFAULT:SHA1 crypto policy manually, which I believe is the safest option. Sadly, that will also enable SHA1 acceptance in TLS connections, which were primary target anyway. Unfortunately I do not know a way to enable SHA1 for named.service, but disallow it in other programs. On 12/15/23 13:38, Scott Morizot wrote: The question I have is why you're posting the issue to this list and what you expect the ISC to do? It could be submitted as a bug to the distribution you're using. Or if you want to change the way algorithms are treated, the dnsops list at the IETF would be an appropriate place to start. (There has been a fair amount of discussion there on algorithms, but I admit I haven't been following it closely and it has mostly been focused on the signing side.) As far as I know, RFC 8624 from 2019 remains the last published standards track instruction to validators. Here's the table from it. The following table lists the implementation recommendations for DNSKEY algorithms [DNSKEY-IANA]. +++-+---+ | Number | Mnemonics | DNSSEC Signing | DNSSEC Validation | +++-+---+ | 1 | RSAMD5 | MUST NOT | MUST NOT | | 3 | DSA | MUST NOT | MUST NOT | | 5 | RSASHA1 | NOT RECOMMENDED | MUST | | 6 | DSA-NSEC3-SHA1 | MUST NOT | MUST NOT | | 7 | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | MUST | | 8 | RSASHA256 | MUST | MUST | | 10 | RSASHA512 | NOT RECOMMENDED | MUST | | 12 | ECC-GOST | MUST NOT | MAY | | 13 | ECDSAP256SHA256 | MUST | MUST | | 14 | ECDSAP384SHA384 | MAY | RECOMMENDED | | 15 | ED25519 | RECOMMENDED | RECOMMENDED | | 16 | ED448 | MAY | RECOMMENDED | +++-+---+ Algorithms 5 and 7 are not recommended for signing but remain valid options until they are moved to MUST NOT. And as long as they are valid options, DNSSEC validation has to remain MUST. ISC BIND functions in part as the reference implementation for the DNS standards as published through the IETF. If your distribution removed the libraries for an algorithm (and openssl is a separate project) on which BIND depends for validating those algorithms and it's the only algorithm available I'm not sure what other result BIND can legitimately return. Yes, there's a statement in the validation portion of RFC 4035 that if the resolver doesn't support any of the algorithms in the delegation, it should treat the zone as unsigned. But that doesn't apply here from what I can tell. The DNSSEC algorithm itself (algorithm 7 in this instance) is supported in the resolver and must be supported for validation to be standards conformant. Support for the hash algorithm used by the supported algorithm has been removed from the operating system. There is a little we can do. Used crypto backend does not allow SHA1 validation and there is no configuration named can use to request it. Choices any DNSSEC validation service has is: 1) Ignore the problem. Causes SERVFAILs on any SHA1 signed zones unfortunately on RHEL9 and derivatives in default configuration. 2) Do not use system provided crypto libraries. I think named maintainers lack expertise and manpower to properly maintain own set of crypto libraries. I would not recommend that either. 3) Disable SHA1 algorithm to make it equivalent to unsigned. Yes, it violates RFC 8624 this way. But does not cause SERVFAILs, still protects all other zones signed with stronger algorithms. Just small subset becomes unprotected. Either by runtime autodetection or manual configuration. 4) Completely disable DNSSEC validation. I would not recommend this option, this is the worst choice. I have chosen the choice 3) for RHEL bind package and ISC has taken it as well. I don't think there were any better choice anyway. I think the future solution might be having separate openssl SHA1 provider, which would be explicitly requested by API in named, but not used for common applications doing TLS connections. I don't see anywhere that BIND is returning the wrong result. In that situation, it looks like the only option. The ISC has no control over those building distributions nor do
Re: DNSSec mess with SHA1
Hello Wolfgang,
I would suggest using policy DEFAULT:SHA1 instead. It does not enable
all outdated algorithms, but enables only SHA1 in addition. Good choice
for dedicated DNS servers.
$ update-crypto-policies --set DEFAULT:SHA1
With my bind maintainer hat on, I need to clarify that it was ensured
SHA1 disabling does not cause fatal errors with default Red Hat provided
configuration. The magic happens in include provided by the system:
include "/etc/crypto-policies/back-ends/bind.config";
That ensures SHA1 algorithm is disabled, making SHA1 signed content just
unsigned, but otherwise resolvable. When you change policy to
DEFAULT:SHA1, it should make SHA1 enabled again automatically. Making it
secure again.
If you have custom named configuration, I would recommend to include
crypto-policies snippet in your options {} block. Unless you are
prepared to handle it manually of course.
The above should work for our RHEL9 supported versions (and derived
rebuilds) and also for ISC provided builds or your own builds. Newer
stable BIND releases have built-in autodetection of SHA1 support, which
makes it not necessary. But it is not error to include that anyway.
Best Regards,
Petr
On 12/15/23 13:21, Wolfgang Riedel via bind-users wrote:
Hello,
To answer my own question, the following will work:
shadowman-200.png
Chapter 4. Using system-wide cryptographic policies Red Hat Enterprise
Linux 8 | Red Hat Customer Portal
access.redhat.com
With:dnssec-validation auto;
_Not working:_
sudo update-crypto-policies —show
DEFAULT
_working:_
update-crypto-policies --set LEGACY
sudo update-crypto-policies --show
LEGACY
—
Cheers,
Wolfgang
__
Wolfgang Riedel | DistinguishedEngineer | CCIE #13804 | VCP #42559
On 15. Dec 2023, at 12:46, Wolfgang Riedel via bind-users
wrote:
Hello Petr,
The issue is not just BIND local, as you can see on dnsviz.net
Re: migration from auto-dnssec to dnssec-policy deletes keys immediately
On 12/28/23 12:58, Adrian Zaugg wrote: Hi Nick Not changing the key algo does help indeed when introducing dnssec-policy, see the log below. Thank you very much for pointing this out. But I do not understand why BIND deletes valid and published keys, just because there should be another algo used. Couldn't this be done in a smooth key rollover process aswell? Maybe someone with more insights than I have, could explain this behaviour. Thanks! I suspect because it did not have the right key states set. In order to do this all automatically we need to maintain state. Prior to dnssec-policy there is no such state. When migrating to dnssec-policy we try to derive the key states from the key timing metadata in the key files. You should check if the migration is complete and all key states are in omnipresent. You can do so with 'rndc dnssec -status '. From that point on it should be safe to make policy configuration changes, such as algorithm rolls, and old keys are phased out smoothly. I am thinking of adding an additional safety mechanism during migration, because you are not the first one to do this. Best regards, Matthijs Best regards, Adrian. Log of successful change from auto-dnssec to dnssec-policy (using the same algo): 2023-12-28 11:53:00: zone myzone.ch/IN (signed): generated salt: [...] 2023-12-28 11:53:00: zone myzone.ch/IN (signed): checkds: set 4 parentals 2023-12-28 11:53:01: zone myzone.ch/IN (signed): zone_addnsec3chain(1,CREATE, 32,[...]) 2023-12-28 11:53:01: zone myzone.ch/IN (signed): reconfiguring zone keys 2023-12-28 11:53:01: keymgr: DNSKEY myzone.ch/ECDSAP256SHA256/50817 (ZSK) created for policy mypolicy_ecdsa 2023-12-28 11:53:01: Permissions on the file /var/lib/bind/keys/Kmyzone.ch. +013+61287.private have changed from 0640 to 0600 as a result of this operation. 2023-12-28 11:53:01: Permissions on the file /var/lib/bind/keys/Kmyzone.ch. +013+38348.private have changed from 0640 to 0600 as a result of this operation. 2023-12-28 11:53:01: Fetching myzone.ch/ECDSAP256SHA256/50817 (ZSK) from key repository. 2023-12-28 11:53:01: Key myzone.ch/ECDSAP256SHA256/50817: Delaying activation to match the DNSKEY TTL (86400). 2023-12-28 11:53:01: DNSKEY myzone.ch/ECDSAP256SHA256/50817 (ZSK) is now published 2023-12-28 11:53:01: DNSKEY myzone.ch/ECDSAP256SHA256/50817 (ZSK) is now active 2023-12-28 11:53:01: CDS for key myzone.ch/ECDSAP256SHA256/61287 is now published 2023-12-28 11:53:01: CDNSKEY for key myzone.ch/ECDSAP256SHA256/61287 is now published 2023-12-28 11:53:01: zone myzone.ch/IN (signed): next key event: 28-Dec-2023 12:53:01.176 2023-12-28 11:53:01: zone myzone.ch/IN (signed): sending notifies (serial 2021010692) -- 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
