On Wed, Jul 18, 2012 at 7:31 AM, intrigeri <intrigeri@???> wrote:
> Thoughts?
After pondering about extending tlsdate for a while, I see no reason
to use tlsdate instead of htpdate at the moment (or, possibly, ever).
There is a difference between thinking of and experimenting with a
gimmick, and using it as a replacement for a robust method of time
setting.
Motivation behind tlsdate is incorrect:
1. Extracting the HTTP Date: header is not a “nightmare” — it is easy,
standards-compliant, and safe. If anything, TLS is much harder to get
right (see issue #16 on GitHub, for instance — tlsdate is currently
susceptible to a MITM attack).
2. The latency due to receiving HTTP headers is negligible when
compared to the latency of a TLS handshake.
3. Nothing is gained by restricting the application layer to TLS — the
reverse is true, since, e.g., using HTTP instead of HTTPS to reduce
latency is not possible anymore.
4. tlsdate either leaks local clock in ClientHello, or is not
standards-compliant (currently, it leaks the local clock); the user
cannot disable TLS to avoid that.
Additionally, tlsdate lacks important features:
6. It cannot run as a daemon with clock skewing and hosts rotation.
7. There is no explicit proxy support.
Once / if these features are implemented, tlsdate will only provide
part of the functionality of htpdate (since TLS is forced), and will
not have any advantages over it (perhaps besides the possibility of
using non-HTTP(S) servers).
I also wonder whether Chrome OS's usage of tlsdate is confirmed by
Google, or this information comes from a single pull request on
GitHub. In any case, I suspect that Chrome OS developers did not
properly explore the available time setting options.
--
Maxim Kammerer
Liberté Linux:
http://dee.su/liberte
