[Unbound-users] Algorithm downgrade protection

[W.C.A. Wijngaards]

-----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.

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOcfbkAAoJEJ9vHC1+BF+NPgwQAIsAm5fUWtPaWjauu6fQdAH7
RrCbJqrc1qw4iOQUsLplntqcCKNijjR7H8NgFhWe5GtUDUTAYVVGv8ueO82oaZA5
/GtgodLnzoa/gFfcpz7pWHrI1HwHnWLD47yjrJ7SR+Y7HOPHku0nvBCkzwIBI5LL
s5XOOg9PAOcoGmbZ9TqIKm7r8xFBvFGd/g5pvJBRj8StlsV2lABA7pEC6eBd5oMp
0OojKvyW0g8i3gM3Zo0AOSgwGiOHqa8dWNbi/wYnn5Xncl55maJJDo91Ic+5WLjm
gioUodPFoHn+3D7k6XSnzBiLXJAc1rfdYGvVnkrsZ+oAXoYZDdbZQ9pPXw05jdAm
LLfhb0+QS/5yi5LQvqg2MUHbI2KwLwph/6XVT26KwG2eRn/HmadWxOcC/yDADIbO
ZBmU/d8BqmF36nhYJeCfq1FgkvtwLRivmZGfutSS0tNRye+GTxLcJQCknr/zS54/
pGBPZjq/VOz+I1IJiVBhCgH3o0jlx7zcqTMgsqfikrjQRVXLxYaIjxp7PLA8tCtd
lxUgtu2q5J/Qnz+m5RqjUmJkR/C0p9eKyh8K8ugMh4anFE3kMfch6Ve4B9/g86Vx
TDWPqFxX4GNLmH6LfcyGgBpZeGmrW6cZtsLfdpnAUdinzAQqPwrjbIkpXFvRVKHg
8IySnmHihGogSjXm6ce3
=OY8/
-----END PGP SIGNATURE-----