Description of problem: Crypto policies in RHEL9 will block SHA-1 signatures by default. However RFC 8624 [1] requires SHA-1 validation as mandatory. Because crypto policy is mandatory, it will affect any DNSSEC validating software using openssl or gnutls. Version-Release number of selected component (if applicable): openssl-libs-3.0.1-21.el9.x86_64 crypto-policies-20220223-1.git5203b41.el9_0.1.noarch gnutls-3.7.3-9.el9.x86_64 How reproducible: reliable Steps to Reproduce: 1. delv int Actual results: # delv int ;; EVP_VerifyFinal failed (verify failure) ;; error:03000098:digital envelope routines::invalid digest:crypto/evp/pmeth_lib.c:959: ;; EVP_VerifyFinal failed (verify failure) ;; error:03000098:digital envelope routines::invalid digest:crypto/evp/pmeth_lib.c:959: ;; validating int/DNSKEY: no valid signature found ;; insecurity proof failed resolving 'int/DNSKEY/IN': 10.2.32.1#53 ;; validating rtma1k8jfek31ikuajq7rie9dufhe33b.int/NSEC3: bad cache hit (int/DNSKEY) ;; broken trust chain resolving 'int/A/IN': 10.2.32.1#53 ;; resolution failed: broken trust chain Expected results: ;; resolution failed: ncache nxrrset ; negative response, fully validated ; int. 3000 IN \-A ;-$NXRRSET ; int. SOA sns.dns.icann.org. noc.dns.icann.org. 2022040601 3600 1800 604800 3600 ; int. RRSIG SOA ... ; rtma1k8jfek31ikuajq7rie9dufhe33b.int. RRSIG NSEC3 ... ; rtma1k8jfek31ikuajq7rie9dufhe33b.int. NSEC3 1 0 5 398954BBB503FF9D S2BQ3UEQJHSGU7FE7M8QPQ563E9PTFH5 NS SOA RRSIG DNSKEY NSEC3PARAM Additional info: command "update-crypto-policies --set DEFAULT:SHA1" will switch to crypto policy, which would allow previous behaviour and success of both signature verification and creation. 1. https://datatracker.ietf.org/doc/html/rfc8624#section-3.1
This bug is intended just as a tracker to common issue among multiple implementations. It exist just to link related issues together on multiple components.
Adding also reference to original bug #1934936, bug #1935491 and bug #1936677. They were made as warning SHA-1 is considered problematic, but library allowed verification and they did not specify how it would be enforced.
Looks like the change to the underlying crypto libraries are going to require changes to all the software identified in the linked bug reports to ensure that they don't consider a DNSKEY that uses SHA1 for signing to be a legitimate key. It's possible to individually patch each tool to ensure that it rejects every DNSKEY that has this algorithm, but it would be more forward-looking to ensure that each tool is patched to query a specific, reasonable API in the dependent crypto library to ensure that a given algorithm isn't deprecated for signatures. Is there some documentation for how to query each underlying affected crypto library about this? If we make this a generic approach, then there's just this one round of patching for all the downstream tools, and then algorithm deprecation can happen in the crypto libraries safely in the future. This would be a good place to identify the specific API for OpenSSL (used by bind) and nettle (used by knot's libdnssec) that the dependent packages should use.
I think nettle does not enforce any policy. If it uses nettle directly, it should not be affected. We don't consider nettle directly a good library for direct use, but implementation detail of gnutls. dnsmasq uses it also, but it has bug #1956873 filled to stop that.
Interesting reference would be in thread about implementing this change to Fedora: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VVLHQAWI3IQ7NRLKMUHJ27JV3V2JAFDP/#W73IMPJVK3DNCRXS5OZXELVWJRDRT6KN Mentions bug #2059424 and bug #2059101, which got affected too. Also bug #2060798. But important reference seems to bring bug #2070977.
Created attachment 1872246 [details] top level domains with SHA-1 dnskeys in CSV format List of Top Level Domains, which are still signed by SHA-1 based algorithm. Any name ending with them would become insecure on RHEL 9.0. It worst case it would fail to resolve.
Relevant thread on unbound: https://lists.nlnetlabs.nl/pipermail/unbound-users/2022-April/007709.html Announced also on dns-operations list: https://lists.dns-oarc.net/pipermail/dns-operations/2022-April/021618.html and on epel-devel list: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/SJQUGL7SRXNE44NWHQE7MXGLBWYCAJT4/
This change would be also relevant on Fedora, but the change has been only announced: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/SIASBM62XE6WJBNOA7H5CTOU3E6HNS32/
Related Fedora change proposal: https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning1
Proposal on openssl [1] API to query or set legacy support. It should help with checking availability of the algorithm. 1. https://github.com/openssl/openssl/issues/17662