[ksk-rollover] Starting discussion on acceptable criteria for proceeding with the root KSK roll

[David Conrad]

Jacques,

Thanks very much for kicking this discussion off.

On January 4, 2018 at 8:39:35 AM, Jacques Latour (jacques.latour at cira.ca<mailto:jacques.latour at cira.ca>) wrote:
I'll go first, we need to take in account the human behaviour, and not being an expert human behavioral analyst, I know that people fix things when broken and not when it's working. So getting a 100% of people's attention to fix something not broken is almost impossible.

Agreed.

When we talk to ISP about this issue, the smaller ones just turn DNSSEC validation off because it's easier.

Not just the smaller ones. I’ve been told one of the largest ISPs in the world turned off DNSSEC until after the KSK rollover.

It's impossible to have 100% readiness.

Agreed. The question we are trying to answer is that given this, and given we now have objective data that strongly suggests there are folks who are NOT ready, what is the criteria by which we move ahead?

The majority of DNSSEC validation today is via google DNS.

I suspect this is the case, but I think Comcast also provides a good chunk of validation.  It’d be interesting to find out exactly what the reality is and that’s part of the problem: the criteria defined by the KSK Rollover Design Team measures something for which we don’t (currently) have objective data (namely, 0.5% of end users negatively impacted).

I think we need to go ahead with the roll over, have the humans fix the problems as they arise, and start re-building the trust in DNSSEC globally! (before it's too late!)

There is a bit to unpack here and I’m left with more questions:

1) “we need to go ahead with the roll over”

Just to level set and argue the extreme, if we had data that suggested that 100% of validating resolvers would fail, would you personally pull the trigger that causes the KSK rollover?

The implication of your statement is that regardless of the state of knowledge about whether the rollover would succeed or the damage that it would cause, we should roll the key. This would appear to contradict SAC063 recommendation #3. As you are on SSAC, perhaps you could encourage them to weigh in on this topic?

2) "have the humans fix the problems as they arise”

This (presumably) assumes humans will fix the problems in a positive way. I’ll admit I suspect the more likely way of fixing DNSSEC rollover-caused validation failures will be to simply disable DNSSEC validation (after all, the folks who would fix things the right way are unlikely to be bit by the rollover). Is that an acceptable outcome?

3) “start re-building the trust in DNSSEC globally!"

I am personally unaware that of any noticeable change in the trust associated with DNSSEC as a result of the (lack of) KSK rollover. Within security knowledgeable folks, I do know that trust in DNSSEC has been _increased_ a bit by the move by Verisign from a 1024 bit ZSK to a 2048 bit ZSK, but that’s obviously unrelated to the KSK rollover. What data do you have that trust has decreased due to the lack of KSK rollover?

4) "(before it's too late!)”

My impression has been that the percentage of responses being validated has been increasing over time, and not just because more and more folks have been using Google Public DNS — I’ve heard anecdotally that more folks on turning on validation (perhaps as a side effect of the KSK rollover communications plan). You’re suggesting that the lack of KSK rollover will result in a crisis of trust in DNSSEC. How long do you think it will be until this occurs? It has already happened? Days? Weeks? Months? Years?

Thanks,

-drc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20180104/158ae636/attachment-0001.html>