robust_time_syncing.md

@@ -60,22 +60,22 @@ can be fingerprinted.
 
 Some other requirements about this mechanism:
 
-* it has to avoid the security issues that current tordate has wrt.
+* **A**: it has to avoid the security issues that current tordate has wrt.
   replayed Tor consensus;
-* it has to be more robust that the current tordate;
-* it has to be as safe as the current tordate + htpdate combination,
+* **B**: it has to be more robust that the current tordate;
+* **C**: it has to be as safe as the current tordate + htpdate combination,
   e.g. wrt. failing closed when facing a replayed consensus and the
   time set by htpdate is out of the `valid-before`/`valid-until`
   interval (admitedly, the corresponding UX is totally miserable as of
   Tails 1.4, but at least we're failing closed);
-* it has to work with pluggable transports;
-* it has to work when not doing a full bootstrap, e.g.
+* **D**: it has to work with pluggable transports;
+* **E**: it has to work when not doing a full bootstrap, e.g.
   when `/var/lib/tor` is persistent;
-* Tor is a bit fragile when it comes to time jumps during
+* **F**: Tor is a bit fragile when it comes to time jumps during
   early bootstrap stages. For instance, in `tordate` we have to restart Tor
   after setting the time according to the fetched consensus, otherwise
   it just idles, at least sometimes. This will have to be solved too;
-* it should help improve the UX we provide while Tor is boostrapping
+* **G**: it should help improve the UX we provide while Tor is boostrapping
   and the time is being sync'ed, both on success and on various kinds
   of failures.