[tor-commits] [torspec/master] actually add proposal 245

[nickm@xxxxxxxxxxxxxx]

commit 3605bcf15635a9a5a7f034887944091514f70ee8
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Date:   Mon Jun 8 11:21:57 2015 -0400

    actually add proposal 245
---
 proposals/245-tap-out.txt |   96 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 96 insertions(+)

diff --git a/proposals/245-tap-out.txt b/proposals/245-tap-out.txt
new file mode 100644
index 0000000..27d73ab
--- /dev/null
+++ b/proposals/245-tap-out.txt
@@ -0,0 +1,96 @@
+Filename: 245-tap-out.txt
+Title: Deprecating and removing the TAP circuit extension protocol
+Author: Nick Mathewson
+Created: 2015-06-02
+Status: Draft
+
+0. Introduction
+
+  This proposal describes a series of steps necessary for deprecating
+  TAP without breaking functionality.
+
+  TAP is the original protocol for one-way authenticated key negotiation
+  used by Tor.  Before Tor version 0.2.4, it was the only supported
+  protocol.  Its key length is unpleasantly short, however, and it had
+  some design warts.  Moreover, it had no name, until Ian Goldberg wrote
+  a paper about the design warts.
+
+  Why deprecate and remove it?  Because ntor is better in basically
+  every way.  It's actually got a proper security proof, the key
+  strength seems to be 20th-century secure, and so on.  Meanwhile, TAP
+  is lingering as a zombie, taking up space in descriptors and
+  microdescriptors.
+
+1. TAP is still in (limited) use today for hidden service hops.
+
+  The original hidden service protocol only describes a way to tell
+  clients and servers about an introduction point's or a rendezvous
+  point's TAP onion key.
+
+  We can do a bit better (see section 4), but we can't break TAP
+  completely until current clients and hidden services are obsolete.
+
+2. The step-by-step process.
+
+  Step 1. Adjust the parsing algorithm for descriptors and microdescriptors
+  on servers so that it accepts MDs without a TAP key.  See section 3 below.
+  Target: 0.2.7.
+
+  Step 1b. Optionally, when connecting to a known IP/RP, extend by ntor.
+  (See section 4 below.)
+
+  Step 2. Wait until proposal 224 is implemented.  (Clients and hidden
+  services implementing 224 won't need TAP for anything.)
+
+  Step 3. Begin throttling TAP answers even more aggressively at relays.
+  Target: prop224 is stable.
+
+  Step 4. Wait until all versions of Tor without prop224 support are
+  obsolete/deprecated.
+
+  Step 5. Stop generating TAP keys; stop answering TAP requests; stop
+  advertising TAP keys in descriptors; stop including them in
+  microdescriptors.
+  Target: prop224 has been stable for 12-18 months, and 0.2.7 has been stable
+  for 2-3 years.
+
+
+3. Accepting descriptors without TAP keys. (Step 1)
+
+  Our microdescriptor parsing code uses the string "onion-key" at the
+  start of the line to identify the boundary between microdescriptors,
+  so we can't remove it entirely.  Instead, we will make the body
+  optional.
+
+  We will make the following changes to dir-spec:
+
+   - In router descriptors, make the onion-key field "at most once"
+     instead of "exactly once."
+
+   - In microdescriptors, make the body of "onion-key" optional.
+
+  Until Step 4, authorities MUST still reject any descriptor without a
+  TAP key.
+
+  If we do step 1 before proposal 224 is implemented, we'll need to make
+  sure that we never choose a relay without a TAP key as an introduction
+  point or a rendezvous point.
+
+4. Avoiding TAP earlier for HS usage (Step 1b)
+
+  We could begin to move more circuits off TAP now by adjusting our
+  behavior for extending circuits to Introduction Points and Rendezvous
+  Points.  The new rule would be:
+
+     If you've been told to extend to an IP/RP, and you know a directory
+     entry for that relay (matching by identity), you extend using the
+     node_t you have instead.
+
+  This would improve cryptographic security a bit, at the expense of
+  making it possible to probe for whether a given hidden service has an
+  up-to-date consensus or not, and learn whether each client has an
+  up-to-date consensus or not. We need to figure out whether that
+  enables an attack.
+
+  (For reference, the functions to patch would be
+  rend_client_get_random_intro_impl and find_rp_for_intro.)

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