Re: can we talk about secure time?

[Hanno Böck <hanno () hboeck de>]

On Sun, 21 Dec 2014 12:31:07 +0100
Florian Weimer <fw () deneb enyo de> wrote:

> Some folks want to run their servers within a few milliseconds of each
> other, and do not care so much about security or resiliency.

I perfectly understand that some people need more accuracy than tlsdate
can give. However it's probably rare, right? I don't see any reason why
average consumer hardware (Desktop, smartphone etc.) would have any
problem with the 1-2 sec max inaccuracy of tlsdate.

> Reconciling this with cryptography is certainly a challenge.  On the
> other hand, this does not have to be the default.

I think it shouldn't be too hard to get both.
You could do an asymmetric key exchange before you do any time
transmission. Then the only thing you really need is a single
authentication operation (HMAC or whatever). That shouldn't delay by
any significant amount.

> I think most desktop-based distributions could get away with something
> like tlsdate.
>
> In contrast, servers with long-running connections and I/O polling
> loops often do not react gracefully to jumps in time.  (I once
> disconnected a few hundreds, if not thousands of users from an IRC
> server just by setting its time correctly.)  Sure, you can avoid that
> by using the appropriate kernel clock for timeout handling, but I have
> the impression that the correct clock changes every couple of years.

tlsdate has tlsdated, I hope it acts intelligent and doesn't do time
jumps. Haven't tested though.


-- 
Hanno Böck
http://hboeck.de/

mail/jabber: hanno () hboeck de
GPG: BBB51E42

Attachment: _bin
Description: OpenPGP digital signature