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

[Michael StJohns]

On 1/9/2018 7:21 PM, Doug Barton wrote:
> On 01/08/2018 11:35 PM, Jakob Schlyter wrote:
>
>> Adding has an emergency rollover key (as described by Mike) has been 
>> considered several times over the years, but has been rejected every 
>> time due to how the primary key is protected and maintained. No 
>> failure scenario has been identified where it wouldn't be possible to 
>> recover from a failure and still maintain public transparency. 
>
> Does that include a scenario where the algorithm used by the current 
> key is unexpectedly broken? (Commonly referred to as alg failure)
>
> Doug 

I'd say maybe based on the fact that alg failures tend to occur over 
time rather than at a discrete point in time.  The current example is 
NSA/NISTs guidance to transition from Suite B to NCAS (Suite B at the 
192 bit strength level basically) pending guidance to transition to a 
Quantum Resistent National Cryptographic Algorithm Suite at some later 
time.   Given that guidance we should already be phasing out 
RSA2048/Sha256... but AFAICT we aren't there yet.  There's also the 
point that algorithm swaps tend to be messy on the client side (because 
they generally need additional crypto implementations) - if you thought 
the arguments about which clients supported 5011 were painful, wait 
until we get to the "which clients/resolvers are 192bit ready?" or 
"which clients/resolvers are EC ready?" discussions.   All that being 
said, we can add a set of stand by keys (up to 4 based on the 5011 
requirements) to cover various algorithms.

To be even more blunt than I normally am, DNSSEC (and DNS) does not lend 
itself to good knowledge about what the consumers of DNS data are doing 
from the view point of the providers of that data.  All the root folks 
can do is a) make a schedule, b) warn everyone a lot, c) keep to the 
schedule, d) repeat a-c annually or on some regular period so we don't 
forget how to do it.

We (this list collectively mostly ) believe DNSSEC is a benefit to the 
end-user.  The root should provide its service in a professional and 
regular manner.  If the resolvers break, they break,  and the people 
running the resolvers can decide if DNSSEC is of benefit to their users 
or they want to turn it off because its too much pain for too little 
gain.  If the Root has followed its schedule and publicity program, has 
waited now some odd months for some of the resolvers to fix themselves, 
while I can see complaints from the resolver folk, I can see no 
liability.   Having the root rollover held hostage to a group of 
resolvers that don't see enough benefit to DNSSEC to pay attention to 
DNSSEC operations seems to me to be a losing strategy.

Later, Mike