-
Bug
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
None
-
Moderate
-
rhel-sst-cs-plumbers
-
ssg_core_services
-
8
-
False
-
-
None
-
None
-
None
-
None
-
If docs needed, set a value
-
-
Unspecified
-
None
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
[RHEL-5903] [systemd-resolved] SHA-1 DNSSEC signatures are broken in DEFAULT crypto-policy
pm-rhel
added a comment - Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.
pm-rhel
added a comment - Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug. 
Frantisek Sumsal
added a comment - 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
Frantisek Sumsal
added a comment - 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 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.
David Tardon
added a comment - (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?
David Tardon
added a comment - (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? 
Stale date bump