I echo what Ted said. If its 'not well known' its a property of the RFC ecology in general, that things we did know, and did document, wind up buried in the RFC free text search.
>From memory, the specific issue was discussed across at least two rounds of IETF, as a thing. I seem to recall Mike St Johns and others iterating around why we weren't going to be able to design the problem away. (btw, if you buy boxes you cannot hand install trust objects into, I believe you walked into a problem because 5011 is for documented roll. It doesn't preclude uncommanded roll which can exist eg if the california earthquake hits, and all the witnesses die on the west coast so the east coast HSM is toast and nobody can unlock it so we replace cold with no sign-over and no signalling opportunity) IETF documented memory is hard to find. That's true. Things people in WG know are not widely understood, that's also true. But collectively, we "do" know this. -G On Wed, Nov 16, 2016 at 5:54 PM, Ted Lemon <mel...@fugue.com> wrote: > 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
