[or-cvs] add puzzles-tls cite

[arma@seul.org (Roger Dingledine)]

Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/home2/arma/work/onion/cvs/doc

Modified Files:
	tor-design.bib tor-design.tex 
Log Message:
add puzzles-tls cite


Index: tor-design.bib
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.bib,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -d -r1.19 -r1.20
--- tor-design.bib	2 Nov 2003 00:32:54 -0000	1.19
+++ tor-design.bib	3 Nov 2003 01:25:41 -0000	1.20
@@ -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},

Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.66
retrieving revision 1.67
diff -u -d -r1.66 -r1.67
--- tor-design.tex	3 Nov 2003 01:03:00 -0000	1.66
+++ tor-design.tex	3 Nov 2003 01:25:41 -0000	1.67
@@ -913,7 +913,7 @@
 
 \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 @@
 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?