[ksk-rollover] followup of DNSSEC Workshop at ICANN64

[Shane Kerr]

Ondrej,

On 14/03/2019 14.57, Ondrej Filip wrote:
> On 14. 03. 19 12:01, Warren Kumari wrote:
>>
>>
>> So, my original "gut feel" was approximately every year, and I still
>> feel that that is roughly the right frequency -- but, I think that we
>> first need to figure out what the cause of the increase in DNSKEY
>> lookups is - it concerns me that we predicted no impact from the
>> revocation, and we got... this. I think that, assuming we figure out
>> the causes of the increase (and understand them well enough that we
>> are fairly sure that they won't jump again!), my gut still says ~1year
>> -- but, more research needed...
> 
> As a producer of a DNS validating CPE device/router, I must say, I am
> not very excited about frequent roll-overs. If your device stays at a
> retailer store for some time, you might be in a trouble. So I would
> prefer some longer periods. But it is more important how much in
> advance is the new key known/published.

As far as I know, patching is still the only solution we have to 
securing software on the Internet. That means there must be some way to 
get software updates to the device.

A device can detect a mismatch between the root KSK that it has and the 
one at the root servers. In that case, it can disable the root trust 
anchor until it updates the KSK, in whatever way it thinks is reliable 
enough - probably by updating the package that configured the KSK.

My own suggestion would be to include a trust anchor for a zone that 
serves updated software, since that would minimize the risk of being 
sent to bogus servers looking for updates. This trust anchor can live 
forever if you want, because of the awesome decision that DNSKEY records 
have no lifetime. 😉 Presumably any software update mechanism has its 
own signatures as well, so the chances of actually getting invalid 
updates seems minimal.

There is already a need to disable DNSSEC at certain times, for example 
before a device has synchronized its clock, so fiddling with trust 
anchors is probably something that the device has to do anyway.

Maybe someone already has BCP in this area written down? If not, maybe 
it should be?

Cheers,

--
Shane