commit 0c856b58719133110d09f35ca8eb47728d42748c Author: Nick Mathewson nickm@torproject.org 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.