[ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover
Marc Blanchet
marc.blanchet at viagenie.ca
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
More information about the ksk-rollover
mailing list