Bug 2073088

Summary: [systemd-resolved] SHA-1 DNSSEC signatures are broken in DEFAULT crypto-policy
Product: Red Hat Enterprise Linux 9 Reporter: Petr Menšík <pemensik>
Component: systemdAssignee: Michal Sekletar <msekleta>
Status: ASSIGNED --- QA Contact: Frantisek Sumsal <fsumsal>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: CentOS StreamCC: bstinson, dtardon, jamacku, jmigacz, jwboyer, msekleta, systemd-maint-list
Target Milestone: rcKeywords: Improvement, TestOnly, 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: 2138081    
Bug Blocks: 2073066    

Description Petr Menšík 2022-04-07 15:39:25 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. set DNSSEC=yes in /etc/systemd/resolved.conf
2. systemctl restart systemd-resolved
3. resolvectl query ietf.org

Actual results:
ietf.org: resolve call failed: DNSSEC validation failed: failed-auxiliary

Expected results:
ietf.org: 2001:1900:3001:11::2c                -- link: eth0
          4.31.198.44                          -- link: eth0

-- Information acquired via protocol DNS in 1.0828s.
-- Data is authenticated: yes; Data was acquired via local or encrypted transport: no
-- Data from: network


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 David Tardon 2022-04-08 11:38:00 UTC
(In reply to Petr Menšík from comment #0)
> Description of problem:
> Crypto policies in RHEL9 will block SHA-1 signatures by default. However RFC
> 8624 [1] requires SHA-1 validation as mandatory.

IOW, we have to support it but we can't... So what exactly is expected from us here?

Comment 2 Petr Menšík 2022-04-08 15:03:28 UTC
I think it should result in insecure response for SHA-1 algorithm on policies, where it would not pass verification. It should not make SHA-1 signed zones completely unavailable, but just considered like unsupported algorithm. Should not result in SERVFAIL, but just without AD flag in dns reply. That is the best way we can fix it.

I am not sure how much resolved is supported in RHEL9, I just filled the bug to notify you there is some issue, which might need fix eventually. Adding also link to JIRA ticket, which provides a list of TLDs affected.

Comment 4 Frantisek Sumsal 2023-02-21 13:55:58 UTC
This is still borked:

# rpm -q systemd
systemd-252-5.el9.x86_64
# grep ^DNSSEC= /etc/systemd/resolved.conf 
DNSSEC=yes
# resolvectl query --cache=no ietf.org
ietf.org: resolve call failed: DNSSEC validation failed: failed-auxiliary

# update-crypto-policies --set DEFAULT:SHA1
Setting system policy to DEFAULT:SHA1
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
# systemctl restart systemd-resolved
# resolvectl query --cache=no ietf.org
ietf.org: 2001:559:c4c7::100                   -- link: eth0
          50.223.129.194                       -- link: eth0

-- Information acquired via protocol DNS in 6.2ms.
-- Data is authenticated: yes; Data was acquired via local or encrypted transport: no
-- Data from: network