[tor-commits] [torspec/master] Incorporate Roger's comments into proposal 184

[nickm at torproject.org]

commit 02049040cd6816ed4893a508a57b61164f9c70ea
Author: Nick Mathewson <nickm at torproject.org>
Date:   Thu Sep 22 21:41:18 2011 -0400

    Incorporate Roger's comments into proposal 184
---
 proposals/184-v3-link-protocol.txt |   18 +++++++++++++++++-
 1 files changed, 17 insertions(+), 1 deletions(-)

diff --git a/proposals/184-v3-link-protocol.txt b/proposals/184-v3-link-protocol.txt
index 910f223..8af15f9 100644
--- a/proposals/184-v3-link-protocol.txt
+++ b/proposals/184-v3-link-protocol.txt
@@ -51,12 +51,28 @@ Design: Indicating variable-length cells.
 Design: Variable-length padding.
 
   We add a new variable-length cell type, "VPADDING", to be used for
-  padding.  All Tor instances may send a DROP cell at any point that
+  padding.  All Tor instances may send a VPADDING cell at any point that
   a VERSIONS cell is not required; a VPADDING cell's body may be any
   length; the body of a VPADDING cell MAY have any content.  Upon
   receiving a VPADDING cell, the recipient should drop it, as with a
   PADDING cell.
 
+  (This does not give a way to send fewer than 5 bytes of padding.
+  We could add this in the future, in a new link protocol.)
+
+  Implementations SHOULD fill the content of all padding cells
+  randomly.
+
+A note on padding:
+
+  We do not specify any situation in which a node ought to generate
+  a VPADDING cell; that's left for future work.  Implementors should
+  be aware that many schemes have been proposed for link padding
+  that do not in fact work as well as one would expect.  We
+  recommend that no mainstream implementation should produce padding
+  in an attempt to resist traffic analysis, without real research
+  showing that it helps.
+
 Interaction with proposal 176:
 
   Proposal 176 says that during the v3 handshake, no cells other