Maxim Kammerer: > On Wed, Jul 18, 2012 at 7:31 AM, intrigeri <intrig...@boum.org> 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. >
Huh, you think that setting your clock where *everyone* can *always* MITM your time is somehow better? Fascinating! > Motivation behind tlsdate is incorrect: > 1. Extracting the HTTP Date: header is not a “nightmare” — it is easy, > standards-compliant, and safe. Allow me to be very explicit: it is harder to parse an HTTP Date header than properly than casting a 32bit integer and flipping their order. The attack surface is very small and easy to audit. > If anything, TLS is much harder to get > right (see issue #16 on GitHub, for instance — tlsdate is currently > susceptible to a MITM attack). It's a work in progress, of course. I use it with a pinned CA, so in such a case, users are not vulnerable to a MITM attack unless one can get certs from that specific CA. With that said, I have a branch to add CN/SAN checking but it makes little sense when one use case is pre-DNSSEC bootstrapping. Rarely do certificates contain the IP address of the host, so what we care about is an assertion of trust by a given authority. That use case would suggest a pinned CA anyway, so perhaps it would make sense to just add a few new options to tackle that use case. I'm not totally sure but I think getting a CA signature for a specific CA is harder than any CA. I agree that using it where it trusts *any* CA allows *any* CA to assert things. That doesn't really change with CN/SAN checking. Practically, it makes it harder for an attacker but theoretically, we're still relying on the CA playing nice. Pinning removes that gamble, which seems better all around. > 2. The latency due to receiving HTTP headers is negligible when > compared to the latency of a TLS handshake. Do you have some data about that? The TLS ServerHello is generally the first thing sent to the client. I'd expect the timing to be very similar > 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. Nothing? That seems a little... technically incorrect. Users gain a cryptographic signature - which is the goal here - to use time to trust signatures, we might want to start with signatures that don't require time. That raises the bar against an attacker and with a pinned CA, it means that the attacker has to own CA or find another vulnerability in TLS itself. Furthermore, in the TODO, I suggest that we should offer an option to confirm the date by comparing it with HTTP over SSL/TLS - then we can at least say that our HTTP date has some kind of integrity protection. The goal isn't to have millisecond accurate clocks, it's to validate cryptographic signatures that have hour or year long windows. > 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. Yes, another known issue - so does Tor - what's your point? It's turtles all the way down, right? I'll gladly add an option to break the standard, if a user wishes to use it. > > Additionally, tlsdate lacks important features: > 6. It cannot run as a daemon with clock skewing and hosts rotation. That isn't the goal of tlsdate but it is something that could be easily added. Support for a list of hosts would be a fine addition, I'm not sure that a daemon mode makes a lot of sense. With the accuracy levels we're discussing, an hourly cronjob would be fine as well. > 7. There is no explicit proxy support. > It appears to work fine with `usewithtor` but I'd gladly take a SOCKS4a/SOCKS5 patch. > 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). Are you one of the authors of htpdate or something? :-) I'll gladly mirror the functionality of htpdate but the primary goal is to solve a few problems that htpdate does not aim to solve. I think these two tools are complementary but with very different goals - htpdate is like rdate without any kind of security properties and tlsdate is like rdate with the possibility of some security properties. Lots of work to be done, of course. > > 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. > I've emailed with them, so no, it's not just a github pull request. However, I assure you, the cryptographic signature is worth something to a lot of people, even if it isn't worth much to you. They have their own CA system, so I bet they'll make different choices. All the best, Jacob _______________________________________________ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
