<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello,</p>
<p>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.</p>
<p>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.</p>
<p>It can be tried in podman/docker the most easy way:</p>
<p><span>
<pre id="command-data" class="command">docker pull quay.io/centos/centos:stream9
run -ti centos:stream9
dnf install unbound
unbound-host -t dnskey -rD int.
</pre>
<pre id="command-data" class="command">Here it what it would emit:
</pre>
</span></p>
<pre><span># unbound-host -t dnskey -rD int</span></pre>
<pre><span>int has DNSKEY record 256 3 7 AwEAAakqkuFzCwB8Zo3lCQGR+7FiPDiaDCpyFdFq2gFeNUF3yFqWwAoCV+A/U5wza2rS0bQaADpnFUO4f8oIdOJbMGLWObs6MUN1NkcQUeSXEsNsjxGZDBwNhqurBeSmrGkDyGvVrxGLmeb+AmuhTsNXbCzA5nvZinZOlAwK6Ft4OJvJ</span></pre>
<pre><span>int has DNSKEY record 256 3 7 AwEAAbvlwoq07LItqAczwktNYABK/KBD9W1fnZYgezM6OXNRju0zHWph1NJQsBlNsVZJWPfvQJQLjxPjMldYQS4tLPmHM8pLPEaa5K8sSzTRJ0Jlx4LasYaIANp2v9L8v18mTBUDC1VTA2U5rh79zPO3yGaHhxdCiNRsq+MPY1QtOiK9</span></pre>
<pre><span>int has DNSKEY record 257 3 7 AwEAAb8omPP2ctJgDcENW8k7C5HhrCv79Q3sASrugKzHwUxWpfyifwHFRWrRcXVcwG6AnJBQ1U6ZplnhjqdnXSphgH0/Y+CJfqsw2FpHA+sPbOzUO8DCKT3Ez2hEEoUXMr19zqR6a6I/lSt0pO/mg8NSQHVwbWuH35haZ4OEOXGW2T83TGvq19XhLZWu/z4GSEeIKN4XagyVol7HLfjOJpRg1EdPMYWDsWZTWmKd35fZFkLgn6YmzzBgDlLI6x2UfLKgnysIBeoh2h952WyL/EOiO3Lbl0bnVvrQl+VelkfTS1tpgYocWT2FvnU+50PWZnuLjLvnjqDBrbbknTBG7fReYa8=</span></pre>
<pre><span>int has DNSKEY record 256 3 7 AwEAAYwx2ixZwqVrqiIHYEIFcqId+jVQGo/9x4uNWfDVuGyTMq8kmdatfv3y1FZ6N6IH5R3BlzEl96GLChsXmKhdFGLxutfFR8vZyT7lJciux4ik/ckb8nTMuXLizx/V2gRmsJ+Qqnn5WyQD1ZwulISMhnvLKVMX5mwPusZrq2l49UG1</span></pre>
<pre><span>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
...
</span></pre>
<pre><span></span></pre>
<p><span><br>
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</span></p>
<p><span>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?</span></p>
<p><span>I have added a log_crypto_error after it, and this was the
result:</span></p>
<p><span>error: verifyInit: crypto error:03000098:digital envelope
routines::invalid digest<br>
</span></p>
<p><span>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?</span></p>
<p><span>Filled also issue on github:
<a class="moz-txt-link-freetext" href="https://github.com/NLnetLabs/unbound/issues/656">https://github.com/NLnetLabs/unbound/issues/656</a><br>
</span></p>
<p><span>Regards,<br>
Petr<br>
</span></p>
<pre class="moz-signature" cols="72">--
Petr Menšík
Software Engineer
Red Hat, <a class="moz-txt-link-freetext" href="http://www.redhat.com/">http://www.redhat.com/</a>
email: <a class="moz-txt-link-abbreviated" href="mailto:pemensik@redhat.com">pemensik@redhat.com</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
</body>
</html>