In message <20090624211854.a3be222...@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.zule...@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: ma...@isc.org _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
