Re: dnskey algorithm update

[Casey Deccio]

On Thu, Jan 7, 2016 at 3:00 PM, Carl Byington  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Thu, 2016-01-07 at 08:34 -0600, Jeremy C. Reed wrote:
> > On Wed, 6 Jan 2016, Carl Byington wrote:
>
> > > Is there a more authoritative document that describes the algorithm
> > > roll over procedure? It seems that I need to:
>
> > ISC has a DNSSEC Guide. See this section:
>
> > http://users.isc.org/~jreed/dnssec-guide/dnssec-guide.html#advanced-
> > discussions-DNSKEY-algorithm-rollovers
>
> > (Also in PDF format at the same directory.)
>
> > We still have some feedback to integrate into the guide, but if anyone
> > would like to participate, also see the GitHub site:
> > https://github.com/isc-projects/isc-dnssec-guide
>
>
> Based on RIPE experience at https://labs.ripe.net/Members/anandb/dnssec-
> algorithm-roll-over, where Unbound and Verisign make assumptions about
> the DS record set, we need to ensure that:
>
> adding an algorithm - you need to generate both KSK and ZSKs for the new
> algorithm, publish them in the DNSKEY rrset, and sign the zone with
> them.


No, the RRSIGs for the algorithm need to be published in the zone *before*
the keys, at least for the value of the largest TTL in the zone, plus
propagation time.  This is because you don't want a resolver to find a set
of DNSKEYs and have to try to validate an RRset with only a subset of the
algorithms found in those keys.


> Then wait one TTL cycle before updating the DS records in the
> parent.
>

> removing an algorithm - you need to remove the old algorithm DS records
> from the parent, then wait one TTL cycle before removing the old KSK and
> ZSKs using that algorithm, and resigning the zone using only the new
> algorithm.
>
>
>
> Also, based on https://tools.ietf.org/html/rfc6781#page-31, it seems we
> need to be able to sign the zone with a key that is not published in the
> DNSKEY rrset. Consider the case of adding a ZSK with the new algorithm,
> where we publish that ZSK in the DNSKEY rrset and resign the zone using
> both old and new ZSKs. A resolver might have an old cached MX rrset only
> signed with the old algorithm; and then retrieve the new DNSKEY rrset
> which mentions both algorithms.
>
> RFC6781 implies that this will break validation. Is that correct?


Yes, in certain cases.  Validators with strict validation policies or
validators that understand one algorithm but not the other will fail to
validate the RRset.

Casey
___
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

Re: dnskey algorithm update

[Jay Ford]

On Wed, 6 Jan 2016, Carl Byington wrote:

My zones are currently using algorithm 5 (RSASHA1), with two KSKs and
two ZSKs with overlapping timers. In preparation for updating to
algorithm 8 (RSASHA256), I read:

 The bind-users thread "KSK signing all records; NSEC3 algorithm
status?"
 https://tools.ietf.org/html/rfc6781#page-31
 https://labs.ripe.net/Members/anandb/dnssec-algorithm-roll-over

Is there a more authoritative document that describes the algorithm roll
over procedure? It seems that I need to:

 generate new ZSK and KSKs using algorithm 8
 sign the zone with all the keys
 wait one ttl cycle, then publish a new dnskey rrset
 wait one ttl cycle, then upload the new ds rrset
...
 eventually, remove the old KSKs from the dnskey rrset,
   but still use them to sign the zone
 wait one ttl cycle, then resign the zone without the
   old KSKs.


Carl:

When I did that algorithm upgrade, I used something close to this process
(based on the dual-signature method):

   # generate new RSASHA256 ZSK & KSK (active & published)
   dnssec-keygen -K Keys.dnssec -a RSASHA256 -b 1024 -n ZONE $ZONE
   dnssec-keygen -K Keys.dnssec -a RSASHA256 -b 4096 -n ZONE -f KSK $ZONE

   # re-sign the zone, using smart signing to pick up all keys
   dnssec-signzone -K $KEY_DIR -d $KEY_DIR -S -o $ZONE $DIR/$ZONE

   # re-load the zone (add any other required rndc args)
   rndc reload $ZONE

   # add DS record(s) for new KSK in parent zone;
   # left as an exercise for the reader

   # wait at least 1 TTL cycle (minimum of that for $ZONE & that for the
   # DS records in the parent zone) to let new DNSKEY, RRSIG, & DS records
   # propagate

   # move old keys out of key dir so they don't get used
   mv $KEY_DIR/K$ZONE.+005+* $TMP_DIR

   # re-sign the zone (with just new keys)
   dnssec-signzone -K $KEY_DIR -d $KEY_DIR -S -o $ZONE $DIR/$ZONE

   # re-load the zone (add any other required rndc args)
   rndc reload $ZONE

   # delete DS record(s) for old KSK in parent zone;
   # left as an exercise for the reader

   # if all good, delete old keys
   rm $TMP_DIR/K$ZONE.+005+*

where:
   $ZONE is the zone being upgraded
   $KEY_DIR contains the key files
   $DIR contains the zone files
   $TMP_DIR contains old keys temporarily

You can get by with activating the new (RRSIG,DNSKEY,DS) set as a group
immediately after creation & re-signing because the old set is still present
as the basis for validation while the new set propagates around.

Likewise, after the TTL cycle you can delete the old (RRSIG,DNSKEY,DS) set as
a group because by then the new set is present as the basis for validation.

It worked for me.  As always, your experience might vary.

I recommend working through this for a zone which:
   o  doesn't matter
   o  has the parent under your direct control

These tools are extremely useful:
   http://dnsviz.net/
   http://dnssec-debugger.verisignlabs.com/

Use them to view & verify things at each stage.  To really have some fun,
purposefully break some part of your test zone & see how the above tools show
it.


Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-f...@uiowa.edu, phone: 319-335-
___
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