resolution fails when the date of the server is more than 2 days late

[Tony Finch]

Joe Abley via Unbound-users <unbound-users at lists.nlnetlabs.nl> wrote:
>
> 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!)

> https://tools.ietf.org/html/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.

https://tools.ietf.org/html/draft-jabley-dnssec-trust-anchor-01

(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.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Mull of Galloway to Mull of Kintyre including the Firth of Clyde and North
Channel: Northwesterly 3 or 4, occasionally 5 at first, becoming variable
later. Rough at first near Mull of Kintyre, otherwise slight or moderate,
becoming smooth or slight, except in North Channel. Showers then fair,
occasional rain later. Mainly good.