DNSSEC DS vs DNSKEY record publication order question (wrt key algorithm rollover)

[Brian Kroth]

Tony Finch <dot at dotat.at> 2013-01-17 12:02:
> Brian Kroth <bpkroth at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130117/e8290c4e/attachment.bin>