[ksk-rollover] Retention of the 2010 KSK

[Petr Špaček]

On 03. 04. 19 16:09, Joe Abley wrote:
> We want the system as a whole to be simple; we want to minimise the failure points. We also want devices that have been sitting on the shelf for five years to be patched, because validation is really the least of their problems and they're probably about three minutes away from being pwned.

We at CZ.NIC actually ship DNSSEC-validating router (Turris Omnia) so I can describe our perspective:

1. Joe is totally right. Software update has to be very first thing which the device does.

2. Software update has to be secured using other means anyway. In our case we sign packages and package lists using vendor-specific key material and public key is hardcoded in the factory-reset image used by the device.
(2b. The factory reset image can be also updated when the system is up and running!)

3. In our case first boot after factory reset (which can be user-induced at any time) will boot minimal system which has barely enough to connect to a network and to download new version of system.

4. DNSSEC validation is turned on after system update is finished and system rebooted.

This seems to work for us.


Adding DNSSEC-re-bootstrap code would increase complexity for a questionable benefit.

My personal feeling is that it just increases risk that something will go wrong - especially because the vendor does not have control over timing of key rollovers etc. and more moving parts is always increasing risk.


To conclude: I would recommend to destroy the old keys and burn all bridges - there is no incentive for vendors to implement DNSSEC-re-bootstrap code anyway.

-- 
Petr Špaček  @  CZ.NIC