<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 7, 2016 at 3:00 PM, Carl Byington <span dir="ltr"><<a href="mailto:carl@byington.org" target="_blank">carl@byington.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<span class=""><br>
On Thu, 2016-01-07 at 08:34 -0600, Jeremy C. Reed wrote:<br>
> On Wed, 6 Jan 2016, Carl Byington wrote:<br>
<br>
> > Is there a more authoritative document that describes the algorithm<br>
> > roll over procedure? It seems that I need to:<br>
<br>
> ISC has a DNSSEC Guide. See this section:<br>
<br>
> <a href="http://users.isc.org/~jreed/dnssec-guide/dnssec-guide.html#advanced-" rel="noreferrer" target="_blank">http://users.isc.org/~jreed/dnssec-guide/dnssec-guide.html#advanced-</a><br>
> discussions-DNSKEY-algorithm-rollovers<br>
<br>
> (Also in PDF format at the same directory.)<br>
<br>
> We still have some feedback to integrate into the guide, but if anyone<br>
> would like to participate, also see the GitHub site:<br>
> <a href="https://github.com/isc-projects/isc-dnssec-guide" rel="noreferrer" target="_blank">https://github.com/isc-projects/isc-dnssec-guide</a><br>
<br>
<br>
</span>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-<br>
algorithm-roll-over</a>, where Unbound and Verisign make assumptions about<br>
the DS record set, we need to ensure that:<br>
<br>
adding an algorithm - you need to generate both KSK and ZSKs for the new<br>
algorithm, publish them in the DNSKEY rrset, and sign the zone with<br>
them.</blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Then wait one TTL cycle before updating the DS records in the<br>
parent.<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
removing an algorithm - you need to remove the old algorithm DS records<br>
from the parent, then wait one TTL cycle before removing the old KSK and<br>
ZSKs using that algorithm, and resigning the zone using only the new<br>
algorithm.<br>
<br>
<br>
<br>
Also, based on <a href="https://tools.ietf.org/html/rfc6781#page-31" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc6781#page-31</a>, it seems we<br>
need to be able to sign the zone with a key that is not published in the<br>
DNSKEY rrset. Consider the case of adding a ZSK with the new algorithm,<br>
where we publish that ZSK in the DNSKEY rrset and resign the zone using<br>
both old and new ZSKs. A resolver might have an old cached MX rrset only<br>
signed with the old algorithm; and then retrieve the new DNSKEY rrset<br>
which mentions both algorithms.<br>
<br>
RFC6781 implies that this will break validation. Is that correct?</blockquote><div><br></div><div>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.<br><br></div><div>Casey<br></div></div></div></div>