[Formats] Rename Ecosystem checkpoint field to Origin #470
Conversation
|
There are one or two more references to |
formats/log/README.md
Outdated
|
|
||
| The presence of this identifier forms part of the log claim, and prevents witness | ||
| signatures being moved between log checkpoints with identical contents, preventing a | ||
| particular type of targetted attack. |
There was a problem hiding this comment.
I think this is just spelled "targeted" but maybe that's an American thing?
formats/log/README.md
Outdated
|
|
||
| > Note that golang sumdb implementation is already compatible with this | ||
| `[otherdata]` extension (see | ||
| <https://github.com/golang/mod/blob/d6ab96f2441f9631f81862375ef66782fc4a9c12/sumdb/tlog/note.go#L52>). | ||
|
|
||
| The first signature on a checkpoint must be from the log which issued it. | ||
| The first signature on a checkpoint should be from the log which issued it, but there MUST NOT | ||
| be more than one signature from a log identity present on the checkpoint () |
There was a problem hiding this comment.
Not sure what's happened with the empty brackets?
There was a problem hiding this comment.
I think I was going to add a parenthetical about it being nonsensical to have a signature on a checkpoint from a log other than the one identified by the zeroth line, but that's probably not really necessary so I've ding'd 'em.
formats/log/README.md
Outdated
| The presence of this identifier forms part of the log claim, and prevents witness | ||
| signatures being moved between log checkpoints with identical contents, preventing a | ||
| particular type of targeted attack. |
There was a problem hiding this comment.
This is true, but expanding this won't do us any harm. Something a little closer to a compelling explanation for me would be something like:
Including a unique log string in the checkpoint prevents distinct logs from creating checkpoints with the same contents. This prevents signatures from being transferred between checkpoints. As an example of an attack that this mitigates: a witness signature on a checkpoint confirms that the log's append-only property has been verified as of this checkpoint. If another log creates the same checkpoint, the witness signature can be used on that checkpoint which implies a verification check that may never have happened.
There was a problem hiding this comment.
I'm not at all against sharing the details, but I'm not sure whether this is the right place to put them - if I'm implementing this, I suspect that at a first pass I just want to know what the fields are and how I should use them, later on I might be interested to know why.
Would having these sorts of details in an issue or appendix section be better? (Maybe I should also remove the "preventing a particular type..." bit too?)
There was a problem hiding this comment.
Yeah I think dropping that removes the slippery slope into explaining the whole thing here. To keep this short and still accurate, perhaps "The presence of this identifier forms part of the log claim, and means that no two logs can create byte-equivalent checkpoints.".
Witnesses, signatures, and all of that can then be moved elsewhere.
There was a problem hiding this comment.
Reworded and remove the extra stuff for now - we can figure out where to put that later.
formats/log/README.md
Outdated
|
|
||
| **Differences from sumdb root:** | ||
| The sumbdb note has `go.sum database tree` as its ecosystem string. | ||
| The sumbdb note has `go.sum database tree` as its `Origin`. |
There was a problem hiding this comment.
Is this really a "difference" as the title suggests?
This change identified a few tests that were still passing using the old origin string that was replaced in google#470. I think this is compelling that reusing the same parsing code reduces bugs.
This change identified a few tests that were still passing using the old origin string that was replaced in #470. I think this is compelling that reusing the same parsing code reduces bugs.
The Ecosystem is a properly of the log which is a member of that ecosystem, whereas the checkpoint is the embodiment of a claim made by that log and as such should be explicit about its origin.
This change renders checkpoints signed by the "wrong" log key invalid, and mitigates a class of targeted attack when using witnesses to protect against split views.