[Top][All Lists]
[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
- Re: [Monotone-devel] Monotone Security, (continued)
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/15
- Message not available
- Message not available
- Re: [Monotone-devel] Monotone Security, Peter Stirling, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Jack Lloyd, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Jack Lloyd, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Nathaniel Smith, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Thomas Keller, 2008/10/17
- Re: [Monotone-devel] Monotone Security,
Zack Weinberg <=
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Ethan Blanton, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Zack Weinberg, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Daniel Carosone, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Jack Lloyd, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Markus Wanner, 2008/10/17
- [Monotone-devel] hypothetical - future-dated certs (Re: Monotone Security), Daniel Carosone, 2008/10/19
- [Monotone-devel] Re: hypothetical - future-dated certs (Re: Monotone Security), Markus Wanner, 2008/10/20