Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

[Ben Schwartz <[e-mail]>]

Paul Wouters is correct, the "validate all" behavior I'm describing is
basically Unbound's "harden-algo-downgrade".  (I don't know if it does
"validate all" or a priority list.)

My claim is that, if this were the default validator behavior, the original
debate here would largely go away.  Adding algorithms to a zone, even
algorithms that you don't really trust, would be safe, and the registry
would be less controversial.

If we applied similar logic to DNSKEY, that would solve the RSA-1024
problem.  Currently, zone owners can either publish RSA-1024 DNSKEYs (and
be vulnerable if RSA-1024 is broken, which appears imminent), or they can
_not_ publish them, and cause users who don't support their other key type
(e.g. ECDSA) to lose DNSSEC entirely.  RSA-1024 is neither sufficiently
secure for general use nor so worthless that we lose nothing if, by
dropping it, we deny DNSSEC to those users ... but those are the only
options we offer.

>  Literally any preference order
> > would be more secure than the behavior recommended in RFC 6840.
>
> Is it? Are you referring here to treating unknown (eg refused)
> algorithms as insecure?
>

No, I'm referring to marking the result as Bogus when one RRSIG tells you
so, instead of continuing down the list of RRSIGs looking for one that
validates (RFC 6840's "any single valid path").