Tor design proposals

Filename: 245-tap-out.txt
Title: Deprecating and removing the TAP circuit extension protocol
Author: Nick Mathewson
Created: 2015-06-02
Status: Superseded
Superseded-by: 350

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.)