[RZERC] RZERC advice to the Board on KSK rollover

[Howard Eland]

> On Jun 24, 2018, at 9:49 PM, Russ Mundy <mundy at tislabs.com> wrote:
> 
> 
> 
>> On Jun 23, 2018, at 6:32 AM, Jim Reid <jim at rfc1035.com> wrote:
>> 
>> 
>> 
>>> On 19 Jun 2018, at 19:11, Russ Mundy <mundy at tislabs.com> wrote:
>>> 
>>> Since changing the root KSK may impact DNS users doing DNSSEC validation, I see the question from the Board is very much within the scope of our charter.
>> 
>> Sorry Russ, I’m still not convinced. We can throw rotting fruit at each other on Monday. :-)
> 
> Well, I hope that we can agree that we should try to have any rotting fruit be sweet :-))

I’d prefer fermented fruit myself…

> 
>> 
>> IMO the rollover isn’t a major change to the root (or shouldn’t be) and is therefore out of scope for RZERC. This should be a routine change, just like tweaking the NS records and glue for a delegation or renumbering a root server. RZERC wouldn’t get involved in these matters. I think a KSK rollover would be in scope for us if it meant adding a new RRtype or a change of crypto algorithm or the newly signed responses had the potential to cause more fragmentation issues. A “routine” rollover -- albeit that the upcoming one will be the very first -- doesn’t pass that threshold. YMMV.
>> 
>> I suppose this comes down to how we or others see RZERC’s role wrt root zone content. Or what is meant by root zone content.
> 
> I don’t see this as a simple change of root zone content that’s been done lots of times before since a KSK change has never been done before in the root zone since it was DNSSEC signed.  In my view, the KSK roll very much an operational risk to the security & stability of the root zone that is clearly a part of the RZERC charter, i.e., the first paragraph of section III of Scope of Responsibilities directly states that risks to the operation of the root zone are part of RZERC’s responsibilities.
> 

I’m in the Russ camp here.  While I agree that a key roll is operational, I’d like to consider the following:

	1) It’s the first time it’s been done in the root zone, so it is far from routine.
	2) It is unique because of the TA load requirement.
	3) We could argue that *anything* is operational, because, well, someone has to perform an operation to make any change, so I consider that to not be valid argument.

>> 
>> 
>> If we provide a substantive response to the Board request -- BTW please note I agree RZERC has to reply -- that will almost certainly mean we get asked about every future KSK rollover. I think that would stray too far into operational details which are even more out of scope for RZERC.
> 
> I think that it is a good thing that the Board will ask for RZERC’s views on future KSK rollovers.  At some point, RZERC might decide that the KSK rollovers are “routine” (for some value of “routine”) and respond that to the Board with such an answer - I also don't see that getting such a question from the Board every 5-8 years should be a problem for RZERC.

Once a key roll *has* become routine, RZERC’s response may become more terse.

-Howard

> 
>> 
>> To an extent, I’m playing devil’s advocate here in the hope of getting clarity and consensus on our role and the nature of the advice we’re expected to offer about this matter.
> 
> 
> Since some sort of problem or failure with the KSK rollover can have a direct, detrimental impact on the operational use of the root zone and the DNS as a whole, which can include the total loss of all DNS resolution (having DNS totally fail for some users is certainly an operational stability problem).
> 
> For at least these reasons, I believe that RZERC is obligated to respond to the Board with some definitive statement about whether or not the rollover plan should be resumed.
> 
> Russ
> 
> 
> 
> _______________________________________________
> RZERC mailing list
> RZERC at icann.org
> https://mm.icann.org/mailman/listinfo/rzerc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/rzerc/attachments/20180625/7a5cb705/signature.asc>