btw this is not in any sense a novel problem. Anyone who owns a Dell, and uses iDrac will be familiar with the "your certificate chain to this console java app is expired" problem. It can be fixed, but it requires effort.
And alongside the crypto age-out problem, the dependency on java is increasingly a problem: browser-embedded java no longer runs in Chrome due to deprecation of the NAPI model, so you may well find you cannot run the signed code blob for reasons un-related to the crypto, after 10 years. I welcome people designing models to try and deal with age-of-system, but making this make-or-break for DNSSEC keyroll at the apex is I think, stepping too far. Given what has been said about out-of-band repositories of the longer-term keystate, you should be able to construct trust in the aged key transition to the new key and move on with your life. I am more worried that inside 10 years, trust in the private key may become false. What do you propose doing, if your sealed unit box comes up with what in the future is morally MD5 password with no salt and the value 'calvin' ? -G On Thu, Nov 17, 2016 at 10:00 AM, Paul Wouters <p...@nohats.ca> wrote: > > On Nov 16, 2016, at 22:38, Philip Homburg <pch-dnso...@u-1.phicoh.com> wrote: > >>> Did you see my original response? Proposals for automatic DNSSEC trust >>> anchor updating *do* exist. >> >> Is there any document that deals with the situation where a device has >> been in a box for 10 years and then has to bootstrap automatically? >> >> I'm not aware of any. But maybe there is. >> >> Note that by and large such a device has no idea about time. NTP is not >> secure. Any key material stored on the box is no longer valid. >> >> If the answer to DNSSEC bootstrapping is use TLS, then there is still the >> question what about time, is the certificate that was stored on the box >> 10 years ago still usable. >> >> Are there resolvers (and libraries like getdns) that can transition from >> not having any trust anchors to full DNSSEC validation. Do other parts of >> the same system see either DNSSEC failures or answers that were not >> validated. > > It is a fundamental problem. For short periods (eg up to 10 years) it is > possible to disable dnssec, fetch the icann key bundle that is signed with a > long term key you have on the device. Grab and verify the new key and then > re-enable dnssec. > > Of course that still leaves time as an issue. If you trust the icann bundle, > you can get rough time from the rrsig record on the root zone SOA record. > > And this all also assumes the icann key bundle hasn't been compromised or > blocked or is being replayed from 10 years ago. Doing multiple scattered > queries that validate to the root might help give you some assurance > (especially from an online signing site like cloudfare using randomized > queries) > > A more vendor like approach is to disable dnssec and fetch software updates, > using the buildin vendor public key. Most concerns from above apply here too. > > Paul > > _______________________________________________ > 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
