[tor-commits] [torspec/master] Add two small proposals

[nickm@xxxxxxxxxxxxxx]

commit 0c856b58719133110d09f35ca8eb47728d42748c
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Date:   Tue Sep 20 15:34:48 2011 -0400

    Add two small proposals
---
 proposals/184-v3-link-protocol.txt    |   82 +++++++++++++++++++++++++++++++++
 proposals/185-dir-without-dirport.txt |   41 ++++++++++++++++
 2 files changed, 123 insertions(+), 0 deletions(-)

diff --git a/proposals/184-v3-link-protocol.txt b/proposals/184-v3-link-protocol.txt
new file mode 100644
index 0000000..910f223
--- /dev/null
+++ b/proposals/184-v3-link-protocol.txt
@@ -0,0 +1,82 @@
+Filename: 184-v3-link-protocol.txt
+Title: Miscellaneous changes for a v3 Tor link protocol
+Author: Nick Mathewson
+Created: 19-Sep-2011
+Status: Open
+Target: 0.2.3.x
+
+Overview:
+
+  When proposals 176 and 179 are implemented, Tor will have a new
+  link protocol.  I propose two simple improvements for the v3 link
+  protocol: a more partitioned set of which types indicate
+  variable-length cells, and a better way to handle link padding if
+  and when we come up with a decent scheme for it.
+
+Motivation:
+
+  We're getting a new link protocol in 0.2.3.x, thanks (again) to
+  TLS fingerprinting concerns.  When we do, it'd be nice to take
+  care of some small issues that require a link protocol version
+  increment.
+
+  First, our system for introducing new variable-length cell types
+  has required a protocol increment for each one.  Unlike
+  fixed-length (512 byte) cells, we can't add new variable-length
+  cells in the existing link protocols and just let older clients
+  ignore them, because unless the recipient knows which cells are
+  variable-length, it will treat them as 512-byte cells and discard
+  too much of the stream or too little.  In the past, it's been
+  useful to be able to introduce new cell types without having to
+  increment the link protocol version.
+
+  Second, once we have our new TLS handshake in place, we will want
+  a good way to address the remaining fingerprinting opportunities.
+  Some of those will likely involve traffic volume.  We can't fix
+  that easily with our existing PADDING cell type, since PADDING
+  cells are fixed-length, and wouldn't be so easy to use to break up
+  our TLS record sizes.
+
+Design: Indicating variable-length cells.
+
+  Beginning with the v3 link protocol, we specify that all cell
+  types in the range 128..255 indicate variable-length cells.
+  Cell types in the range 0..127 are still used for 512-byte
+  cells, except that the VERSIONS cell type (7) also indicates a
+  variable-length cell (for backward compatibility).
+
+  As before, all Tor instances must ignore cells with types that
+  they don't recognize.
+
+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
+  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.
+
+Interaction with proposal 176:
+
+  Proposal 176 says that during the v3 handshake, no cells other
+  than VERSIONS, AUTHENTICATE, AUTH_CHALLENGE, CERT, and NETINFO are
+  allowed, and those are only allowed in their standard order.  If
+  this proposal is accepted, then VPADDING cells should also be
+  allowed in the handshake at any point after the VERSIONS cell.
+  They should be included when computing the "SLOG" and "CLOG"
+  handshake-digest fields of the AUTHENTICATE cell.
+
+Notes on future-proofing:
+
+  It may be in the future we need a new cell format that is neither the
+  original 512-byte format nor the variable-length format.  If we
+  do, we can just increment the link protocol version number again.
+
+  Right now we have 10 cell types; with this proposal and proposal
+  176, we will have 14.  It's unlikely that we'll run out any time
+  soon, but if we start to approach the number 64 with fixed-length
+  cell types or 196 with var-length cell types, we should consider
+  tweaking the link protocol to have a variable-length cell type
+  encoding.
+
diff --git a/proposals/185-dir-without-dirport.txt b/proposals/185-dir-without-dirport.txt
new file mode 100644
index 0000000..c84ec35
--- /dev/null
+++ b/proposals/185-dir-without-dirport.txt
@@ -0,0 +1,41 @@
+Filename: 185-dir-without-dirport.txt
+Title: Directory caches without DirPort
+Author: Nick Mathewson
+Created: 20-Sep-2011
+Status: Open
+
+Overview:
+
+  Exposing a directory port is no longer necessary for running as a
+  directory cache.  This proposal suggests that we eliminate that
+  requirement, and describes how.
+
+Motivation:
+
+  Now that we tunnel directory connections by default, it is no
+  longer necessary to have a DirPort to be a directory cache.  In
+  fact, bridges act as directory caches but do not actually have a
+  DirPort exposed.  It would be nice and tidy to expand that
+  property to the rest of the network.
+
+Configuration:
+
+  Add a new torrc option, "DirCache".  Its values can be "0", "1",
+  and "auto".  If it is 0, we never act as a directory cache, even
+  if DirPort is set.  If it is 1, then we act as a directory cache
+  according to same rules as those used for nodes that set a
+  DirPort.  If it is "auto", then Tor decides whether to act as a
+  directory cache.
+
+Advertising cache status:
+
+  Nodes which are running as a directory cache but which do not have
+  a DirPort set should set the entry "dir-cache 1" in their router
+  descriptors.
+
+Consensus:
+
+  Authorities should assign a "DirCache" flag to all nodes running
+  as a directory cache that do not set a DirPort.
+
+  This does not require a new version of the consensus algorithm.



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits