Bug 2073081 - [knot-resolver] SHA-1 DNSSEC signatures are broken in DEFAULT crypto-policy
Summary: [knot-resolver] SHA-1 DNSSEC signatures are broken in DEFAULT crypto-policy
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: knot-resolver
Version: epel9
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Vladimír Čunát
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: el9_dnssec_sha1
TreeView+ depends on / blocked
 
Reported: 2022-04-07 15:27 UTC by Petr Menšík
Modified: 2022-07-15 08:54 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2022-07-15 08:54:48 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.