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