add puzzles-tls cite

svn:r722

2 files changed, 24 insertions, 4 deletions

diff --git a/doc/tor-design.bib b/doc/tor-design.bib
index a018ca7db..da8a0dfcb 100644
--- a/doc/tor-design.bib
+++ b/doc/tor-design.bib
@@ -522,6 +522,26 @@
    note =        {\url{http://www.abditum.com/mixmaster-spec.txt}},
 }
 
+@InProceedings{puzzles-tls,
+    author = "Drew Dean and Adam Stubblefield",
+    title = {{Using Client Puzzles to Protect TLS}},
+    booktitle = "Proceedings of the 10th USENIX Security Symposium",
+    year = {2001},
+    month = Aug,
+    publisher = {USENIX},
+}
+
+@InProceedings{breadpudding,
+  author =       {Markus Jakobsson and Ari Juels},
+  title =        {Proofs of Work and Bread Pudding Protocols},
+  booktitle =    {Proceedings of the IFIP TC6 and TC11 Joint Working
+                  Conference on Communications and Multimedia Security
+                  (CMS '99)},
+  year =         1999,
+  month =        {September},
+  publisher =    {Kluwer}
+}
+
 @Misc{hashcash,
    author =      {Adam Back},
    title =       {Hash cash},
diff --git a/doc/tor-design.tex b/doc/tor-design.tex
index 7b3a4e8cb..6385657f4 100644
--- a/doc/tor-design.tex
+++ b/doc/tor-design.tex
@@ -913,7 +913,7 @@ see Section~\ref{sec:maintaining-anonymity} for more discussion.
 
 \Section{Other design decisions}
 
-\SubSection{Resource management and denial-of-service prevention}
+\SubSection{Resource management and denial-of-service}
 \label{subsec:dos}
 
 Providing Tor as a public service provides many opportunities for an
@@ -935,14 +935,14 @@ fake the start of a TLS handshake, forcing the OR to carry out its
 cost to the attacker.
 
 Several approaches exist to address these attacks. First, ORs may
-demand proof-of-computation tokens \cite{hashcash} before beginning new
+require clients to solve a puzzle \cite{puzzles-tls} while beginning new
 TLS handshakes or accepting \emph{create} cells.  So long as these
 tokens are easy to verify and computationally expensive to produce, this
-approach limits the DoS attack multiplier.  Additionally, ORs may limit
+approach limits the attack multiplier.  Additionally, ORs may limit
 the rate at which they accept create cells and TLS connections, so that
 the computational work of processing them does not drown out the (comparatively
 inexpensive) work of symmetric cryptography needed to keep cells
-flowing.  This rate limiting could, however, allows an attacker
+flowing.  This rate limiting could, however, allow an attacker
 to slow down other users when they build new circuits.
 
 % What about link-to-link rate limiting?