monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Monotone Security


From: Zack Weinberg
Subject: Re: [Monotone-devel] Monotone Security
Date: Thu, 16 Oct 2008 09:31:40 -0700

On Thu, Oct 16, 2008 at 8:41 AM, Jack Lloyd <address@hidden> wrote:
>> Regardless of whether this stops the DOS attack or not, I think that it is
>> important that the dates on the certificates be trustworthy.
>
> That is really really hard. In fact it seems pretty much impossible,
> especially for backdating.
[...]
> I think in Monotone is it more useful to reason about causality using
> the explicit revision graph rather than try to bring trusted global
> clocks into it.

Yes.  Distributed systems research has concluded that there ain't no
such thing as a trustable global clock.  (I don't have cites - this is
my paraphrase of something Nathaniel said some years ago.)  In
particular, the rule Daniel suggested in his next message

> Never trust a revision that is dated earlier than its parent

is broken both ways: a malicious sender can ensure that all their bad
revisions are dated later than their parents, and an innocent sender
suffering from clock skew can produce good revisions that are
nonetheless dated earlier than their parents.

More generally, Daniel, you seem to want to put security enforcement
in the sender of revisions, which you simply can't do in distributed
systems.  All security has to go in the *recipient*, because the
sender could be completely malicious.  (It's ok to do some checks of
the form "I know the recipient will reject this so I won't waste
bandwidth transmitting it" in the sender, but the recipient can't
assume the sender is doing that.)

Are there any writeups of more-or-less-current policy branch thinking
on the wiki or other convenient place?  We *have* thought about these
issues at great length, but I'm not sure where to point new people so
they can get past the simple, obvious, but wrong solutions quickly.

zw




reply via email to

[Prev in Thread] Current Thread [Next in Thread]