BIND 9.7.0a1 and dnssec-signzone verification

[Mark Andrews]

In message <20090624211854.A3BE222827 at thrintun.hactrn.net>, Rob Austein writes:
> At Wed, 24 Jun 2009 18:23:52 +0000, Evan Hunt wrote:
> > 
> > On Wed, Jun 24, 2009 at 05:45:33PM +0200, Holger.Zuleger at arcor.net wrote:
> > > I have some issues with dnssec-signzone under BIND 9.7.0a1.
> > > 
> > > I'm using different algorithms for key- and zone signing keys.
> > 
> > You can use multiple algorithms in a zone, but each algorithm must be
> > represented as both KSK and ZSK.  If you have an RSASHA1 KSK, an RSAMD5
> > KSK, an RSASHA1 ZSK and an RSAMD5 ZSK, you'll be fine.  But if all
> > your KSKs are RSASHA1 and all your ZSK's are RSAMD5, that's actually
> > a protocol violation.  dnssec-signzone should have been complaining
> > all along; it was a bug that it didn't.
> 
> Evan's rule (that the KSK and ZSK algorithms should match) is
> correct, but the reasons are a bit (more) complex.
> 
> The protocol requirement is that every signed RRset in a zone have an
> RRSIG for each algorithm listed in the zone's DS RRset in the parent.
> A simpler way of saying this is that every KSK algorithm in a zone
> must also be a ZSK algorithm.  Note that this has nothing to do with
> the SEP bit in the DNSKEY RRs, only to do with which keys sign which
> RRsets (the protocol forbids the validator from using the SEP bit).
> 
> The validator allows ZSK algorithms which are not KSK algorithms, but
> signing your zone that way leaves you vulnerable to the same algorithm
> downgrade attack that resulted in the seemingly bizzare protocol
> requirement noted above.  So don't do that.  Allowing ZSK algorithms
> that aren't KSK algorithms is useful during certain transitions, but
> you don't want verification to rely on mismatched algorithms.

Not so much a downgrade attack but validation failures may result
if you have a algorithm listed in the DS that are not used to sign
all the RRsets in the zone.  Preventing downgrade attacks are not
a DNSSEC design goal as it is any key validates.  That being said
you can have a validator that has policy knobs which aren't part
of the DNSSEC design goals but can be realised as a side effect of
trying to ensure that you have valid signatures for each algorithm.

Holger if you build dnssec-signzone with ALLOW_KSKLESS_ZONES defined
then the set of algorithms with self-signed DNSKEY records will be
used.  You will still get complains because you don't have a non
KSK key for RSASHA1.

You appear to be moving from a KSK less use of RSAMD5 to KSK aware
use of RSASHA1 and are in the pre-publish phase with RSASHA1 keys.
This isn't covered by the verifier.  I would add a non-KSK for RSASHA1
and set ALLOW_KSKLESS_ZONES to allow this transition to pass the
verifier.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org