[dns-operations] [dnsext] BlackHat Presentation on DNSSEC Downgrade attack

[Phillip Hallam-Baker]

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 <ietf-dane at dukhovni.org>
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
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20220811/bd75a19a/attachment.html>