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

[Viktor Dukhovni]

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.