On Mon, 5 Nov 2018 at 10:23, Chris Thompson <cet1@cam.ac.uk> wrote:
On Oct 30 2018, Matthew Pounsett wrote:
On Mon, 29 Oct 2018 at 12:21, Paul Hoffman <paul.hoffman@icann.org> wrote:
On Oct 29, 2018, at 9:08 AM, Chris Thompson <cet1@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).