<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>Apart from DNSSEC validation, have you also tested DNS servers
hosting DNSSEC signed zones with NSEC3? This is since NSEC3 only
has <a moz-do-not-send="true"
href="https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml">SHA1
specified</a> and this may cause the DNS server unable to update
the zone to create new NSEC3 records. This will mean that even if
the zone is signed with ECDSA algorithms but use NSEC3 then they
are going to fail.<br>
</p>
<div class="moz-signature">
<p>
Regards,<br>
<b>Shreyas Zare</b><br>
<a href="https://technitium.com/">Technitium</a>
</p>
</div>
<div class="moz-cite-prefix">On 4/13/2022 10:36 PM, Petr Menšík
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:c82f55b3-cc82-57db-ec7d-9865f1673c73@redhat.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<p>Hello DNS users,</p>
<p>I have already created some bugs to inform some affected
software packages. But I would like to notify also here with
prepared plan to obsolete SHA-1 in upcoming RHEL 9.0. Final
documentation is not yet created for it, but it could be tested
already on centos container:</p>
<p><span> </span></p>
<pre id="command-data" class="command">docker pull quay.io/centos/centos:stream9
</pre>
delv command from bind-utils or unbound-host -D from unbound can
test it. delv would still fail, because it does not follow
crypto-policy configuration which named consumes.<br>
<p><span>I have filled tracker bug for EPEL9 components I know on
bug #</span><span>2073066 [1]. If your software validates
DNSSEC signatures, it might start failing on domain names
signed with RSASHA1 or NSEC3RSASHA1 algorithms. If you have
package validating DNSSEC on EPEL9 which I have not mentioned
and it is affected, please create a bug blocking this tracker
bug. If have created the bug but is not affected, please
close it with NOTABUG.<br>
</span></p>
<p><span>Crypto-policy DEFAULT makes some openssl or gnutls
methods to fail, when RSASHA-1 key is used. That includes
openssl function EVP_VerifyFinal (used in bind) and
EVP_DigestVerifyInit (used in unbound). Because used crypto
policy DEFAULT prevents such signature verification, DNSSEC
validators may start to return failures on those names.</span></p>
<p><span>A simple workaround would be switching to crypto policy
DEFAULT:SHA1:</span></p>
<p><span>update-crypto-policies --set DEFAULT:SHA1</span></p>
<p><span>I have created list to TLD affected and attached them to
the bug [2]. But it includes many more names, such as
icann.org, ietf.org or paypal.com.</span></p>
<p><span>I know it violates still active RFC 8624 [3], but because
it is enforced by lower-level API, it is possible just to
follow or fail. I think so far every crypto call failure
results in bogus result and returns status SERVFAIL on the
reply. Would it make sense to create some common cases, where
the result would be fallback to insecure reply without AD bit,
but no failure?<br>
</span></p>
<p><span>Supported bind and unbound packages will start
considering those names as insecure to prevent validation
failures. There has been interesting conversation on
mattermost Town Square [4] on this topic. Worth noting might
be also threads on unbound [5] and Fedora discussion about
implementing the same way [6].<br>
</span></p>
<p><span>Best Regards,</span></p>
<p><span>Petr<br>
</span></p>
<p><span>1. <a class="moz-txt-link-freetext"
href="https://bugzilla.redhat.com/show_bug.cgi?id=2073066"
moz-do-not-send="true">https://bugzilla.redhat.com/show_bug.cgi?id=2073066</a><br>
2. <a class="moz-txt-link-freetext"
href="https://bugzilla.redhat.com/show_bug.cgi?id=2073066#c7"
moz-do-not-send="true">https://bugzilla.redhat.com/show_bug.cgi?id=2073066#c7</a><br>
3. <a class="moz-txt-link-freetext"
href="https://datatracker.ietf.org/doc/html/rfc8624#section-3.1"
moz-do-not-send="true">https://datatracker.ietf.org/doc/html/rfc8624#section-3.1</a><br>
4. <a class="moz-txt-link-freetext"
href="https://chat.dns-oarc.net/community/channels/town-square"
moz-do-not-send="true">https://chat.dns-oarc.net/community/channels/town-square</a><br>
5.
<a class="moz-txt-link-freetext"
href="https://lists.nlnetlabs.nl/pipermail/unbound-users/2022-April/007709.html"
moz-do-not-send="true">https://lists.nlnetlabs.nl/pipermail/unbound-users/2022-April/007709.html</a><br>
6.
<a class="moz-txt-link-freetext"
href="https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VVLHQAWI3IQ7NRLKMUHJ27JV3V2JAFDP/#W73IMPJVK3DNCRXS5OZXELVWJRDRT6KN"
moz-do-not-send="true">https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VVLHQAWI3IQ7NRLKMUHJ27JV3V2JAFDP/#W73IMPJVK3DNCRXS5OZXELVWJRDRT6KN</a><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/" moz-do-not-send="true">http://www.redhat.com/</a>
email: <a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:pemensik@redhat.com" moz-do-not-send="true">pemensik@redhat.com</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
dns-operations mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dns-operations@lists.dns-oarc.net">dns-operations@lists.dns-oarc.net</a>
<a class="moz-txt-link-freetext" href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a>
</pre>
</blockquote>
</body>
</html>