Bug 2073068

Summary:	[pdns] SHA-1 DNSSEC signatures will fail on RHEL 9
Product:	[Fedora] Fedora EPEL	Reporter:	Petr Menšík <pemensik>
Component:	pdns	Assignee:	Morten Stevens <mstevens>
Status:	ASSIGNED ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	epel9	CC:	mstevens, peter.van.dijk, ruben, sander
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-06-06 08:57:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2073066

Description Petr Menšík 2022-04-07 15:09:39 UTC

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

Comment 1 Petr Menšík 2022-04-10 15:35:03 UTC

It was tested by PowerDNS maintainer and it seems pdns does not use EVP_ methods to verify SHA-1 signatures. Then it seems it still passes, because disabled signatures are not enforced at lower level API. PowerDNS uses such API for RSA validation. If you could test it on latest CentOS 9 Stream container, please close this bug with NOTABUG.

Comment 2 Peter van Dijk (PowerDNS) 2023-06-06 09:14:55 UTC

auth 4.8 switches to EVP for RSASHA1 on systems that have OpenSSL 3 - like RHEL9. So, it's broken now.

Comment 3 Peter van Dijk (PowerDNS) 2023-06-06 09:43:49 UTC

(Recursor 4.9 is even more broken - SERVFAILs on icann.org)

Comment 4 Morten Stevens 2023-06-06 09:58:14 UTC

Alright, I will change the status back to open. Currently, we have version 4.7.4 in EPEL-9. We can continue using version 4.7.x for a while. However, I'm unsure about our next steps.

The easiest approach would be to provide a documentation recommending users to set the following crypto policy: update-crypto-policies --set DEFAULT:SHA1

However, I'm not sure what we should do as package maintainers since we cannot directly change the crypto policy. That is something the user would need to do themselves.

Comment 5 Peter van Dijk (PowerDNS) 2023-06-06 10:03:49 UTC

ah, thank you for DEFAULT:SHA1, I was about to put LEGACY in our docs

Comment 6 Peter van Dijk (PowerDNS) 2023-06-06 10:46:09 UTC

I collected my thoughts here: https://github.com/PowerDNS/pdns/issues/12890