dnskey algorithm update

[Casey Deccio]

On Thu, Jan 7, 2016 at 3:00 PM, Carl Byington <carl at byington.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160108/b78758d5/attachment.html>