BIND 9.7.0a1 and dnssec-signzone verification

[Holger.Zuleger at arcor.net]

Thanks to all for the fast reply and the detailed answers.
And thank you very mutch for the verifing option of dnssec-signzone.
With it (and your help) I've learned again a bit more about dnssec.

> 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.
This was nothing I wanted to do in a productive zone. It was only an
example zone, but thanks again for the hint how to handle this.

Holger