Zitat von "W.C.A. Wijngaards" <wouter at NLnetLabs.nl>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Lately there have been operational failures, where domains became > DNSSEC-bogus, for which it is possible to 'fix' unbound. What happened > was a failure in algorithm rollover that left virginia.gov > un-validatable by unbound (but bind worked). Unbound detected it as > algorithm downgrade and it failed validation. > > Should we turn off algorithm downgrade protection? > > There can be an option to turn it back on, but most users won't bother > to do that. With 'algorithm-protection: yes/no' in unbound.conf. If > there is such an option, what is then its default value? > > What is algorithm downgrade? If one algorithm is broken, say > Hash-Algorithm-X, then it is no longer safe. Unbound, today, protects > zones that are signed with multiple algorithms by checking all the > algorithms. Thus the strongest algorithm protects, not the weakest. > http://unbound.net/documentation/info_algo.html > > On the dnssec-deployment list, several experts have said they consider > unbound to be too strict. It should not provide algorithm protection. > It should leniently accept these operational mistakes where a DS with an > unused algorithm is present. > > Discussion summary > > * algorithm downgrade is considered very unlikely. > * algorithm downgrade, of RSASHAx, has such large consequences that a > pre-emptive validator fix is not interesting. > * software update can be used to control algorithms the software > considers safe. > * the zone owner can control what algorithm is used. > * The mistake in this case - extra DS - causes all validators that > support only that algorithm, not the other, to be bogus. So it is a > mistake where a large portion of the validators return bogus. Do we > really need to save operators from this? > * The virginia case was a corner case with its NSEC3-related rollover. > It was the same algorithm with a different NSEC3-flag. > * false positives, such as caused by this, cause damage to dnssec > deployment. To the willingness to turn it on. > * signers must communicate with the parents. And this shows how it can > go wrong. Had communication worked, the signer would not have generated > this zone. It could just as well have been that the DS record for the > working KSK had been removed leaving the old KSK DS behind. Or that the > new KSK was not inserted. This is a similar operational error, for > which unbound can not be fixed. > * for a correctly signed zone, valid chains of trust with every > algorithm (that it uses) have to be present, as per RFCs. The > information ought to be there. With all others beside RFC should be followed so my vote would be to have the switch 'algorithm-protection: yes/no' with default "yes" and a warning that while "No" will fix some corner cases it lowers the security promise for DNSSEC and is not RFC conform. Regards Andreas