adrelanos:
> Jacob Appelbaum:
>> adrelanos:
>>> Jacob Appelbaum:
>>>> If I were to reinvent the wheel without having read any of tordate's
>>>> source, I would:
>>>>
>>>> open the consensus or the cached-microdescs
>>>> parse the absolute minimum time
>>>> stat the respective file to see the last possible atime/mtime/ctime
>>>> pick the later time of the two
>>>> jump the clock forward again
>>>
>>> What in case the directory authority is not reachable (censored area)?
>>>
>>
>> Well, if we have a file on the disk, we don't even have to touch the
>> network to jump the clock, right?
>
> I must admit I am the over thinking type. Three cases. One appears
> unsolved to me.
>
> 1) there is a file on disk -> no consensus parser required
> 2) there is no file on disk; Tor directory authority available -> parse
> consensus
> 3) there is no file on disk; Tor directory authority is not reachable -> ?
>
> How likely is it that there is no file on disk and that Tor directory
> authority is not reachable? I have no idea, just thought, if it isn't a
> likely use case, you wouldn't think about a consensus parser.
>
I'd add another case:
4) There is a file on disk with a consensus
we see the mtime is newer than the current clock
we jump the clock forward
we parse the consensus, we decide that we should jump the clock again
This may end differently:
we download a new consensus, we decide to jump the clock again
or:
we have fetched a new consensus via some other means
>>> Is the parasitic approach future proof anyway? Won't that cost the
>>> remote server admins cpu load and traffic?
>>
>> Probably and probably not?
>
> I don't know.
>
>>>
>>> What if the remote server admins install some "intelligent" filter,
>>> which blocks Tor? (for other unrelated spam/ddos issues)
>>
>> Which server admins? People offering TLS?
>
> The admins of the servers which tlsdate contacts, i.e. top 100 alexa or
> whatever hosts you may pick.)
>
What will they do? Break the TLS spec and stop offering time? Set their
clocks wrong? Stop serving TLS clients?
>>>
>>> Why trust and get the time of some remote server admins who are not
>>> really willing to run a network time server? They most likely get their
>>> own time over unauthenticated NTP. Getting time from TLS is more a hack
>>> than a replacement for non-existing tcp, authenticated and distributed NTP.
>>>
>>
>> Yeah, I'm aware. Really, well aware. People keep telling me over and
>> over again
>
> I apologize, very sorry for my wording and didn't want to join that, in
> fact very happy about ANY kind of improvements in the network time sync
> area.
>
No need to apologize - perhaps just consider that we're trying to make
those improvements. We'd love the help, rather than an argument where we
make no improvements and people just tell us we're stupid for trying new
things that are imperfect. Especially when everything is imperfect.
I mean, the best complaint I've heard is that we suck for only doing
32bit time. I take that as a challenge and I look forward to solving
that issue because it does really lack in that department.
All the best,
Jacob
