[tor-dev] Proposal 245: Deprecating and removing the TAP circuit extension protocol
nickm at torproject.org
Tue Jun 2 16:00:41 UTC 2015
Title: Deprecating and removing the TAP circuit extension protocol
Author: Nick Mathewson
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
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.
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
Step 5. Stop generating TAP keys; stop answering TAP requests; stop
advertising TAP keys in descriptors; stop including them in
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
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
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.)
More information about the tor-dev