auth, rec: RSA-SHA1 broken on EL9

[Habbie]

• Program: Authoritative, Recursor
• Issue type: Bug report
• Affects: auth 4.8, rec 4.9

Short description

Red Hat has decided that RSASHA1 validation (and signing?) is, by default, forbidden in EL9, even for DNSSEC.

This breaks auth if a user has algo 5/7 keys:

# pdnsutil test-algorithms
Testing algorithm 5(RSASHA1): 'OpenSSL RSA' ->'OpenSSL RSA' -> 'OpenSSL RSA' (2048 bits) OpenSSL RSA: Could not initialize context for signing: 50331800:digital envelope routines::invalid digest - crypto/evp/m_sigver.c:343 - do_sigver_init
Testing algorithm 7(RSASHA1-NSEC3-SHA1): 'OpenSSL RSA' ->'OpenSSL RSA' -> 'OpenSSL RSA' (2048 bits) OpenSSL RSA: Could not initialize context for signing: 50331800:digital envelope routines::invalid digest - crypto/evp/m_sigver.c:343 - do_sigver_init

This breaks recursor - icann.org, which currently is signed with algo 7, is declared BOGUS.

Workaround

Running update-crypto-policies --set DEFAULT:SHA1 (and restarting affected daemons) makes the problem go away. LEGACY also works, but likely allows more things that users may not want. (you may need to dnf install crypto-policies-scripts)

Handling in other software

For BIND, update-crypto-policies generates a snippet (included from named.conf) that explicitly disables the affected algorithms, which changes the outcome from Bogus to Insecure.

Unbound handles the failure case explicitly: NLnetLabs/unbound@6cfcf21

cznic libdnssec (gnutls, not openssl): https://gitlab.nic.cz/knot/knot-dns/-/commit/b0c6f0709aeab#3b7edfb68fbd436c6b46dcbb2c7a8c0cc6d5fd92_264_266

Fixing this

Some proposals:

configurable DNSSEC policy

if we add support for a feature like disable-algorithms=5,7 to Recursor, users at least have a quick workaround to go insecure for such keys without changing the systemwide policy. Configuration of that feature could maybe be integrated into the systemwide policy like RHEL has done for BIND.

detect the situation/handle the error

Either during validation handle the specific error (like Unbound does), or do a check at startup and then automatically disable the algorithms.

document it

We could also decide to just document that everything will be broken until the user updates the systemwide policy so OpenSSL allows RSA-SHA1 validation.

[zeha]

I guess pdns could also init openssl with an explicit policy, or at least openssl.cnf?

[omoerbeek]

I did search for a way to configure openssl (either programmatically or via i'ts .cnf file), but did not find it

[omoerbeek]

I think the steps ahead are:

1. document how to change system wide policy for RHEL9 for now in upgrade guide
2. Implement method to disable specific algos, so we get Insecure for zones affected
3. Update docs to reflects the choices: either change system wide policy (so the zones affected can be validated), or disable to specific algos (with the consequence to zones become Insecure)

[Habbie]

I guess pdns could also init openssl with an explicit policy, or at least openssl.cnf?

it is my understanding that it's not possible to influence or even query the policy from our end

[omoerbeek]

A step 4. could be: a smart way to adapt. That would involve a test to see if the algos work and then disable the algos if not. That way the default RHEL9 config would “work” (go Insecure) and if the sysadmin enables a policy we adapt and start validating.

[Habbie]

That would involve a test to see if the algos work and then disable the algos if not.

I have just learned that this is what BIND9 does (outside of RHELs automatic configuration).

[Habbie]

for auth, Otto suggests teaching check-zone to warn about keys using unsupported algorithms.

[mnordhoff]

Should Recursor use EDE? Code 1, "Unsupported DNSKEY Algorithm", perhaps?

[omoerbeek]

Should Recursor use EDE? Code 1, "Unsupported DNSKEY Algorithm", perhaps?

I would not have been be surprised if that would work automatically if we modify the return value of DNSCryptoKeyEngine::isAlgorithmSupported()

But alas, I was wrong, DNSSEC related EDE is only added to an answer if it is Bogus, not when going Insecure

[Habbie]

#12891 is the first step for documenting the problem for existing users. It points at this issue, because it is actively developing. Eventually we should update the docs once more to explain what we actually did to make it easy to deal with this issue.

[mortenstevens]

A step 4. could be: a smart way to adapt. That would involve a test to see if the algos work and then disable the algos if not. That way the default RHEL9 config would “work” (go Insecure) and if the sysadmin enables a policy we adapt and start validating.

I believe that would be the best approach and would save us a lot of bug reports on both sides (Fedora/Red Hat) and PowerDNS.