Bug 2077909

Summary: [unbound: FIPS mode] Resolution of many domains signed by just 1024 bit key would start failing
Product: Red Hat Enterprise Linux 9 Reporter: Petr Menšík <pemensik>
Component: unboundAssignee: Petr Menšík <pemensik>
Status: CLOSED MIGRATED QA Contact: rhel-cs-infra-services-qe <rhel-cs-infra-services-qe>
Severity: high Docs Contact:
Priority: unspecified    
Version: 9.0Keywords: MigratedToJIRA, Regression
Target Milestone: rc   
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: 2023-09-21 21:07:12 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: 2071543, 2077884, 2135933    
Bug Blocks:    

Description Petr Menšík 2022-04-22 14:59:15 UTC 
Description of problem:
Many DNSSEC ZSK keys used on public zones use short keys. Those short keys verifications works on RHEL 9.0 at the moment, but is going to be fixed by bug #2077884.

Version-Release number of selected component (if applicable):
unbound-1.13.1-13.el9_0.x86_64

How reproducible:
would be reliable


Steps to Reproduce:
1. kdig +multi -t dnskey 100.in-addr.arpa | grep '1[0-9]\{3\}b'
2. fips-mode-setup --enable && reboot
3. unbound-host -rdD -t dnskey 100.in-addr.arpa

Actual results:
validation failure <100.in-addr.arpa. DNSKEY IN>: ...

Expected results:
# unbound-host -rdD -t dnskey 100.in-addr.arpa
[1650638908] libunbound[5250:0] notice: init module 0: subnet
[1650638908] libunbound[5250:0] notice: init module 1: validator
[1650638908] libunbound[5250:0] notice: init module 2: iterator
[1650638908] libunbound[5250:0] info: resolving 100.in-addr.arpa. DNSKEY IN
[1650638908] libunbound[5250:0] info: response for 100.in-addr.arpa. DNSKEY IN
[1650638908] libunbound[5250:0] info: reply from <.> 10.2.32.1#53
[1650638908] libunbound[5250:0] info: query response was ANSWER
[1650638908] libunbound[5250:0] info: prime trust anchor
[1650638908] libunbound[5250:0] info: generate keytag query _ta-4f66. NULL IN
[1650638908] libunbound[5250:0] info: resolving . DNSKEY IN
[1650638908] libunbound[5250:0] info: resolving _ta-4f66. NULL IN
[1650638908] libunbound[5250:0] info: response for . DNSKEY IN
[1650638908] libunbound[5250:0] info: reply from <.> 10.2.32.1#53
[1650638908] libunbound[5250:0] info: query response was ANSWER
[1650638908] libunbound[5250:0] info: validate keys with anchor(DS): sec_status_secure
[1650638908] libunbound[5250:0] info: Successfully primed trust anchor . DNSKEY IN
[1650638908] libunbound[5250:0] info: resolving arpa. DS IN
[1650638908] libunbound[5250:0] info: response for _ta-4f66. NULL IN
[1650638908] libunbound[5250:0] info: reply from <.> 10.2.32.1#53
[1650638908] libunbound[5250:0] info: query response was NXDOMAIN ANSWER
[1650638908] libunbound[5250:0] info: response for arpa. DS IN
[1650638908] libunbound[5250:0] info: reply from <.> 10.2.32.1#53
[1650638908] libunbound[5250:0] info: query response was ANSWER
[1650638908] libunbound[5250:0] info: validated DS arpa. DS IN
[1650638908] libunbound[5250:0] info: resolving arpa. DNSKEY IN
[1650638908] libunbound[5250:0] info: response for arpa. DNSKEY IN
[1650638908] libunbound[5250:0] info: reply from <.> 10.2.32.1#53
[1650638908] libunbound[5250:0] info: query response was ANSWER
[1650638908] libunbound[5250:0] info: validated DNSKEY arpa. DNSKEY IN
[1650638908] libunbound[5250:0] info: resolving in-addr.arpa. DS IN
[1650638908] libunbound[5250:0] info: response for in-addr.arpa. DS IN
[1650638908] libunbound[5250:0] info: reply from <.> 10.2.32.1#53
[1650638908] libunbound[5250:0] info: query response was ANSWER
[1650638908] libunbound[5250:0] info: validated DS in-addr.arpa. DS IN
[1650638908] libunbound[5250:0] info: resolving in-addr.arpa. DNSKEY IN
[1650638908] libunbound[5250:0] info: response for in-addr.arpa. DNSKEY IN
[1650638908] libunbound[5250:0] info: reply from <.> 10.2.32.1#53
[1650638908] libunbound[5250:0] info: query response was ANSWER
[1650638908] libunbound[5250:0] info: validated DNSKEY in-addr.arpa. DNSKEY IN
[1650638908] libunbound[5250:0] info: resolving 100.in-addr.arpa. DS IN
[1650638908] libunbound[5250:0] info: response for 100.in-addr.arpa. DS IN
[1650638908] libunbound[5250:0] info: reply from <.> 10.2.32.1#53
[1650638908] libunbound[5250:0] info: query response was ANSWER
[1650638908] libunbound[5250:0] info: validated DS 100.in-addr.arpa. DS IN
[1650638908] libunbound[5250:0] info: resolving 100.in-addr.arpa. DNSKEY IN
[1650638908] libunbound[5250:0] info: validated DNSKEY 100.in-addr.arpa. DNSKEY IN
[1650638908] libunbound[5250:0] info: validate(positive): sec_status_secure
[1650638908] libunbound[5250:0] info: validation success 100.in-addr.arpa. DNSKEY IN
100.in-addr.arpa has DNSKEY record 257 3 8 AwEAAdu8S6vA/qjjqhpy+uHwCI6OROw/XYHEzflqQNIxx8duJgjoWNCcFWM2IFd0IYE/ZAIY8u1+eyV8abfnQNvLtww/SrNgOmkJwEJuato7sSOYUYdWMkYzUHtyvykaRk9/MeN+zFAJvSL3/qwI0WlQvgXeOpzpLdedndsy5SSAR9NnqWXnx8zsfDvbAlAKiw6jh4MGPZXYx7amuHdjUT56I8ve5kBDtmYokA4VsZnLkVvmXPrMBV7D/EkUMMnAh0E/vwpvTDymy+1FdlsUfahSTk5FDoefPCbM/rdLPIzaeOiv4hpBJRSVRmPqNXDpAYme7LBYeBoOY1HUCHdQu4GNLbk=
100.in-addr.arpa has DNSKEY record 256 3 8 AwEAAbR4oHfWLSP0zkavL3qHJ9zvfEwnKEOmivHW4iXicr5r/Qg1q0OBnvuXSPfZejCJ//3YQZdBG8iBLAH6GF7J+/Bw1txtXbAR38d1Vr2RGqrvk814QwunYBof/abLjFalp+oXkGROUa8ZyoYlM4j+rBsuUL8gVAATLJW+JQb8eYNN
100.in-addr.arpa has DNSKEY record 256 3 8 AwEAAdTgLMi5YbiAEE1zb2hXsmIIJIpqEt+YyV1NLbmeVYAoBvXKK+U3H6N2PrlQ/HEF0jNWBQfxIsvpkLuDZ/HOKlOuDaESaNHioLu42Jcfv4AQDRrjDiPvnmpzmOYFFVocDSd1wkM/6uZoz1kr8WtsXtDLT843xgY+GJL2moqwbNzn
100.in-addr.arpa has DNSKEY record 257 3 8 AwEAAcV24UXiGxCcmKYdQXt/z3W3JNgqh0ycG0/WTS/H+bXV/pmLB9N2fq45gwbJfS2UAvz7pMNqFYTdqaPNK0eCYal4fRVwZvI655pUZr/rXYHhj0ASvSmJZOV5wiiQ27VB30lM+57DXSYVzXdGIi16R3ScEE/HwdYq/Cuge/G/tUqYpOYowHDkEjPTtQB3SlZzlvCFNQ30l6y7i2/ZI5scmmS/QS18dZlsYRV6+aWIFY6AfQ5jZgS3Rrrs9mH9ZiJlvdh314bZDk7Zt1SBCI8/6JEdadt6DG0+TJMBl2lQZM/+UJUGtz+ZO30eVB5n6JQLCKU0wgrNouDks9hOxJNHFJM=


Additional info:
Similar bug #2077906 for bind. It is needed to find a way to make those queries insecure in FIPS mode, but not failing.


Another issue is with ED25519 and ED448 algorithms, which are disabled in FIPS mode. They make validation failing:

unbound-host -rD secure.d4a15n3.rootcanary.net.
secure.d4a15n3.rootcanary.net. has address 145.97.20.20
validation failure <secure.d4a15n3.rootcanary.net. A IN>: use of key for crypto failed from 10.x.x.1 for key d4a15n3.rootcanary.net. while building chain of trust
secure.d4a15n3.rootcanary.net. has IPv6 address 2001:610:188:408::20
validation failure <secure.d4a15n3.rootcanary.net. AAAA IN>: key for validation d4a15n3.rootcanary.net. is marked as invalid because of a previous validation failure <secure.d4a15n3.rootcanary.net. A IN>: use of key for crypto failed from 10.x.x.1 for key d4a15n3.rootcanary.net. while building chain of trust
validation failure <secure.d4a15n3.rootcanary.net. MX IN>: key for validation d4a15n3.rootcanary.net. is marked as invalid because of a previous validation failure <secure.d4a15n3.rootcanary.net. A IN>: use of key for crypto failed from 10.x.x.1 for key d4a15n3.rootcanary.net. while building chain of trust

Those are failing in sldns_ed255192pkey_raw and sldns_ed4482pkey_raw calls. A good fallback to insecure is needed for them as well.
Comment 1 RHEL Program Management 2023-09-21 20:52:01 UTC 
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.
Comment 2 RHEL Program Management 2023-09-21 21:07:12 UTC 
This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.