[dns-operations] SHA-1 DNSSEC verification broken in RHEL 9 and CentOS 9 Stream

Petr Menšík pemensik at redhat.com
Wed Apr 13 17:06:06 UTC 2022


Hello DNS users,

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:

docker pull quay.io/centos/centos:stream9

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.

I have filled tracker bug for EPEL9 components I know on bug #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.

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.

A simple workaround would be switching to crypto policy DEFAULT:SHA1:

update-crypto-policies --set DEFAULT:SHA1

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.

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?

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].

Best Regards,

Petr

1. https://bugzilla.redhat.com/show_bug.cgi?id=2073066
2. https://bugzilla.redhat.com/show_bug.cgi?id=2073066#c7
3. https://datatracker.ietf.org/doc/html/rfc8624#section-3.1
4. https://chat.dns-oarc.net/community/channels/town-square
5. https://lists.nlnetlabs.nl/pipermail/unbound-users/2022-April/007709.html
6.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VVLHQAWI3IQ7NRLKMUHJ27JV3V2JAFDP/#W73IMPJVK3DNCRXS5OZXELVWJRDRT6KN

-- 
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: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20220413/737a6994/attachment.html>


More information about the dns-operations mailing list