Why would you put a device on the shelf for ten years? Is this a real scenario? This is certainly a known issue that has been talked about at length--the conclusion when it was discussed is that there is nothing we can do about it, and it's relatively unlikely, and manually fixable.
On Wed, Nov 16, 2016 at 5:46 PM, Mikael Abrahamsson <swm...@swm.pp.se> wrote: > > Hi, > > today I have discovered something after talking to some people that know > more than I do. > > Example: > > I go to the store and buy two DNSSEC enabled devices that rely on DNSSEC > working for them to work. > > I put one device on the network immediately and the other one on the shelf. > The one I plugged in works just fine for 10 years because it has RFC5011 > support. > > Now after 10 years after plugging the first one in, I take the second one > off the shelf and plug it in. It will now not work because there has been a > root zone key rollover. I am told this is by design. This makes me a sad > panda. > > We have a bootstrapping problem. My device has no way to know what time it > is so it can't verify certificates that might be used to update the key > material, and by above design decision, DNSSEC doesn't work. > > I had some idea that DNSSEC could be used to sign a distribution of > roughtime (have someone sign a DATE+TIME TXT record so I at least know > approximately what day and time of day it is), so I could verify > certificates and then bootstrap myself that way. > > I believe that this property of DNSSEC (put on shelf, take from shelf in 10 > years, device now not working properly) is not well known in the wider IETF > community. Is this documented somewhere in plain text that everybody will > understand? > > What's the current thinking of what a user should do with a device that has > only old root zone key material? Is there any guidance to vendors on what > they should instruct users to do in order to make their device work again? > > -- > Mikael Abrahamsson email: swm...@swm.pp.se > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
