Bug 2073081

Summary: [knot-resolver] SHA-1 DNSSEC signatures are broken in DEFAULT crypto-policy
Product: [Fedora] Fedora EPEL Reporter: Petr Menšík <pemensik>
Component: knot-resolverAssignee: Vladimír Čunát <vladimir.cunat>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: epel9CC: dns-sig, jakub.ruzicka, jv+fedora, nicki, peter.van.dijk, pspacek
Target Milestone: ---   
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: 2022-07-15 08:54:48 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:27:00 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-11 12:28:01 UTC 
Note: I know knot-resolver does not yet have a build for EPEL9. This is just to make you aware of a potential problem. If there won't be any, please close this bug.
Comment 2 Vladimír Čunát 2022-07-15 08:54:48 UTC 
I believe this has never been broken.  Since crypto policies of Fedora, in 2020 we started to respect GnuTLS's policies [1].  So SHA1 zones were treated as insecure in there already, and based on my earlier testing this also worked in CentOS 9 without changing anything (after you switched to stronger restrictions).

In the meantime we also managed to get the package into EPEL 9.

[1] https://gitlab.nic.cz/knot/knot-dns/-/commit/b0c6f0709a