Add drafty prototype

1 files changed, 7 insertions, 25 deletions

diff --git a/docs/introduction.md b/docs/introduction.md
index 65b0366..b0d7e71 100644
--- a/docs/introduction.md
+++ b/docs/introduction.md
@@ -69,10 +69,9 @@ To filter out certificates that are not relevant, the monitor is configured with
 a list of domains to match on.  Only matching certificates will be stored, which
 means there are nearly no storage requirements to run this type of monitor.
 
-To achieve the property of _silence_, the trusted nodes push legitimately issued
-certificates to the monitor which listens for such requests using an HTTP API.
-The monitor will use the feedback from these nodes to further filter the
-downloaded certificates that matched based on which ones are legitimate.  If any
+To get the property of _silence_, the monitor pulls the trusted nodes
+periodically (HTTP GET) for legitimately issued certificates.  The monitor will
+use this feedback to filter the downloaded certificates that matched.  If any
 certificates are found that no node pushed to the monitor, an alert is created.
 
 The communication channel between the trusted nodes and the monitor can be
@@ -83,30 +82,13 @@ Owning that the communication channel is insecure helps avoid misconfiguration.
 A pre-shared secret is used for each node to authenticate with the monitor.
 That secret is never shown on the wire (an HMAC key is derived from it), which
 means that all a man-in-the-middle attacker can do is replay and block messages.
-Accounting for replayed messages is either way a good thing, because it makes it
-easy to overcome temporary issues like a spotty network, a monitor reboot, etc.
-In other words, nodes can periodically (re)submit their legitimate certificates.
-Blocked messages can not be solved by cryptography and will result in alerts.
-
-To keep the attack surface of the monitor down, one may optionally choose to
-operate it as a Tor onion service, restrict access using WireGuard, or similar.
-Or in the case of a single-node deployment, run everything on the same system.
-
-## Open questions
-
-  - What do we do about certificates that appear in the logs after time `T`, but
-    which were issued with a `NotBefore` timestamp that is before time `T`?  We
-    want to minimize noise, but also not open up for CA backdating threats.
-  - What options for generating alerts should be supported other than stdout, if
-    any?  Most deployments already have ways to integrate with dashboards/email.
+"Replays" can happen either way because the monitor polls periodically, i.e.,
+the monitor needs to account for the fact that it may poll the same thing twice.
+Blocking can not be solved by cryptography and would simply result in alerts.
 
 ## Further documentation
 
-  - [HTTP API](./http-api.md): read more about how the trusted nodes
-    authenticate with the monitor to submit legitimately issued certificates.
-  - [State directory](./state.md): read more about how the trusted monitor keeps
-    track of its state as plaintext files in a given directory.  Staying away
-    from a database is meant to ease debugging, silencing of alerts, etc.
+docdoc
 
 ## Future ideas