Bug 2073066 (el9_dnssec_sha1)
| Summary: | SHA-1 DNSSEC signatures are broken in DEFAULT crypto-policy | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora EPEL | Reporter: | Petr Menšík <pemensik> | ||||
| Component: | distribution | Assignee: | Petr Menšík <pemensik> | ||||
| Status: | NEW --- | QA Contact: | |||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | epel9 | CC: | carl, dkg, kevin, matt.castelein, ngompa13, peter.van.dijk, riehecky, stefano.biagiotti | ||||
| Target Milestone: | --- | Keywords: | UserStory | ||||
| 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: | 2073072, 1934936, 1935491, 1936677, 2070230, 2070495, 2073068, 2073081, 2073088, 2075672 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Petr Menšík
2022-04-07 15:07:18 UTC
This bug is intended just as a tracker to common issue among multiple implementations. It exist just to link related issues together on multiple components. Adding also reference to original bug #1934936, bug #1935491 and bug #1936677. They were made as warning SHA-1 is considered problematic, but library allowed verification and they did not specify how it would be enforced. Looks like the change to the underlying crypto libraries are going to require changes to all the software identified in the linked bug reports to ensure that they don't consider a DNSKEY that uses SHA1 for signing to be a legitimate key. It's possible to individually patch each tool to ensure that it rejects every DNSKEY that has this algorithm, but it would be more forward-looking to ensure that each tool is patched to query a specific, reasonable API in the dependent crypto library to ensure that a given algorithm isn't deprecated for signatures. Is there some documentation for how to query each underlying affected crypto library about this? If we make this a generic approach, then there's just this one round of patching for all the downstream tools, and then algorithm deprecation can happen in the crypto libraries safely in the future. This would be a good place to identify the specific API for OpenSSL (used by bind) and nettle (used by knot's libdnssec) that the dependent packages should use. I think nettle does not enforce any policy. If it uses nettle directly, it should not be affected. We don't consider nettle directly a good library for direct use, but implementation detail of gnutls. dnsmasq uses it also, but it has bug #1956873 filled to stop that. Interesting reference would be in thread about implementing this change to Fedora: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VVLHQAWI3IQ7NRLKMUHJ27JV3V2JAFDP/#W73IMPJVK3DNCRXS5OZXELVWJRDRT6KN Mentions bug #2059424 and bug #2059101, which got affected too. Also bug #2060798. But important reference seems to bring bug #2070977. Created attachment 1872246 [details]
top level domains with SHA-1 dnskeys in CSV format
List of Top Level Domains, which are still signed by SHA-1 based algorithm. Any name ending with them would become insecure on RHEL 9.0. It worst case it would fail to resolve.
Relevant thread on unbound: https://lists.nlnetlabs.nl/pipermail/unbound-users/2022-April/007709.html Announced also on dns-operations list: https://lists.dns-oarc.net/pipermail/dns-operations/2022-April/021618.html and on epel-devel list: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/SJQUGL7SRXNE44NWHQE7MXGLBWYCAJT4/ This change would be also relevant on Fedora, but the change has been only announced: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/SIASBM62XE6WJBNOA7H5CTOU3E6HNS32/ Related Fedora change proposal: https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning1 Proposal on openssl [1] API to query or set legacy support. It should help with checking availability of the algorithm. 1. https://github.com/openssl/openssl/issues/17662 |