<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<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>
<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>
</span></p>
<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">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">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">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">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">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">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/">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>