2 files changed, 119 insertions, 0 deletions
diff --git a/archive/2021-08-24-checkpoint-otherdata b/archive/2021-08-24-checkpoint-otherdata
new file mode 100644
index 0000000..94caca0
--- /dev/null
+++ b/archive/2021-08-24-checkpoint-otherdata
@@ -0,0 +1,59 @@
+Background
+	* The current checkpoint format leaves the [otherdata] section undefined
+	* (The format of [otherdata] is inferred from a log's unique identifier)
+
+Impact on believers
+	* None, makes sense that each ecosystem knows their own format
+
+Impact on witnesses
+	* If witnesses disregard [otherdata] while cosigning: none
+	* Otherwise: may complicate witness configuration and support for [otherdata]
+
+The problem in more detail
+	* (Let's not focus on if these extensions are good ideas or not.  It's an example.)
+	* Suppose ecosystem A uses a checkpoint extension that adds a timestamp
+		* First line of otherdata: <timestamp> <diff>
+		* "A witness must only sign a checkpoint if its timestamp is in [now-diff, now]"
+	* Now ecosystem B comes along
+		* "We want timestamp verification too as in ecosystem A"
+		* "Some witnesses support that, just pass 'ecosystem A' as log metadata"
+		* (A little hacky but works)
+	* Now ecosystem C comes along
+		* "We want a timestamp as in ecosystem A and B"
+		* "We also want a secondary root hash because we operate a log-backed map"
+		* Unless witnesses change they will not understand 'ecosystem C' as log metadata
+		* This is unfortunate if witnesses actually do understand the timestamp part :<
+
+Prediction
+	* If [otherdata] catches on, each log ecosystem will do their own thing
+	* This may lead to compatibility issues like the one described above
+
+Mitigation
+	* A well-defined [otherdata] format that is generally useful would go a long way
+
+Example: an unordered key-value format
+	* Identifier: 'checkpoint key-value format'
+		* Might be communicated on the first line in [otherdata]
+			* Would affect the current checkpoint format
+		* Might be communicated as external checkpoint metadata
+			* Would not affect the current checkpoint format
+			* Would probably be good with a 'recommended usage' section though
+				* "If you want witnesses to look into [otherdata], think about X else Y"
+	* Grammar
+		* Each line is composed of <key>=<value>
+			* A line is an extension that is named <key>
+			* A key must not contain '='
+			* A line must adhere to the usual checkpoint v0 restrictions, e.g., no '\n'
+
+What we gained from this example:
+	* Witnesses that peek into [otherdata] would probably have used a common format
+	* Ecosystem A would probably have used that format to define a timestamp extension
+		* verified-timestamp=<timestamp> <diff>
+	* Ecosystem C could come along and set their [otherdata] to:
+		* map-hash=<root hash>
+		* verified-timestamp=<timestamp> <diff>
+	* Now a witness that speaks 'checkpoint key-value format' and which enforces the 'verified-timestamp' extension can do that regardless of if they know 'map-hash'
+
+Conclusion
+	* Allowing witnesses to peek into [otherdata] can get messy.
+	* We can probably avoid this mess by having a recommended or forced [otherdata] usage
diff --git a/archive/2021-08-24-checkpoint-timestamp b/archive/2021-08-24-checkpoint-timestamp
new file mode 100644
index 0000000..bc2b4b5
--- /dev/null
+++ b/archive/2021-08-24-checkpoint-timestamp
@@ -0,0 +1,60 @@
+Background
+	* The current checkpoint format does not contain a roughly verified timestamp
+	* Therefore, there is a possible attack against log monitors
+
+Assumptions about log monitors
+	* Download log leaves to find suspicous ones
+	* Rely on witness cosigning for security, defined loosely as:
+		* "Any leaf a believer accepts I will discover in a timely manner"
+		* "Timely manner" is vague, but sort of "today" rather than "next month"
+	* Receive checkpoints and log entries from untrusted parties only
+		* "Bob in Växjö, Sweden, who downloads log entries and checkpoints from the log"
+		* I.e., with these assumptions we are probably looking at a smaller self-monitor
+
+Attacker capabilities
+	* Controls the untrusted parties that a targeted monitor talks to
+	* Can submit a malicious leaf that the targeted monitor would like to discover
+	* Cannot fork the log due to witness cosigning (does not control enough witnesses)
+
+Attacker goal
+	* Slow down a monitor so that a malicous leaf is not detected for a long time
+
+Attack outline
+	* Suppose witnesses cosign an append-only checkpoint history [a,b,c,...]
+	* A believer accepts a log leaf if it has an inclusion proof to a cosigned checkpoint
+	* Each time a targeted monitor asks for a cosigned checkpoint:
+		* Option 1: return the same checkpoint_X that the monitor already has
+		* Option 2: every now and then return checkpoint_X+1
+	* This means that:
+		* The append-only witness history may be [a,b,c,d,e,f]
+		* The append-only history that a monitor observes may only be a sublist [a,b,c]
+	* Problem: monitor's view does not contain all log leaves that a believer accepts
+		* Now the attacker inserts its malicous log leaf
+		* A believer accepts it because it has an inclusion proof for cosigned checkpoint_g
+		* The monitor does not notice this entry at all (stuck) or much later (slowed-down)
+
+Attack remarks
+	* There is no log or witness misbehavior to speak of / prove after the fact
+	* Attack is possible because the monitor doesn't see the complete checkpoint history
+
+Attack mitigations
+	* Option 1: ensure that checkpoints can convince a monitor that they are current
+		* Add a checkpoint timestamp that witnesses verify roughly
+		* Monitor checks that new checkpoints have recent timestamps
+		* This would strenghten the overall witnessing threat model so that the attacker could only pull of a slow-down attack if they can tamper with relevant clocks.
+	* Option 2: monitors must convince themselves that they see recent checkpoints
+		* Gossip / download checkpoints from different parties and/or diverse vantage points
+
+Conclusion
+	* Important: communicate the threat of slow-down attacks
+	* Important: pick a mitigation option, communicate it, and be aware of limitations
+	* A roughly verified timestamp does not fit into the claimant model.  Example:
+		* Policy: "we only sign documents that have today's date"
+		* Scene: there is a document that needs to be signed in a meeting room.
+			* 2021-08-20, <Alice signature>
+			* 2021-08-20, _________________
+		* Two weeks later Bob walks by and realizes that he forgot to sign.  It would be embarrassing to draw up new papers and ask Alice to sign again, so Bob signs.
+				* 2021-08-20, <Alice signature>
+				* 2021-08-20, <Bob signature>
+		* Once a signature has been slapped on there is no way to prove if the above policy was followed or not.  This is what makes a claim like "I will only sign if the timestamp is in [now-X, now], X>0" unfalsifiable and hence a 'bad claim'.
+	* While a roughly verified timestamp does not fit into the claimant model, it does fit into the policy aspect of witness cosigning.  Witnesses are trust anchors.