Runtime detection of SHA-1 support in unbound

[Petr Menšík]

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: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20220406/b9a96848/attachment.htm>