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

[Warren Kumari]

On Wed, Jan 17, 2018 at 2:39 AM Petr Špaček <petr.spacek at nic.cz> wrote:

> On 17.1.2018 02:19, Paul Hoffman wrote:
> > On Jan 16, 2018, at 12:48 PM, Bob Harold <rharolde at umich.edu> wrote:
> >> As I understand it, draft-huston-kskroll-sentinel could be set up by
> one person.
> >
> > That doesn't match my understanding from the draft or the clarification
> that Warren sent to the DNSOP WG yesterday. It has to be installed and
> configured in resolvers first, and then the test can be run by one person
> who can get folks to hit a web page or download some JavaScript.
> >
> > Warren, do I have that correctly?
>
> I will reply even though I'm not Warren:
> Yes, this is correct, it needs support in every validating resolver.
>
In other words, this mechanism suffers from the very same upgrade
> problem as RFC 8145.
>

Yup, what y'all said -- anyone can setup the test, but it won't generate
useful data until implemented in resolvers. Sentinal will generate much
more useful data (it's measuing what users will experiance, not what
resolvers will experiance), but still needs to be deployed -- I was
somewhat surprised by how quickly RFC8145 will deployed - I guess we need
a: this to be implmented, and then b: some security events to cuase
upgrades :-)

I ment to include the below in my original bloviation:
I think it would be really useful to reach out to the press who published
articles on the keyroll pause (e.g: BleepingComputer, Bloomberg, Modern
Ghana, The Register, ITWorld, etc) - having them be told ahead of time that
ICANN stopped things, got community feedback and is proceeding cautiously
(potentially) changes the narrative completely - and, at least, helps
prevent the bad PR hit to ICANN (this is an ICANN list, after all) and them
feeling blindsided. Converting the potential PR ding into a win would be
nice - and may also reach more people.

W



>
> I've implemented a prototype of draft-huston-kskroll-sentinel for Knot
> Resolver, but later I've realized that whatever we do is largely
> irrelevant when it comes to collecting reliable data for *this* KSK roll.
>
> We should go ahead and implement draft-huston-kskroll-sentinel but I do
> not see it giving us data for KSK-2017 roll.
>
> This is how I arrived to conclusion that KSK-2017 will inevitably
> involve some out-of-band fixes and press coverage, similarly to any
> other security issue these days.
>
> --
> Petr Špaček  @  CZ.NIC
> _______________________________________________
> ksk-rollover mailing list
> ksk-rollover at icann.org
> https://mm.icann.org/mailman/listinfo/ksk-rollover
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20180117/94e11cd7/attachment.html>