Re: How to set time.

[Scott Bennett <bennett@xxxxxxxxxx>]

     On Thu, 23 Jul 2009 17:32:27 -0400 Niels Elgaard Larsen <elgaard@xxxxxxx>
wrote:
>Watson Ladd wrote:
>> Niels Elgaard Larsen wrote:
>
>>> On the other hand it would work better for eg. TOR browser bundle.
>> It would enable an entry guard to give a different time to a client, and
>>  so distinguish that client's connections to sites of interest via
>> protocols that use a timestamp sent in the clear.
>
>Yes, that was why i suggested only using it to set the time zone by 
>changing the clock a number of hours.

     I don't think that would be good enough to satisfy tor's requirements
for time consistency.
>
>Using an average of three entry-nodes could also work. Maybe add a 
>little random time.

     Actually, no, three would not be enough, but statistical quality
control of some sort would be necessary.  First off, this kind of thing
should be a last resort option, not a common approach.  Second, choosing
a random sample size within a certain range would help.  Maybe limiting
the contacts to guards in this case should be dropped, allowing a much
larger set of relays to be queried for the correct time.  Then computing
the mean and standard deviation would allow the client to disregard any
outlier timestamps that might represent an attack, based upon some set
limit, say, 1/4 sigma, but that the entire sample set would be discarded
if the variance were too large relative to the mean and a new sample set
constructed.  Also, it should be obvious that the data collection could
not be done over DirPort connections.
     Another irritating problem is that a tunneled connection probably
would entail delays too lengthy to use for setting a time, so an observer
seeing a set of direct connections during startup numbering in the range
of acceptable sample sizes could make a shrewd guess as to whether the
client were determining the correct time or were building tunneled
connections for fetching consensus and directory updates.
>
>Because what is the alternatives for setting time?
>
>GPS or DCF77 would be good, but requires hardware.

     Right.  Those are no good in this situation.
>
>Having users setting it from other sources would work, but not is very 
>user friendly. Especially on a live-cd where we do not even know the 
>local timezone, we would have to let the user also input the timezone or 
>  ask what time it is in London now.

     Yup.  A discouragingly large fraction of the user population would
probably not understand how to set the time, even if told. :-<
>
>NTP is an option, but if used without authentification it also opens up 
>for the attack you described. For an organization or a country 
>controlling an entire network it would be easy to change timestamps in 
>flight. NTP is even worse because you could change the clock many times 
>during a session. And which NTP-servers with authentification would you use?
>
     Exactly.  Also, NTP is not encrypted, so an observer would know the
set of time values from which one value would be used by the client.
     Lest another point be forgotten, the methods of determining the correct
time that we are discussing here would only be available in the case of
client operations.  tor should still not set a clock or offset itself if
it is to run as a relay.


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:       bennett at cs.niu.edu                              *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************