On Nov 16, 2016, at 22:38, Philip Homburg <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/dnsop
