On Fri, Nov 17, 2023 at 12:57:00PM +0100, Niels Möller wrote:
Rasmus Dahlberg rgdd@glasklarteknik.se writes:
Agreed, storing (co)signatures doesn't protect against attacks on the monitor's disk.
Ok.
Only storing the tree head seems fine to me, assuming that the tree head state is never moved forward without a sufficient amount of witnessing.
Hmm, I think that's a tangential issue, or does it relate to locally stored signatures in some way? (My thinking is that if the log signs a tree that includes a leaf with an unauthorized signature, that's worthy of alerts regardless of the presence of cosignatures.
I agree with your thinking here.
And then there should be orthogonal check to raise alerts if cosignatures are missing for too long).
Also agree that such checks are orthogonal.
What I'm trying to say is I don't see an obvious issue if (co)signatures are dropped on disk. The part I do see a potential issue with is if we lose track of how far each log and witness for that log progressed. And if untracked, at least ensure we had a quorum for the stored state.
Otherwise you probably want to know who has cosigned what when, so that it is possible to eventually trigger alerts that say too many recent cosignatures are missing.
Right, I plan to keep state (which probably does *not* need to persisted to disk) with the latest timestamp cosigned per log per witnesses, and the latest timestamp per log that had sufficient number of cosignatures to satisfy configured quorum.
To me it sounds like this information should be persisted to disk. And size as well as root hash that the witness timestamp is associated with.
Out of hyugine I'd still store the latest good (signed) state for each log and witness though. Because it may be useful if an incident occurs.
If that's for forensic purposes only, a monitor could store all received tree heads, including all signatures, to a write-only log file. Those signatures would never be read or verified by the monitor itself, and writing that log, if wanted, could be the responsibility of the monitor application, but out-of-scope for the core monitor library.
The angle you're describing now wrt. forensic purposes makes sense. I like it because the point of a transparency log is not that there will never be an issue. But we can debug issues, and such info = v. helpful.
Perhaps a toggle for 'store everything' and 'store latest' is a reasonable option to have? With the default being 'store latest'.
Or do you see any concrete benefit in having the monitor check that signature when restarting?
No, the only use-case I can think of is random disk-errors. I.e., it is possible to know that it's not a valid signed tree head stored on disk.
-Rasmus