[ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover

Michael StJohns 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 
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




More information about the ksk-rollover mailing list