[Unbound-users] Algorithm downgrade protection
Lst_hoe02 at kwsoft.de
Lst_hoe02 at kwsoft.de
Thu Sep 29 07:51:41 UTC 2011
Zitat von "W.C.A. Wijngaards" <wouter at NLnetLabs.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 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.
> 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.
More information about the Unbound-users