dnskey algorithm update

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

dnskey algorithm update

Carl Byington
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.


For that to work, I need to get dnssec-signzone to sign a zone without
publishing the keys (activate < publish) and (inactivate > delete).

'man dnssec-signzone' under -S smart signing, talks about the following
timers - (publication, activation, revocation, unpublication, deletion).

That man page implies that dnssec-signzone will always publish keys that
it has used to sign the zone. The use of 'unpublication' and lack of
mention of 'inactivate' seems to be an oversight.

'man dnssec-settime' documents the following timers - (P publication, A
activation, R revocation, I retired (inactive?), D deleted)

'dnssec-settime -p all' uses (Created, Publish, Activate, Revoke,
Inactive, Delete) names.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlaNdXsACgkQL6j7milTFsFQ6wCffo9wlY7roi2U3iI/6TSahK7R
6hQAn3HgFbGeJBXsMza6IRAuDLBx2Wr3
=bTLc
-----END PGP SIGNATURE-----


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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: [hidden email], phone: 319-335-5555
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: dnskey algorithm update

Jeremy C. Reed
In reply to this post by Carl Byington
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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: dnskey algorithm update

Carl Byington
-----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. 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? If so,
I don't see any way to get dnssec-signzone to do this using -S smart
signing based on the timers in the K*{key,private} files.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlaOw7sACgkQL6j7milTFsEdRACeLW4vhluKZF9Aq65m/YGbU2Bp
1YEAnjA3ZRJx+4Ykd8g7cc8NHAhP/FY2
=Xesv
-----END PGP SIGNATURE-----


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: dnskey algorithm update

Casey Deccio


On Thu, Jan 7, 2016 at 3:00 PM, Carl Byington <[hidden email]> 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 <a href="https://labs.ripe.net/Members/anandb/dnssec- algorithm-roll-over" rel="noreferrer" target="_blank">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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users