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

Marc Blanchet marc.blanchet at viagenie.ca
Fri Sep 21 17:10:16 UTC 2018



On 21 Sep 2018, at 13:02, Michael StJohns wrote:

> 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.
>

you are right, but what we can see in the field is not that. firmwares 
are rarely updated (on purpose, so you instead by a new CPE… and send 
them more money, they like it…).

Marc.

> Later, Mike
>
>
> _______________________________________________
> ksk-rollover mailing list
> ksk-rollover at icann.org
> https://mm.icann.org/mailman/listinfo/ksk-rollover


More information about the ksk-rollover mailing list