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

[Brian Kroth]

Brian Paul Kroth <bpkroth at gmail.com> 2013-01-15 23:19:
> Hello All,
>
> First, I'm not currently on the list, so please CC if me if you could.

Let's try this again now that I'm on the list.

> Next, I've been working on some scripts to get KSK rotation 
> semi-automated or at least alerting in our environment and I've got 
> some questions about the DS record requirements and their relation to 
> the files generated and included by dnssec-signzone's smart signing 
> feature.
>
> 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.
>
>
> RFC 4035 sec 2.4 says
>
> A DS RR SHOULD point to a DNSKEY RR that is present in the child's
> apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
> by the corresponding private key.  DS RRs that fail to meet these
> conditions are not useful for validation, but because the DS RR and
> its corresponding DNSKEY RR are in different zones, and because the
> DNS is only loosely consistent, temporary mismatches can occur.
>
> 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?
>
>
> RFC 5011 sec 6.6 says
>
> 1.  Generate a new DNSKEY and DS record and provide the DS record to
> the parent along with DS records for the old keys.
>
> 2.  Once the parent has published the DSs, add the new DNSKEY to the
> RRSet and revoke ALL of the old keys at the same time, while
> signing the DNSKEY RRSet with all of the old and new keys.
>
> 3.  After 30 days, stop publishing the old, revoked keys and remove
> any corresponding DS records in the parent.
>
> This says to me that DS records SHOULD be published before the DNSKEY 
> is, which seems to contradict the first quote.

To add some more confusion, RFC 4641 (now 6781) sec 4.2.4 also mentions 
standby keys and pushing DS records without DNSKEY records for KSK keys.

    The way to deal with stand-by keys differs for ZSKs and KSKs.  To
    make a stand-by ZSK, you need to publish its DNSKEY RR.  To make a
    stand-by KSK, you need to get its DS RR published at the parent.

> Why to the bind-users list you ask?  Well, I'm trying to figure out 
> if the dsset-* files generated by the "smart signing" feature of 
> dnssec-signzone -S are smart enough to be usable for key rotation 
> inclusion and warning scripts, or if I need to come up with that 
> logic on my own and generate and include DS records separately from 
> the -g option.
>
> I think it gets particularly tricky when you start considering things 
> like key algorithm rollover where one needs to (I think) first yank 
> the DS records, wait, then revoke the old algorithm keys, wait, then 
> yank the keys (mostly due to the first quote I posted).
>
> If the parent and child are on the same server and being resigned 
> during that waiting period, then dnssec-signzone will continue to 
> overwrite and include the olds keys in the dsset-* files, and the -g 
> option would normally just include them in the parent.  Unless I've 
> misinterpreted something above, the only way around that that I see 
> is to maintain your own DS records in the parent zones (whether 
> they're local or remote), including them manually (ie: via perl/db 
> :), and specifically *not* using the -g option (which makes me sad).
>
>
> Anyways, thoughts, opinions, advice?

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.

2) dnssec-signzone probably generates the right dsset-* files ("Does the 
Right Thing TM") and can be included without much thought.

3) With the above, in an algorithm rollover, I should be able to do 
something like this:

- Generate keys with a new algorithm and publish them, but don't 
   activate them yet.
# dnssec-keygen -a RSASHA256 -P +0 -A none parent.tld
# dnssec-keygen -a RSASHA256 -P +0 -A none -f KSK parent.tld
# dnssec-keygen -a RSASHA256 -P +0 -A none child.parent.tld
# dnssec-keygen -a RSASHA256 -P +0 -A none -f KSK child.parent.tld

- Include them in the zone, but don't sign with them yet - just use the 
   old algorithm keys for now.
# dnssec-signzone -S -g -x child.parent.tld.db
# dnssec-signzone -S -g -x parent.tld.db

- Publish the dsset-parent.tld. records (which include the old KSK 
   algorithm record as well) to tld
	At least for parent.tld, since dnssec-signzone -g parent.tld.db 
	will already have included the new ones from 
	dsset-child.parent.tld.

- Wait for max(DS TTL, DNSKEY TTL) to expire so another path to chain of 
   trust (through the new keys) is established.

- Activate the new keys and sign the zone with them.
# dnssec-setting -A+0 $new_alg_zsk_key
# dnssec-setting -A+0 $new_alg_ksk_key

- Revoke the old algorithm's KSK key, and inactivate the old algorithm's 
   ZSK key and mark them to be removed entirely in 30 days (the 
   HOLD_DOWN increment per 5011).

# dnssec-settime -I +0 -D +30d $old_alg_zsk_key
# dnssec-settime -R +0 -I +30d -D +60d $old_alg_ksk_key

- Resign the zone as above but this time it should only include 
   signatures for the new algorithm.


- After the 60 days have passed and the new dsset-* files generated from 
   periodic zone resigning no longer include the old algorithm's key, 
   push the new records upstream.

Seem reasonable?

Thanks,
Brian
-------------- 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/20130116/8d639bd8/attachment.bin>