Re: [Monotone-devel] Monotone Security

[Daniel Carrera]

Peter Stirling wrote:
> The problem is that if you have the old key available to you, then you 
> can create revisions that will pass your test for 'earlier than <date>',
> regardless of when they were actually signed.

Monotone lets you do that? I mean, I know that if you have shell access 
to the database you can use sqlite to insert whatever you want, and the 
paper already warns about shell access. But assuming that we are on 
netsync, will Monotone allow you to sign a binary and claim a date that 
is in the past?

Regardless of whether this stops the DOS attack or not, I think that it 
is important that the dates on the certificates be trustworthy.

In any case, I think that you proposed a more workable solution than mine:

> The problem is probably not quite as dire as I originally thought.
>
> Revisions include the hash of the parent revision so the DAG can't be 
> spoofed (if I understand the mechanism correctly), so you only need
> to examine revisions chains that are at the head of a branch
> that are signed by the 'evil' key.
>
> If you start from the last revision signed by a 'good' key you can 
> assign someone to look at each child revision in turn, to see if it
> should be kept. Once you find a bad revision, it, and all its children
> can be kill_revision_locally'd by a script.

Yeah. This should work. You might have to do it for every head, but the 
main point is that you can do it - you don't have to cancel the project. 
Find the most recent revision date-stamped with a good key which is 
dated before the key compromise happened. Then kill every descendant of 
that revision. Repeat for every head.


> With 10,000,000 bogus branch heads you might be forced to simply delete 
> (recursively) every revision signed by the key that is at the head of a
> branch (though this would risk losing useful stuff).

Slight modification:

foreach (head) {
    if (head is signed with bad key) {
        1. find the first ancestor revision of that head that is
        signed by a good key.
        2. delete every descendant of that revision.
    }
}



Daniel.