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

Thu Apr 14 05:52:43 UTC 2022

On Thu, Apr 14, 2022 at 10:32:18AM +0530, Shreyas Zare wrote:
> 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.

Petr's email seems limited to use of RSASHA-1 and NSEC3RSASHA1 as RRSIG
algorithms, and possibly DS digest type.

As you point out, SHA-1 is used in NSEC3. It is also used in TSIG
(hmac-sha1), but these are not affected in the same way currently as use
in RRSIG and DS. Removing SHA-1 support completely would be very
disruptive. Even removing support at the OS level for RRSIG and DS seems
extreme - it is better to allow this to be configured in the DNS
implementation.

NSEC3 uses SHA-1 as a one-way hash function to obfuscate the
corresponding owner name so that a "zone walk" to enumerate all the
names in a zone is not as straightforward as with NSEC, but it does not
rely on cryptographic hash function properties such as second pre-image
resistance, pre-image resistance (back to the original owner name) or
even collision resistance. So the usage in NSEC3 would not be affected
by the current weaknesses in SHA-1.

HMAC usage of SHA-1 is also still considered safe and "approved" for use
(e.g., NIST SP 800-57 Part 1 Rev 5 section 5.6.1.2), which is used with
TSIG.

TKEY still makes use of MD5 - there was a dnsop thread by Mark Andrews
about updating it recently.

		Mukund

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

> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20220414/4eb14719/attachment.sig>