Hello, I am maintainer of unbound in RHEL. We are preparing RHEL9 (and CentOS Stream 9). Because preparations for various security certifications SHA-1 signature validation is disabled now in upcoming RHEL9. It is done via something we call crypto-policies, which sets openssl configuration among others.
In DEFAULT policy (set by update-crypto-policies --set DEFAULT) it would fail to resolve any name signed by DNSSEC key using SHA-1 or SHA-1 digest. Most DNSSEC validators I have seen assume they know all algorithms right from the start. Unfortunately openssl does not seem to provide good API to test if SHA-1 based signature would be accepted. It can be tried in podman/docker the most easy way: docker pull quay.io/centos/centos:stream9 run -ti centos:stream9 dnf install unbound unbound-host -t dnskey -rD int. Here it what it would emit: # unbound-host -t dnskey -rD int int has DNSKEY record 256 3 7 AwEAAakqkuFzCwB8Zo3lCQGR+7FiPDiaDCpyFdFq2gFeNUF3yFqWwAoCV+A/U5wza2rS0bQaADpnFUO4f8oIdOJbMGLWObs6MUN1NkcQUeSXEsNsjxGZDBwNhqurBeSmrGkDyGvVrxGLmeb+AmuhTsNXbCzA5nvZinZOlAwK6Ft4OJvJ int has DNSKEY record 256 3 7 AwEAAbvlwoq07LItqAczwktNYABK/KBD9W1fnZYgezM6OXNRju0zHWph1NJQsBlNsVZJWPfvQJQLjxPjMldYQS4tLPmHM8pLPEaa5K8sSzTRJ0Jlx4LasYaIANp2v9L8v18mTBUDC1VTA2U5rh79zPO3yGaHhxdCiNRsq+MPY1QtOiK9 int has DNSKEY record 257 3 7 AwEAAb8omPP2ctJgDcENW8k7C5HhrCv79Q3sASrugKzHwUxWpfyifwHFRWrRcXVcwG6AnJBQ1U6ZplnhjqdnXSphgH0/Y+CJfqsw2FpHA+sPbOzUO8DCKT3Ez2hEEoUXMr19zqR6a6I/lSt0pO/mg8NSQHVwbWuH35haZ4OEOXGW2T83TGvq19XhLZWu/z4GSEeIKN4XagyVol7HLfjOJpRg1EdPMYWDsWZTWmKd35fZFkLgn6YmzzBgDlLI6x2UfLKgnysIBeoh2h952WyL/EOiO3Lbl0bnVvrQl+VelkfTS1tpgYocWT2FvnU+50PWZnuLjLvnjqDBrbbknTBG7fReYa8= int has DNSKEY record 256 3 7 AwEAAYwx2ixZwqVrqiIHYEIFcqId+jVQGo/9x4uNWfDVuGyTMq8kmdatfv3y1FZ6N6IH5R3BlzEl96GLChsXmKhdFGLxutfFR8vZyT7lJciux4ik/ckb8nTMuXLizx/V2gRmsJ+Qqnn5WyQD1ZwulISMhnvLKVMX5mwPusZrq2l49UG1 validation failure <int. DNSKEY IN>: keyset not secured by DNSKEY that matches DS from 10.0.2.3 for key int. while building chain of trust #unbound-host -t dnskey -rddddD int ... [1649264462] libunbound[6614:0] info: validator: inform_super, sub is int. DNSKEY IN [1649264462] libunbound[6614:0] info: super is int. DNSKEY IN [1649264462] libunbound[6614:0] debug: attempt DS match algo 7 keytag 27433 [1649264462] libunbound[6614:0] debug: DS match digest ok, trying signature [1649264462] libunbound[6614:0] debug: verify: EVP_DigestVerifyInit failed [1649264462] libunbound[6614:0] debug: rrset failed to verify: all signatures are bogus [1649264462] libunbound[6614:0] debug: Failed to match any usable DS to a DNSKEY. [1649264462] libunbound[6614:0] info: Did not match a DS to a DNSKEY, thus bogus. [1649264462] libunbound[6614:0] debug: validator[module 1] operate: extstate:module_wait_subquery event:module_event_pass ... It fails in function EVP_DigestVerifyInit on algorithm 7. Would it be possible to modify it, so it would revert on few specific openssl error codes back to insecure validation? It is able to switch to mode enabling also sha-1 digests: update-crypto-policies --set DEFAULT:SHA1 I would like to find a good way to support both mode when validation fails and when it can pass. In single compiled binary. Is there a better way, than building in an example key and checking once after startup each algorithm in question? I think it is now decided only in dns_resolver_algorithm_supported() function and similar. Would be adjusting unbound code to react to crypto libraries errors too hard? Could such functions return just sec_status_indeterminate in similar cases? I have added a log_crypto_error after it, and this was the result: error: verifyInit: crypto error:03000098:digital envelope routines::invalid digest Would it make sense to return something like sec_status_insecure in such failing cases? Could similar cases be hit for example on ED448 or other rare key algorithms? Filled also issue on github: https://github.com/NLnetLabs/unbound/issues/656 Regards, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: [email protected] PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
