Dave Knight and I once wrote down some thoughts about the process of
bootstrapping a cold validator onto the network. The draft apparently
didn't seem very interesting to anybody else and wasn't picked up by the
working group, but I think the potential for circular dependencies is worth
documenting.
I'm interested but I have limited spare energy 
Our approach was to specify that validation should be disabled following
boot until an accurate sense of time was acquired, which is what many
people in this thread have suggested.
I think it's better to assume validation will work and only disable it if
the assumption turns out to be wrong. (Computers without RTCs might prefer
to be less optimistic!)
draft-jabley-dnsop-validator-bootstrap-00
I wonder if it's worth having separate recovery processes for getting the
time and getting the trust anchors. If they are separated then you can use
cutting edge cleverness like roughtime, and in most cases you will have
the right trust anchor but not the right time. On the other hand, a
single process is simpler, and if you are getting the trust anchor then
you'll usually get good-enough time for free from the HTTP Date: header
My pet idea for solving the bootstrap problem is:
* Your device is shipped with a list of trust anchor servers, identified
by URL and TLS SPKI pin, and a quorum size which is less than the
length of the list.
The URL could have an IP address in the host part, so bootstrapping
doesn't depend on the DNS, but that might make trust anchor servers
too difficult from the ops point of view. On the other hand
authoritative TLD name servers have very stable IP addresses so it is
possible...
The servers should be diverse in terms of operators, locations, etc.
The size of the quorum allows you to trade off availability and
security.
* If DNSSEC doesn't work at boot time, your device runs a bootstrap
process, as follows:
* Shuffle the list of trust anchor servers
* Make an https request to each one, authenticating the server using the
SPKI pin but ignoring certificate validity times. The response
includes the time and the current root trust anchor.
* Keep going until you get matching responses from a quorum of servers.
You can make requests concurrently so it's reasonably fast. When
comparing the time (actually, compare the offset from the local clock,
because the requests don't happen at the same time), you should allow
for some amount of drift, e.g. tuned to match your NTP client's
maximum offset.
This process avoids two problems with the validator-bootstrap draft, or
rather with the trust anchor publication draft which it refers to.
(1) It sets up data.iana.org to be a huge single point of failure.
(2) The process for validating the responses from data.iana.org just moves
the trust anchor from the DNS to x.509/pgp/smime. Whereas the DNSSEC trust
anchor has extremely trustworthy and visible processes, the data.iana.org
certificates are a complete mystery, and after the rollover they are
mostly broken.
I know that SPKI pins are now deprecated for web sites, because they are
too brittle. But they are just right for this protocol: the SPKI pin
(subject public key information, i.e. a hash of the server's certificate
public key) authenticates the trust anchor server directly to the device
without relying on a third party.
We aren't just moving trust around, instead we are dispersing it. We don't
trust any individual server (if the quorum is greater than 1), instead we
establish trust from several diverse servers agreeing with each other.
Servers can fail, drop out, etc. and bootstrapping still works. The trust
anchor server list gets updated by the usual OS patching process, but it
should be stable enough that it can still work if it is years out of date:
more like DNS root zone hints than the DNSSEC root trust anchor.
We could add a transparency system that monitors public trust anchor
servers for good behaviour, so that they are trustworthy as well as
trusted.
Tony.