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ý <[email protected]> (He/Him) > On 13. 4. 2022, at 20:10, Viktor Dukhovni <[email protected]> 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 > [email protected] > https://lists.dns-oarc.net/mailman/listinfo/dns-operations _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
