<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello <span style="white-space: pre-wrap">Bjørn.</span></p>
<p>No. Algorithm 5 and 7 are skipped earlier and should never reach
the code affected.</p>
<p>If the zone is signed only by SHA1 based algorithm, then it will
be considered insecure after receving DS record for it. It should
not even request DNSKEY for such zone and should not call any
cryptographic functions. Keys should be skipped even if zone would
be signed by multiple algorithms. Although I think it brings no
benefit to dual sign with the weakest possible algorithm and I
hope nobody does it.</p>
<p>I think this should affect only special cases considered
supported algorithm (ie. not 5 or 7 on RHEL9+) and having special
crafted DNSKEYs. Common signed zone would not trigger any of this,
it would have to be something crafted to trigger unfixed code.</p>
<p>No crypto policy will change any of this, you do not have to
lower your security defaults to avoid that.</p>
<p>Please wait few days, proper fixed are on the way!</p>
<div class="moz-cite-prefix">On 31/10/2025 12:37, Bjørn Mork wrote:<br>
</div>
<blockquote type="cite" cite="mid:87ikfvuwsg.fsf@miraculix.mork.no">
<pre wrap="" class="moz-quote-pre">Time to re-evaluate the default SHA1 policies on RHEL...
Quoting from <a class="moz-txt-link-freetext" href="https://bind9.readthedocs.io/en/v9.20.15/notes.html#security-fixes">https://bind9.readthedocs.io/en/v9.20.15/notes.html#security-fixes</a>
DNSSEC validation fails if matching but invalid DNSKEY is found. (CVE-2025-8677)
Previously, if a matching but cryptographically invalid key was
encountered during DNSSEC validation, the key was skipped and not
counted towards validation failures. named now treats such DNSSEC keys
as hard failures and the DNSSEC validation fails immediately, instead of
continuing with the next DNSKEYs in the RRset.
IIUC, this means that any zone with a RSASHA1 key will now fail
validation on Redhat systems using default policies, even if other keys
are present.
Is that correct? Is it intentional?</pre>
</blockquote>
No, the description is intentionally a little vague to not help
attackers misusing known problem. But attack vector is not this
simple AFAIK.
<blockquote type="cite" cite="mid:87ikfvuwsg.fsf@miraculix.mork.no">
<pre wrap="" class="moz-quote-pre">
If correct, then I believe it will break a number of zones with leftover
RSASHA1 keys and signatures. Anyone still having such keys in their
zones should purge them ASAP. And resolver operators running BIND on
RHEL9 should consider running
update-crypto-policies --set DEFAULT:SHA1
to prevent unexpected failures.
Bjørn
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Petr Menšík
Senior Software Engineer, RHEL
Red Hat, <a class="moz-txt-link-freetext" href="https://www.redhat.com/">https://www.redhat.com/</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
</body>
</html>