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

[Shreyas Zare]

Hi,

Apart from DNSSEC validation, have you also tested DNS servers hosting 
DNSSEC signed zones with NSEC3? This is since NSEC3 only has SHA1 
specified 
<https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml> 
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.

Regards,
*Shreyas Zare*
Technitium <https://technitium.com/>

On 4/13/2022 10:36 PM, Petr Menšík wrote:
>
> 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
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20220414/5f9c6e89/attachment.html>