Bug 2075672

Summary: delv tool cannot validate SHA-1 signed domains in DEFAULT crypto-policy
Product: Red Hat Enterprise Linux 9 Reporter: Petr Menšík <pemensik>
Component: bindAssignee: Petr Menšík <pemensik>
Status: ASSIGNED --- QA Contact: rhel-cs-infra-services-qe <rhel-cs-infra-services-qe>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: CentOS StreamCC: bstinson, jwboyer
Target Milestone: rcKeywords: FutureFeature, Triaged
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: 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: 2070230    
Bug Blocks: 2073066    

Description Petr Menšík 2022-04-14 20:02:31 UTC
Description of problem:
RHEL 9.0 has obsoleted SHA-1 signatures. named is configured via crypto-policies package to disable RSASHA1 and NSEC3RSASHA1 algorithms (bug #2070230). delv tool from bind-utils validates using the same algorithm, but does not read any configuration file. It has no way to disable algorithms from command line or configuration file, even a custom one. It should modify named code to be able to test availability of SHA1 signatures.

Might need also ED25519 and ED448 algorithms detection in FIPS mode.

Version-Release number of selected component (if applicable):
bind-utils-9.16.23-1.el9.x86_64
crypto-policies-20220223-1.git5203b41.el9_0.1.noarch

How reproducible:
reliable

Steps to Reproduce:
1. delv int
2.
3.

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:
# delv int
;; resolution failed: ncache nxrrset
; negative response, fully validated
; int.			3408	IN	\-A	;-$NXRRSET
; int. SOA sns.dns.icann.org. noc.dns.icann.org. 2022040623 3600 1800 604800 3600
; int. RRSIG SOA ...
; rtma1k8jfek31ikuajq7rie9dufhe33b.int. RRSIG NSEC3 ...
; rtma1k8jfek31ikuajq7rie9dufhe33b.int. NSEC3 1 0 5 398954BBB503FF9D S2BQ3UEQJHSGU7FE7M8QPQ563E9PTFH5 NS SOA RRSIG DNSKEY NSEC3PARAM

or insecure, but successful reply.

Additional info:

Comment 1 Petr Menšík 2022-04-14 20:15:43 UTC
Pushed work in progress attempt on main branch to repository:

https://gitlab.isc.org/pemensik/bind9/-/commits/feature/main/sha1-runtime-disable

Not creating even Draft MR, because it won't compile yet.

Comment 2 Petr Menšík 2022-04-14 20:19:14 UTC
Marking as future feature, even when it is sort of regression compared to RHEL 8. But such behaviour does not exist in upstream and fresh new code is required as a workaround.

Comment 3 Petr Menšík 2022-04-30 10:33:07 UTC
Upstream has already a nice way to detect those support at FIPS mode changes: https://gitlab.isc.org/isc-projects/bind9/-/blob/mnowak/fix-fips-in-tests/lib/dns/opensslrsa_link.c#L1637