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

Reply via email to