Log validity flaw

[abel1502]

This is where the backlinks come in: By iteratively traversing backlinks, any reader of the log can verify that no fork occured. Forked logs are considered invalid from the point of the earliest fork, so there is no incentive for the author to deliberately fork their log.

I've realized this gives the author of a log the power to invalidate its existing tail at any moment, by issuing a forking entry and sharing it with the receivers. This makes entry validity non-permanent, which seems undesirable to me.

Also, there's a similar but less significant issue with tag, where the author could set it in some entry, but then continue the log regardless. They could then only present the lipmaalink path to new parties, making them believe the log is valid (as long as the tag is not on the lipmaalink path itself).

I'd like to clarify whether these are in fact security issues, or if it's a matter in which the spec doesn't aim to provide guarantees? In the latter case, I guess it should be explicitly pointed out. Also I apologize if these matters are in fact addressed in the spec but I've failed to notice it.

[snej]

this gives the author of a log the power to invalidate its existing tail at any moment, by issuing a forking entry and sharing it with the receivers.

This is a good protection if the private key has been compromised. By creating a deliberate fork you make the rest of the log invalid and prevent the attacker from impersonating you.

This makes entry validity non-permanent, which seems undesirable to me.

I guess it’s a matter of opinion (and content domain, probably.) The early BBS/forum The WELL had a principle called “You Own Your Own Words” (YOYOW) which meant every member had the ability to retroactively delete their own posts.

[abel1502]

I just fear this might stimulate divergence from the standard in some implementations. Like, for instance, only deeming the newly-revealed brach invalid. I believe at least an explicit mention of the given scenario (validity revocation) and some reasoning in the spec could suffice to avoid these consequences

[AljoschaMeyer]

@abel1502 My thinking on this topic has shifted over the years, by now I consider the terminology "append-only log" to be misleading, exactly because of the issue you describe. See also https://arxiv.org/abs/2308.13836

I should at some point rework the spec to talk about prefix authentication rather than about logs. For now, a disclaimer will have to do...

For a more detailed discussion on invalidating (parts of) a log, see https://arxiv.org/abs/2307.08381

---

Also, there's a similar but less significant issue with tag, where the author could set it in some entry, but then continue the log regardless. They could then only present the lipmaalink path to new parties, making them believe the log is valid (as long as the tag is not on the lipmaalink path itself).

Again I agree, every entry should also have to include whether its lipmaa link traverses over an end-of-log marker. This is among the things I would change in a new bamboo version (well, I would remove the end-of-log marker in favor of a system for generic monoidal metadata, but that's beside the point).