Maxim Kammerer:
> 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.
>
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
