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

Thu Apr 14 06:47:41 UTC 2022

On Thu, Apr 14, 2022 at 11:22:43AM +0530, Mukund Sivaraman wrote:
> 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

This should say "*except* back to the original owner name".

> 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

> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

		Mukund
-------------- 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/2ea47f0e/attachment.sig>