[ksk-rollover] followup of DNSSEC Workshop at ICANN64

[Michael Richardson]

Shane Kerr <shane at time-travellers.org> wrote:
    > 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.

Cool.  So I can get DNSSEC turned off on those by breaking the . signatures.
The device will turn off DNSSEC, and I can do whatever it was that DNSSEC
was preventing.

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

This is a reasonable suggestion, but you need to include NS-glue
records/hints as well.   Some update systems (yum comes to mind) have many
many anchors, mirrors, which are discovered from lists and by measurements.
That's a lot of glue.... it might be better to have a single source for a new
trust anchor package, and just update that.

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

No, that's not true.
You don't need to disable DNSSEC, you just need to disable checking the
expiry on the records.  That opens one up to replay attacks, but not
substitution attacks.   OpenWRT's dnsmasq already does this.

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

Given your domain, I guess synchronizing your clock is a regular problem :-)
What happens if you go back to the 1990s?  Do you un-type-roll-over? :-) :-)
And do you have a HOSTS.TXT for even earlier visits?

--
Michael Richardson <mcr+IETF at sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190322/1ffaf177/signature.asc>