[ksk-rollover] [Ext] Re: Starting discussion on acceptable criteria for proceeding with the root KSK roll
Michael StJohns
msj at nthpermutation.com
Thu Jan 11 17:30:04 UTC 2018
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
More information about the ksk-rollover
mailing list