[dns-operations] SHA-1 DNSSEC verification broken in RHEL 9 and CentOS 9 Stream

[Ondřej Surý]

I’m with Victor on this one. Disabling RSASHA1 signing in DNS software would be perfectly fine, crippling the validation is counterproductive and actively harmful.

Ondřej 
--
Ondřej Surý <ondrej at sury.org> (He/Him)

> On 13. 4. 2022, at 20:10, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
> On Wed, Apr 13, 2022 at 07:06:06PM +0200, Petr Menšík wrote:
> 
>> I know it violates still active RFC 8624 [3], but because it is enforced
>> by lower-level API, it is possible just to follow or fail. I think so
>> far every crypto call failure results in bogus result and returns status
>> SERVFAIL on the reply. Would it make sense to create some common cases,
>> where the result would be fallback to insecure reply without AD bit, but
>> no failure?
> 
> DNSSEC signature validation failure MUST NOT downgrade to "insecure".
> If a validating resolver expects to be able to validate algorithm 5 or 7
> RRsets then (barring specific NTAs) "bogus" (i.e. SERVFAIL) is the only
> correct response when signature validation fails unexpectedly.
> 
> * A validating resolver can only ignore signatures for algorithms it
>  does not support, or zones explicitly designated as insecure by local
>  policy (negative trust anchors or NTAs).
> 
> * For an expected to be supported algorithm (not disabled by local
>  policy, at compile time in the resolver software, ...) the only
>  reason to downgrade a validation error to "insecure" would be if the
>  error status is an unambiguous "late" indication that the algorithm
>  is unavailable by crypto library policy.  A new signal of this sort
>  requires new code in the resolver.
> 
> All the above said, I maintain that the new crypto policy is much too
> blunt a tool, that is suitable only for a narrow set (be it some of the
> most popular) of applications.
> 
> Barring known cross-protocol attacks, or other compelling issues, in
> opportunistic security applications (RFC 7435) some security is better
> than none.  Failing to validate RSA SHA1 signatures without an
> understanding of the application context is counterproductive and IMNSHO
> amounts to vandalism.
> 
> This change in the default crypto policy should be reconsidered, and
> any policy changes need to be applied at a higher (application) layer.
> 
> -- 
>    Viktor.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations