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. And then there should be orthogonal check to raise alerts if cosignatures are missing for too long).
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.
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.
Or do you see any concrete benefit in having the monitor check that signature when restarting?
Regards, /Niels