Looks like the 'downgrade attack' is actually a consequence of the fact that support for multiple algorithms means that you end up with the security of the weakest. So not really an 'attack' but a consequence of the design approach not considering the downgrade issue worth addressing because people should not be signing under multiple algorithms for very long.
But given that, I think we are long past the time when anyone is doing anything of the slightest value signing with SHA-1. There is no reason to pick SHA-1 over SHA-2. You are not going to improve interop, you are much more likely to harm it. So moving SHA-1 to MUST NOT seems like the way to go. On Thu, Aug 11, 2022 at 7:23 PM Viktor Dukhovni <[email protected]> wrote: > On Thu, Aug 11, 2022 at 06:41:23PM -0400, Donald Eastlake wrote: > > > So say a zone is signed by the zone owner with both BK and a strong > > algorithm denoted STRONG. As long as a resolver only trusts STRONG > > signatures I don't see how the status of what NSECs say is signed can > cause > > forged data to be trusted. > > The issue is arguable lack of clarity in the validator requirements of > 4035 when the server returns only RRSIGs with algorithms none of which > are supported by the validator. > > When only unsupported algorithms appear in DS, the zone is "insecure" > and all's well. But otherwise, when only unsupported algorithms (or > none at all) appear in an authoritative RRset's set of RRSIGs, the > response is "bogus" not "insecure". > > The question of which algorithm is stronger or weaker does not arise > here, MiTM can in fact "downgrade" a multi-signed zone to its weakest > signing algorithm, by stripping the other RRSIGs. Don't use broken > algorithms, by switching away from deprecated algorithms in a timely > fashion. This has largely been accomplished for algorithms 5 and 7, > which are down to ~7% of their peak deployment counts. > > DNSSEC algorithm agility is serving its intended purpose just fine. > Resolver implementations had an apparently somewhat common bug, which > most should have addressed by now (that the issue is public). > > -- > 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
