On Wed, Jul 18, 2012 at 7:31 AM, intrigeri <[email protected]> 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 _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
