[DNSOP] Re: Questions before adopting must-not-sha1

[Petr Menšík <[e-mail]>]

I have found there is no need to link to different library. What is 
needed is just different *configuration*. I found a very simple method 
to share with you:

Use OPENSSL_CONF environment to point to conf file containing:

.include = /etc/ssl/openssl.cnf
[evp_properties]
rh-allow-sha1-signatures = yes

That is all needed to get SHA1 verification in DNSSEC back, without 
accepting SHA1 in TLS connections at the same time. Cool, eh?

I think it is quite okay to have SHA1 recognized on similar level as DNS 
cookies. It helps against cache poisoning, but is not reliable against 
attacker with significant resources (government agencies?). That is why 
I think setting AD for it should not be done, but it should be used as 
relative good source indication.

I don't know about any implementation we support, which would be able to 
report this. It is just full trust or nothing.

I am missing a good call indicating from the crypto library, that given 
key type and digest algorithm for signature is not considered strong 
enough. Our crypto team is not very supportive with this, not a priority 
for them. They are not DNSSEC fans anyway. Until we have a good way to 
get DS record trust level from crypto library, we can use just make 
strange hacks around.

If you can influence openssl upstream, please try. It is a common 
problem for (almost?) all open source implementations.

They have made openssl issue #17662 [1] for adding a separate 
definitions for signing and verification. Which is needed for the 
lifecycle mentioned, but not yet merged. I would add we need also 
interface to get that state back from the library, once configured.

More below...

1. https://github.com/openssl/openssl/issues/17662

On 13/11/2024 17:03, Philip Homburg wrote:
>> Tony Finch has correctly identified in SHA-1 chosen prefix collisions
>> and DNSSEC [3] article that when a single record is usually safe,
>> multiple records might allow creating fake signature even in DNSSEC.
> There are two types of attacks on hash functions: collisions and second
> pre-image attacks.
>
> There is no practical 2nd pre-image attack for SHA-1, so we can concentrate
> on collision attacks. A collision attack requires that the victim to
> accepts malcious data from an attacker
>
> There are many, proably even the majority of DNSSEC signed domains,
> where this is not an issue. Attackers cannot influence the contents of a
> zone. In those cases, using SHA-1 is secure.
No, zone stays where author has it. What might get different is what 
clients see.
> Obviously we need to move away from SHA-1 as fast as possible. But we do
> those domains a disservice if we treat them as insecure. In
> particular, DANE will stop working if a domain is considered insecure.
I think that is correct and needed. Consider them similar to DNS cookie 
verified. Better than nothing yes, strong authentication no. If 
something expects strong proof, SHA1 should not be trusted for that.DANE 
expect strong proofs IMO. But first someone needs to implement that.
> We already see the operational impact. People with RedHat systems notice
> that DANE suddenly stops working. They have no clue where is coming from,
> they just see that unbound doesn't set the AD bit.
We have it included in RHEL 9.0 Release notes [2] in clear words. It is 
not our fault documentation is not read, then someone is surprised.
> The solution should be that RedHat provides a way to link with a different
> crypto library that does support RSASHA1.

We should have provided helping configuration. If we had that at hand, 
we would have.

Hope that helps,
Petr

[2] 
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/9.0_release_notes/known-issues#known-issue_infrastructure-services

-- 
Petr Menšík
Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB