[ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover

Fri Sep 21 15:12:39 UTC 2018

On 21 Sep 2018, at 11:05, Eric Osterweil wrote:

> I think the setting of this discussion is missing some key elements: 
> the DNS Root KSK is a global root of trust.  The extent to which we 
> build on that is the extent to which software will need for this key 
> to be well known, knowable, and learnable.  As the frequency of its 
> rollover increases, so too does the probability that software will 
> have out of date keys (especially I the context of hyperlocal roots).  
> If you factor DANE in, that root has even more importance to end-user 
> perception.  I think it needs to be a top priority to ensure that DNS 
> Relying Party (RP) software knows how to maintain the current key, 
> keep up with rollovers, and re-bootstrap when it loses the correct key 
> (a failure mode that software absolutely will experience).  As of now, 
> I don’t think we have more than a few nascent ideas about how to 
> handle this.

right but:
- people are lazy: until there are real events (KSK rollover), they will 
not care or prepare. Therefore, we must have rollover enough frequent so 
people do act.
- there are mechanisms to help/automate rollover, such as RFC5011, which 
shall fit with most use cases.
- for the use cases/reasons people not use RFC5011, then it is like any 
manual configuration management: you take the responsability to put 
whatever process in your org to handle that case, since you are aware 
that you are taking the manual route.

my 2c

Marc.

>
> Just my 0.02,
>
> Eric
>
>> On Sep 18, 2018, at 9:39 AM, Mark Elkins <mje at posix.co.za> wrote:
>>
>> I agree with the sentiment that there should be a "regular" KSK Key
>> roll-over - probably once every five years (though I roll my KSK's 
>> once
>> a year).
>>
>> However, I would agree that it first makes sense for this roll-over 
>> to
>> complete first - along with some research to understand any mishaps.
>>
>> Regarding people reaching out to their own communities - anyone got 
>> an
>> outline of what such a communication would contain? In South Africa, 
>> up
>> to 50% of lookups are via DNSSEC aware recursive resolvers according 
>> to
>> https://stats.labs.apnic.net/dnssec - so this would seem like a worth
>> while exercise.
>>
>>
>>
>> On 09/18/2018 02:46 PM, Lars-Johan Liman wrote:
>>> I agree too.
>>>
>>> I think we should set an "intense" schedule (twice per year? once 
>>> per
>>> year?) _beforehand_, to send the message that "there is no relief 
>>> after
>>> this, there is only more pain ahead ... unless you automate!" to the 
>>> DNS
>>> software community. There must be no way to hardcode the KSK in 
>>> code.
>>> This will continue to be this painful until that message is received 
>>> and
>>> understood.
>>>
>>> 				Cheers,
>>> 				  /Liman
>>>
>>>
>>> kolkman at isoc.org:
>>>> I agree with Michael, albeit I would phrase it slightly 
>>>> differently:
>>>> Rolling the key regularly is a strategic choise and makes a keyroll 
>>>> an operational reality.
>>>> How regular (or how frequent) is a tactic. Whether That is yearly, 
>>>> no
>>>> monthly or once half a decade is a tactic that takes into account 
>>>> some
>>>> of our learnings.
>>>> I would really like to see that strategic position being explicit.
>>>
>>>> Olaf.
>>>> ----
>>>> Composed on mobile device, with clumsy thumbs and unpredictable 
>>>> autocorrect.
>>>> ________________________________
>>>> From: ksk-rollover <ksk-rollover-bounces at icann.org> on behalf of 
>>>> Michael StJohns <msj at nthpermutation.com>
>>>> Sent: Tuesday, September 18, 2018 5:04:31 AM
>>>> To: Matt Larson
>>>> Cc: ksk-rollover at icann.org
>>>> Subject: Re: [ksk-rollover] ICANN board meeting result and the 
>>>> Current status of KSK-Rollover
>>>> On 9/17/2018 3:57 PM, Matt Larson wrote:
>>>>> The answer I've given when people ask this question is that we 
>>>>> need to
>>>>> get through the first rollover and analyze how it goes before we 
>>>>> can
>>>>> discuss subsequent rollovers. One can imagine that how the first
>>>>> rollover goes could have a material effect on the timing of the 
>>>>> next one.
>>>> This seems like a bad approach given how that we currently have 
>>>> interest
>>>> and opportunity in the roll-over that could catalyze planning for a
>>>> second roll.  This does not - and should not - need to be single
>>>> threaded.    AFAICT, you're going to know most everything you need 
>>>> to
>>>> know a few seconds to a few days after you stop signing the the old 
>>>> key.
>>>> So - I suggest you pick a date now.  Start planning for the next 
>>>> roll
>>>> now.  If your post analysis shows a problem - adapt and overcome 
>>>> and
>>>> adjust the dates if you need to.  It's hard to hit a target if you 
>>>> don't
>>>> put it on calendar.
>>>> Later, Mike
>>>
>>>> _______________________________________________
>>>> ksk-rollover mailing list
>>>> ksk-rollover at icann.org
>>>> https://mm.icann.org/mailman/listinfo/ksk-rollover
>>>> _______________________________________________
>>>> ksk-rollover mailing list
>>>> ksk-rollover at icann.org
>>>> https://mm.icann.org/mailman/listinfo/ksk-rollover
>>> _______________________________________________
>>> ksk-rollover mailing list
>>> ksk-rollover at icann.org
>>> https://mm.icann.org/mailman/listinfo/ksk-rollover
>>
>> -- 
>> Mark James ELKINS  -  Posix Systems - (South) Africa
>> mje at posix.co.za       Tel: +27.128070590  Cell: +27.826010496
>> For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
>>
>> _______________________________________________
>> ksk-rollover mailing list
>> ksk-rollover at icann.org
>> https://mm.icann.org/mailman/listinfo/ksk-rollover

> _______________________________________________
> ksk-rollover mailing list
> ksk-rollover at icann.org
> https://mm.icann.org/mailman/listinfo/ksk-rollover