Revoking KSK-2010 imminent
With the revoking of KSK-2010 in the root DNSKEY RRset due in 5 days time, is no one at all nervous about possible consequences? A couple of more specific question: 1. This has been asked before, but is anyone analysing the RFC 8145 data to see how many servers are reporting that they only trust KSK-2017, and are they in a position to track how this changes during the revoking process? The graphs at http://root-trust-anchor-reports.research.icann.org/ are described in terms of servers trusting only KSK-2010 vs. all others. 2. In the unlikely event that publishing a revoked KSK-2010 causes significant problems (e.g. the new high water mark for the size of a signed DNSKEY response has been mentioned), do ICANN have a back-off strategy (e.g. to delay the revoking)? -- Chris Thompson Email: cet1@cam.ac.uk
I haven’t been paying attention. Is anything being signed by ksk2010 anymore? If not, then revoking it should be the very definition of a non-event. And you can’t “delay the revoking “ once you’ve published the revoked key. Revocations take place immediately upon receipt. You could delete the revocation from future publications, but I’d guess that if you wait more than 1ttl after first publication such deletion would have little effect on the overall system. Lastly, existing systems should currently be trusting both 2017 and 2010 - unless manually intervened - so why would systems show only 2017 trust? Mike On Sun, Jan 6, 2019 at 12:15 Chris Thompson <cet1@cam.ac.uk> wrote:
With the revoking of KSK-2010 in the root DNSKEY RRset due in 5 days time, is no one at all nervous about possible consequences?
A couple of more specific question:
1. This has been asked before, but is anyone analysing the RFC 8145 data to see how many servers are reporting that they only trust KSK-2017, and are they in a position to track how this changes during the revoking process? The graphs at http://root-trust-anchor-reports.research.icann.org/ are described in terms of servers trusting only KSK-2010 vs. all others.
2. In the unlikely event that publishing a revoked KSK-2010 causes significant problems (e.g. the new high water mark for the size of a signed DNSKEY response has been mentioned), do ICANN have a back-off strategy (e.g. to delay the revoking)?
-- Chris Thompson Email: cet1@cam.ac.uk
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On Jan 6, 2019, at 9:47 AM, StJohns, Michael <msj@nthpermutation.com> wrote:
I haven’t been paying attention. Is anything being signed by ksk2010 anymore?
No.
If not, then revoking it should be the very definition of a non-event.
...assuming that all software has implemented RFC 5011 completely correctly. We are not assuming that, which is why we will be looking for problems after the publication. This will be the first time that root zone will have a record with the revoke bit set in any DNSKEY record. --Paul Hoffman
On Sun, Jan 6, 2019 at 13:04 Paul Hoffman <paul.hoffman@icann.org> wrote:
On Jan 6, 2019, at 9:47 AM, StJohns, Michael <msj@nthpermutation.com> wrote:
I haven’t been paying attention. Is anything being signed by ksk2010
anymore?
No.
If not, then revoking it should be the very definition of a non-event.
...assuming that all software has implemented RFC 5011 completely correctly. We are not assuming that, which is why we will be looking for problems after the publication. This will be the first time that root zone will have a record with the revoke bit set in any DNSKEY record.
--Paul Hoffman
So you’re telling me that no one got copies of all of the various resolvers and tried to feed them a revoked key of any sort? Strange. Mike
On Jan 6, 2019, at 10:11 AM, StJohns, Michael <msj@nthpermutation.com> wrote:
So you’re telling me that no one got copies of all of the various resolvers and tried to feed them a revoked key of any sort?
Nope, I'm not telling you that at all. We (and others) did do that. We could not do it all possible configurations of software, and we know that configurations count, so we are being careful.
Strange.
Not really. Given how our predictions for what would happen on October 11 were so off, the DNS community is now confident that we cannot be confident just based on testing in labs. --Paul Hoffman
Mike, On Jan 6, 2019, at 10:11 AM, StJohns, Michael <msj@nthpermutation.com> wrote:
So you’re telling me that no one got copies of all of the various resolvers and tried to feed them a revoked key of any sort?
Could you point me to the exhaustive universal catalog of all resolvers used on the Internet? Thanks, -drc
As far as I understand the situation there is one small risk factor - the revoked key will inflate the size of the response to a root zone DNSKEY query to 1449 octets (as I recall). The combination of the possibility of fragmentation and some root servers performing response truncation implies a small risk of some DNSSEC-validating resolvers being unable to retrieve the root zone DNSKEY RR and going ‘dark’. However, this seems like a pretty small risk - other zones, such as .org, use a far larger response, and if a validating resolver is going to get caught out on being unable to receive large responses then it already has problems with .org names! Geoff
On Jan 6, 2019, at 17:49, Geoff Huston <gih@apnic.net> wrote:
As far as I understand the situation there is one small risk factor - the revoked key will inflate the size of the response to a root zone DNSKEY query to 1449 octets (as I recall). The combination of the possibility of fragmentation and some root servers performing response truncation implies a small risk of some DNSSEC-validating resolvers being unable to retrieve the root zone DNSKEY RR and going ‘dark’.
However, this seems like a pretty small risk - other zones, such as .org, use a far larger response, and if a validating resolver is going to get caught out on being unable to receive large responses then it already has problems with .org names!
Also, if it turns out to be an actual problem, the dnskey RRset without the revoked key can be restored quickly. The only bad effect would be that not all RFC 5011 compliant revolvers remove the old no longer used key from their trust set. And all copies of that key can/should be destroyed soon anyway :) Paul
On 1/6/2019 5:24 PM, David Conrad wrote:
Mike,
On Jan 6, 2019, at 10:11 AM, StJohns, Michael <msj@nthpermutation.com> wrote:
So you’re telling me that no one got copies of all of the various resolvers and tried to feed them a revoked key of any sort? Could you point me to the exhaustive universal catalog of all resolvers used on the Internet?
Thanks, -drc
So you're saying that ICANN didn't make one of those during trying to figure out how to do the rollover and revisit it when you delayed the rollover? Seriously though - "all the various resolvers" is a pretty small set and I seem to remember a pretty exhaustive fingerprinting effort some 5-6 years ago that had a pretty good identification of not only the base server types (e.g. bind, nominum, etc), but the various release branches. In any event, the answer to my first question appears to be "we managed to get most of the base servers, but your mileage may vary because they're sensitive to configuration". That's fine. Later, Mike
On 6 Jan 2019, at 9:14, Chris Thompson wrote:
With the revoking of KSK-2010 in the root DNSKEY RRset due in 5 days time, is no one at all nervous about possible consequences?
A couple of more specific question:
1. This has been asked before, but is anyone analysing the RFC 8145 data to see how many servers are reporting that they only trust KSK-2017, and are they in a position to track how this changes during the revoking process? The graphs at http://root-trust-anchor-reports.research.icann.org/ are described in terms of servers trusting only KSK-2010 vs. all others.
2. In the unlikely event that publishing a revoked KSK-2010 causes significant problems (e.g. the new high water mark for the size of a signed DNSKEY response has been mentioned), do ICANN have a back-off strategy (e.g. to delay the revoking)?
ICANN cannot "delay" the revoking once it has started because some validating resolvers will have already seen the DNSKEY RRset that has the revoke bit for KSK-2010 turned on. However, if there are significant problems, there is a fallback DNSKEY RRset that is the same as the one that will be published but without the revoke bit set. ICANN (and many others) will be monitoring for signs of significant problems for the 48 hours after the new DNSKEY RRset is published. --Paul Hoffman
Related to this thread, ICANN published my blog post this morning: https://www.icann.org/news/blog/icann-is-revoking-the-old-key-signing-key-th... (To be clear, this publication date for this blog post was set a month ago. I didn't want to foreshadow it in this thread before it was posted.)
participants (7)
-
Chris Thompson -
David Conrad -
Geoff Huston -
Michael StJohns -
Paul Hoffman -
Paul Wouters -
StJohns, Michael