<div dir="ltr"><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 11, 2022 at 7:23 PM Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org">ietf-dane@dukhovni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Aug 11, 2022 at 06:41:23PM -0400, Donald Eastlake wrote:<br>
<br>
> So say a zone is signed by the zone owner with both BK and a strong<br>
> algorithm denoted STRONG. As long as a resolver only trusts STRONG<br>
> signatures I don't see how the status of what NSECs say is signed can cause<br>
> forged data to be trusted.<br>
<br>
The issue is arguable lack of clarity in the validator requirements of<br>
4035 when the server returns only RRSIGs with algorithms none of which<br>
are supported by the validator.<br>
<br>
When only unsupported algorithms appear in DS, the zone is "insecure"<br>
and all's well.  But otherwise, when only unsupported algorithms (or<br>
none at all) appear in an authoritative RRset's set of RRSIGs, the<br>
response is "bogus" not "insecure".<br>
<br>
The question of which algorithm is stronger or weaker does not arise<br>
here, MiTM can in fact "downgrade" a multi-signed zone to its weakest<br>
signing algorithm, by stripping the other RRSIGs.  Don't use broken<br>
algorithms, by switching away from deprecated algorithms in a timely<br>
fashion.  This has largely been accomplished for algorithms 5 and 7,<br>
which are down to ~7% of their peak deployment counts.<br>
<br>
DNSSEC algorithm agility is serving its intended purpose just fine.<br>
Resolver implementations had an apparently somewhat common bug, which<br>
most should have addressed by now (that the issue is public).<br>
<br>
-- <br>
    Viktor.<br>
_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net" target="_blank">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
</blockquote></div>