[ksk-rollover] followup of DNSSEC Workshop at ICANN64

[Edward Lewis]

On 3/14/19, 08:58, "ksk-rollover on behalf of Michael Richardson" <ksk-rollover-bounces at icann.org on behalf of mcr+ietf at sandelman.ca> wrote:

>I think it's reasonable that a live boot/install device do RFC5011 to update itself before reaching out to update software, but I don't think that we leave the chain of keys in place long enough for a 3-5 year LTS to be able to catch up.

(I altered the RFC number in the included text assuming Automated Updates is meant.  [...Why I try to refrain from using document numbers as identifiers...] ;) )

>(Why would a paranoid person one use such an old release?  There are a number of reasons I can think about, some of them involving investigation of potential other compromised software tool chains.  Is this enough justification?  Maybe.)

The use case of having a device re-establish a secure state after an extended period of being disconnected is one of those "classic problems."  I've heard this applied to devices in submarines go radio-silent while the keys are rolled.

And, for instance, from 10 years back, "DNSSEC Trust Anchor History Service"
https://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-02

That has resulted in an resource record type reservation but the draft hasn't made it into a RFC document.
https://www.iana.org/assignments/dns-parameters/TALINK/talink-completed-template

There were considerable mail threads around that draft in the IETF.

My suggestion is to measure the incidence of the use-case.  Now would be the time to do so.  The key is rolled, how many re-connected devices will try to catch up?  It isn't clear how to measure this, but it would be good to measure the volume of this use case.  (Who has the data?  What should be measured?  Is there an objective measure of the need?)  Anyone want to take this on?

If the impact is high enough, intent (Michael's use of 'paranoia') doesn't matter.  In the sense that there have been attempts to address this in the past that have not come to fruition, if the impact is seen, we ought to redouble our efforts.  With use cases quantified, the parameters ('3-5 years' from Michael's mail) would be based on what's real, which may precipitate a workable solution.