[ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover
msj at nthpermutation.com
Fri Sep 21 17:02:06 UTC 2018
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
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.
More information about the ksk-rollover