On 9/21/2018 11:34 AM, Ray Bellis wrote:
What about the (hypothetical?) home CPE with a validating resolver that's been left on the shelf for a couple of years.
RFC 5011 doesn't help those. AFAIK, re-bootstrapping trust for those is still an unsolved problem.
I wish people would stop repeating this stupid canard. It's almost as stupid as "IOT devices need less security". Yes, there is no "standard" way of resolving this. However, it's pretty much solved. The first thing a CPE router should do upon awakening is check the time to find out how long its been asleep (e.g. NVRAM time stamp the last boot), then try and download an updated firmware version from the CPE manufacturer's servers with more recent trust anchors. The "its been on the shelf for years and it should just work" is a pretty much stupid model. Security rots bit by bit over time until at some point you need to get a human involved. I can't even plug in a TV these days without doing a bit of configuration - why wouldn't I have to configure (or at least push the button to auto-configure) this trust anchor update? Firmware signing keys are both problematic and time-limited. Problematic because you mostly have no way of reliably and securely updating the deployed devices (exceptions exist, but the cost/benefit for CPE is lacking) firmware public key. Time-limited because IT devices have a 3-7 year lifecycle - including especially home CPE routers, cable modems and WiFi installations. I mention this because while the problem is a DNSOP problem, it is not a DNSEXT problem. E.g. there's no protocol in the world that will fix this perceived problem. But guidance to the CPE vendors that they need to provide firmware updates for at least N years after manufacture and that those firmware updates may include new root public keys seems like a good document to write. Later, Mike