Tony Finch <d...@dotat.at> 2013-01-17 12:02:
Brian Kroth <bpkr...@gmail.com> wrote:RFC 4035 sec 2.2 says There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any). This says to me that you can have extra DNSKEY records (that don't yet have a corresponding DS pair upstream), but not extra DS records (that don't yet have a corresponding DNSKEY downstream), since every DS records must have a key and sig associated with it.Be careful: this paragraph is about zones that are signed with more than one algorithm. It says that you can't have a DS record for an algorithm that isn't used to sign a zone. It's fine to have DS records without matching DNSKEY records, provided there is another DS with the same algorithm that does have a matching DNSKEY record.This says to me that the RFC also acknowledges that things might/will get out of sync due to caching in DNS, but doesn't describe to me what resolvers do in that context. Do they complain that the DS they happened to choose to look for a valid chain of trust didn't work and throw the whole thing out, or do they just move along to the next one in the hopes that it might succeed?The latter.Given the latest RFC evidence I posted, I think my summary view is as follows, please correct me if it seems wrong: 1) DS records are just used to validate the chain of trust upstream for DNSKEY records found downstream, so there MUST exist a DS record for each DNSKEY/RRSIG chain you intend to have used for validating RRSIGs (though not for just standby keys that are listed in DNSKEY records but not signing), but there need not exist a DNSKEY/RRSIG chain for each DS record (which is what contradicts 4035 2.2). So, we could prepublish DS records without an issue, but DNSKEYs that are published must be validated by an existing chain of trust (DNSKEY/DS pair) before they can be used to validate other RRSIGs.That doesn't sound quite right to me. It's probably easiest to work upwards: Each RRset in a zone must be signed by a private key corresponding to one of the zone's DNSKEY RRs. Different RRsets can be signed by different keys. In particular, it is common for the DNSKEY RRset to be signed by a different key (a key-signing key) from the rest of the zone (which uses a zone-signing key); there may be more differences during a key rollover. The KSKs are special in that they authenticate the zone's keys. For a zone to be secure there must be a DS record in the parent corresponding to a KSK. If a particular DNSKEY is not self-signed then it fails to prove the zone admin has both private and public halves of the key. DS records corresponding to ZSKs are useless. There can be extra DS records and extra DNSKEY records. They are ignored if they aren't usable as part of a validation chain. So the usual chain of authentication is parent RRSIG(DS) child DS -> DNSKEY(ksk) <-> RRSIG(DNSKEY) DNSKEY(ksk) DNSKEY(zsk) -> RRSIG(A,NS,MX etc) A,NS,MX etc If you are signing with multiple algorithms then it must be possible to validate the zone using each algorithm by itself. That is, each algorithm must have a ZSK and a KSK and an RRSIG on every record. The zone is considered bogus if it is bogus according to any of the algorithms. A validator knows whether to expect multiple algorithms for a zone by examining its DS RRset in the parent. So for an algorithm rollover you need to get all the DNSKEYs and RRSIGs for the new algorithm in place before adding it to the DS RRset, and you must remove the old algorithm from the DS RRset before removing its DNSKEYs and RRSIGs. You have much less flexibility than there is for normal key rollovers. Pay attention to the following sentence in RFC 6781 section 4.1.4! Note that the Double-DS KSK rollover method cannot be used, since that would introduce a parental DS of which the apex DNSKEY RRset has not been signed with the introduced algorithm. It is also worth looking at http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing You do not need to follow the timing restrictions in RFC 5011 unless you support users that have configured a trust anchor for your zone. If you only support the normal validation chain from the root then RFC 5011 is not relevant. Tony.
Thanks, this is pretty clear.I think it just means that if I want to script key algorithm rollover (the answer here might just be don't [1]), then I at least have to maintain the dsset- files myself since the ones obtained from dnssec-signzone just include everything that was used to sign things with and during an algorithm rollover, I may need/wish to either not publish a DS record yet, or remove a DS record from publication prior to removing the signatures (so that things timeout in the right order).
I guess my last confusion is, how does the REVOKE bit on the old algorithm's KSK affect this?
For instance, suppose I did the following: - gen new algorithm keys and sign with them - wait for some period then publish the new DS (old DS remains)- revoke the old algorithm KSK (leave the ZSK alone), which changes its DS fingerprint, so publish a new DS
However, if I'm reading things correctly, then the REVOKE bit really just governs automatic trust-anchor updates for clients that support that mechanism, but the key is still usable for validating at the very least itself, if not also other RRSIGs (eg: for compatibility with clients that don't understand the REVOKE bit and have another trust anchor to work off of?).
In looking at an example, dnssec-signzone still signs a DNSKEY record which includes the old algorithm's ZSK for that zone, so I think there's still a valid chain of trust, and the same RFC 6781 4.1.4 note applies.
If this is true, then the only way to actually complete the algorithm rollover is to just drop the algorithm from the DS records once the new algorithm is in place, but before actually dropping the RRSIGs and DNSKEY records for that algorithm, correct?
Thanks for you help, Brian[1] I guess I should have mentioned that basically I got stuck with a system with a deficient dnssec implementation on 100+ zones that are generated from a db via perl, so I was really hoping in the course of fixing it up to to get to something where I (or the person behind me) could just change $ALG = 'NEW_VALUE' and have it complete the rest of the steps as necessary, even if some of them were just "compare expected vs. seen DS and generate an email to tell people to push things up stream when they need to be updated". Now, it's looking more and more to me like some of this just isn't possible to automate well.
signature.asc
Description: Digital signature
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
