[ksk-rollover] When is the KSK rollover complete?

[Matthew Pounsett]

On Mon, 5 Nov 2018 at 10:23, Chris Thompson <cet1 at cam.ac.uk> wrote:

> On Oct 30 2018, Matthew Pounsett wrote:
>
> >On Mon, 29 Oct 2018 at 12:21, Paul Hoffman <paul.hoffman at icann.org>
> wrote:
> >
> >> On Oct 29, 2018, at 9:08 AM, Chris Thompson <cet1 at cam.ac.uk> wrote:
> >> >
> >> > On Oct 29 2018, Paul Hoffman wrote:
> >> >
> >> >> * Y'all did remember that the rollover isn't complete until we revoke
> >> >> KSK-2010 on 11 January 2019, yes?
> >> >
> >> > Or maybe 70 days later (22 March) when the revoked KSK-2010 disappears
> >> > from the root zone?
> >>
> >> Good catch! We know that some software that does DNSSEC validation
> doesn't
> >> implement RFC 5011. The fact that the REVOKE bit is turned on in the
> record
> >> for KSK-2010 in DNSKEY RRset won't mean anything to systems running that
> >> software unless they also update their trust anchor files to only
> include
> >> KSK-2017.
> >>
> >
> >Although anything that doesn't implement 5011 should already be
> >experiencing problems since KSK-2010 is no longer being used to sign
> >anything.  Any of those systems that are not experiencing problems now
> must
> >have had their trust anchor manually updated, and revocation or removal of
> >KSK-2010 should be irrelevant to them.  I would expect the only problems
> to
> >be exposed by revocation or removal of KSK-2010 to be bugs in 5011
> >implementations.
>
> This surely isn't right? Validators using statically configured trust
> anchors (e.g. using "trusted-keys" rather than "managed-keys" in BIND)
> and having both KSK-2010 and KSK-2017 configured as trust anchors will
> go on working just fine. If this wasn't the case, they would not have
> been able to add a trust anchor for KSK-2017 in advance of the rollover.
>

I thought that's what I said. :)   Although I can see now how I may have
assumed too much shared understanding in my first sentence.  It should
probably have read "Anything that doesn't implement 5011 and wasn't
manually updated...".    That is clarified in the very next sentence,
though.

Non-5011 systems that aren't already experiencing problems due to the key
roll must have had their trust anchors updated manually (or by software
update, or some other method).  Revocation and removal of KSK-2010 from the
root zone will (should?) be irrelevant to these systems.  The only case I
can think of where it would be a problem is if, for some reason, an
implementation requires all configured trust anchors to be present in the
zone.  In that pathological case operators would need to take a second
configuration step to remove KSK-2010 from their trust anchor list.

It won't be entirely irrelevant to software that implements 5011 because
they will react to revocation, but it shouldn't have an impact on their
ability to validate using KSK-2017.. unless there are bugs (which is what I
was getting at in the final sentence of that paragraph).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20181107/46dd1729/attachment.html>