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

[Carlos Martinez-Cagnazzo]

Hi David,

On Thu, Jan 4, 2018 at 10:32 PM, David Conrad <david.conrad at icann.org>
wrote:

> Carlos,
>
> On January 4, 2018 at 4:31:18 PM, Carlos Marcelo Martinez Cagnazzo (
> carlosm3011 at gmail.com) wrote:
>
>  The problem is, and Jacques said it much better than me, it’s the
> uncertainty. “Over soon” could be “we will not roll until 2020”, or “we
> will roll once the numbers for ksk2010 fall below X%”
>
> Sorry, I’m a bit confused: are you saying the uncertainty is due to the
> lack of definitive criteria to move forward or that people are not certain
> that we will move forward?
>
IMO, it has to do more with your second point, not knowing what next
quarter's decision will be in terms of the roll. I fear that this sends a
confusing signal to the community. Outside quite a closed circle people
will not know or will not understand that is going on, feeding both the
skeptical camp and not sending a strong enough signal for others to update
their configurations. In an ideal world people would take advantage of
these hiatuses and update their systems, but well, in reality they won't.


> This uncertainty every quarter will, IMO, seriously erode trust in DNSSEC.
>
> TBH, I’m struggling a bit with this assertion. Whose trust is being eroded?
>
What will happen after this first roll? will there be another ? if so,
when? what would happen if an emergency roll was needed ? are we prepared
enough to do one ? These are the kind of questions that pop in peoples
minds. I know, and most people know, you have them all well covered. But
community trust is a subtler value more affected by feeling than reason.

>
>
> Again, just echoing here something already mentioned in this thread,  I
> also believe some amount of collateral damage seems unavoidable if we’re to
> ever roll the key. The question is how much.
>
> And this is precisely the question that we’re trying to get answered. We
> absolutely know we’re going to break some resolver's ability to validate —
> the 8145 reports provide concrete proof. We have no idea what the
> collateral damage will be — we don’t even know how many people behind those
> resolvers will be impacted.
>
> You and others appear to be saying that we should ignore that question
> (which calls into question the point of SAC-063 recommendation 3). I’m
> unsure this would be viewed by the wider community as prudent and I suspect
> it has the potential to more seriously erode the trust in DNSSEC than
> postponing the key roll has.
>
I won't speak for others on this particular point. That was not what I was
saying. My central issue is with uncertainty, not actually so much with
rolling the key today or next quarter. I know you had to make a decision
based on limited data and on a very short time frame. I trust your
instinct, and not rolling last October was probably the wisest call to
make. My point is that I don't feel that scanning ICANN's maililing lists
or press releases each new quarter to see what will be happening each time
is the best way forward.

Quantitative criteria would definitely help, including perhaps publishing
up-to-date data and indicators.

> And no, I’m not a big risk taker, actually shame on me for that.
>
> Err, but you’re saying roll sooner even without data — doesn’t that imply
> taking an unmeasured risk?
>
Well, again I wasn't saying that. I hope I clarified it enough. However,
this last comment brings something else to mi mind. We as a community
seemed to be perfectly fine with rolling the key with no data whatsoever
until around July-August 2017 or so. Did we feel at the time we were taking
an unmeasured risk ?

> Regards,
>
> -drc
>
>
> Best regards,

/Carlos



-- 
--
=========================
Carlos M. Martinez-Cagnazzo
h <http://cagnazzo.name>ttp://cagnazzo.me
=========================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20180105/34d1562d/attachment-0001.html>