[ntp:questions] Re: handling of falsetickers withdumb NTP clients

David L. Mills mills at UDel.Edu
Mon Sep 15 03:09:34 UTC 2003


Brad,

Stripped to essentials, the DNS/bind distributed service must conform to
Lamport's "happens before" relation, which results in a partial ordering
of significant events, such as sequency number/timestamp comparisons.
Stand back and look at the entire process from absence of all time
references until DNS is reliably in that relation. First, you have to
manufacture a primal certificate, which requires verified time by some
means or other. That's the Little Time Bang. Then, you have to
distribute verfied time to at least the respective neighbors so they can
verify identity and time. This is what the Autokey protocol does. Only
when a neighbor in the same security group has "synchronized to a
proventic source" can that neighbor manufacture and sign certificates
and verify identity with its group neighbors. And so it goes.

There is a great deal of discussion on these issues in the Autokey
Version 2 proto-RFC at www.eecis.udel.edu/~mills/reports.html and on the
NTP project page. You get nasty brainfizz when trying to prove
dependencies between timestamps, filestamps and comparisons. Good thing
is that you are thinking about the issues; not many folks are. I think
they are generic to many more distributed applications than DNS/bind.

Dave

Brad Knowles wrote:
> 
> At 2:07 AM +0000 2003/09/12, David L. Mills wrote:
> 
> >                                         In other painful words, time and
> >  security are inseparable in themselves, but must be separable from name
> >  resolution. The purist cannot turn up bind unless NTP has synchronized
> >  the clock.
> 
>         BIND (and name resolution in general) only needs an accurate
> value for time if you're using DNSSEC.  Otherwise, coarse relative
> values (within a second or so, monotonically increasing) are
> sufficient.  And even that's only necessary for servers that are
> acting as caching/recursive resolvers -- authoritative-only servers
> only need to compare the SOA serial number as a generic 32-bit
> quantity and see whether or not A is greater than B.
> 
>         In the case of NTP, we are fortunate that we can bootstrap this
> process by providing IP addresses in the ntp.conf file, which allows
> us to start up before name resolution is working.
> 
>         However, we should probably give some thought as to a two-phase
> startup process whereby we might delay trying to sync with servers
> that are specified by name, until such time as name resolution is
> working, while proceeding with time sync with servers that are
> specified by IP address.
> 
>         Once name resolution is working again, we could then restart the
> early parts of the sync process with the servers that are now
> presumably available, if that was deemed to be necessary or useful.
> 
> --
> Brad Knowles, <brad.knowles at skynet.be>
> 
> "They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety."
>      -Benjamin Franklin, Historical Review of Pennsylvania.
> 
> GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
> !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
> tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)



More information about the questions mailing list