Add xxx-single-guard-node as proposal 236.
[torspec.git] / proposals / 221-stop-using-create-fast.txt
1 Filename: 221-stop-using-create-fast.txt
2 Title: Stop using CREATE_FAST
3 Authors: Nick Mathewson
4 Created: 12 August 2013
5 Target: 0.2.5.x
6 Status: Closed
7
8 0. Summary
9
10    I propose that in 0.2.5.x, Tor clients stop sending CREATE_FAST
11    cells, and use CREATE or CREATE2 cells instead as appropriate.
12
13 1. Introduction
14
15    The CREATE_FAST cell was created to avoid the performance hit of
16    using the TAP handshake on a TLS session that already provided what
17    TAP provided: authentication with RSA1024 and forward secrecy with
18    DH1024.  But thanks to the introduction of the ntor onionskin
19    handshake in Tor 0.2.4.x, for nodes with older versions of OpenSSL,
20    the TLS handshake strength lags behind with the strength of the onion
21    handshake, and the arguments against CREATE no longer apply.
22
23    Similarly, it's good to have an argument for circuit security that
24    survives possible breakdowns in TLS. But when CREATE_FAST is in use,
25    this is impossible: we can only argue forward-secrecy at the first
26    hop of each circuit by assuming that TLS has succeeded.
27
28    So let's simply stop sending CREATE_FAST cells.
29
30 2. Proposed design
31
32    Currently, only clients will send CREATE_FAST, and only when they
33    have FastFirstHopPK set to its default value, 1.
34
35    I propose that we change "FastFirstHopPK" from a boolean to also
36    allow a new default "auto" value that tells Tor to take a value from
37    the consensus.  I propose a new consensus parameter, "usecreatefast",
38    default value taken to be 1.
39
40    Once enough versions of Tor support this proposal, the authorities
41    should set the value for "usecreatefast" to be 0.
42
43    In the series after that (0.2.6.x?), the default value for
44    "FastFirstHopPK" should be 0.
45
46    (Note that CREATE_FAST must still be used in the case where a client
47    has connected to a guard node or bridge without knowing any onion
48    keys for it, and wants to fetch directory information from it.)
49
50 3. Alternative designs
51
52    We might make some choices to preserve CREATE_FAST under some
53    circumstances.  For example, we could say that CREATE_FAST is okay if
54    we have a TLS connection with a cipher, public key, and ephemeral key
55    algorithm of a given strength.
56
57    We might try to trust the TLS handshake for authentication but not
58    forward secrecy, and come up with a first-hop handshake that did a
59    simple curve25519 diffie-hellman.
60
61    We might use CREATE_FAST only whenever ntor is not available.
62
63    I'm rejecting all of the above for complexity reasons.
64
65    We might just change the default for FastFirstHopPK to 0 in
66    0.2.5.x-alpha.  It would make early users of that alpha easy for
67    their guards to distinguish.
68
69 4. Performance considerations
70
71    This will increase the CPU requirements on guard nodes; their
72    cpuworkers would be more heavily loaded as 0.2.5.x is more
73    adopted.
74
75    I believe that, if guards upgrade to 0.2.4.x as 0.2.5.x is under
76    development, the commensurate benefits of ntor will outweigh the
77    problems here.  This holds even more if we wind up with a better ntor
78    implementation or replacement.
79
80 5. Considerations on client detection
81
82    Right now, in a few places, Tor nodes assume that any connection on
83    which they have received a CREATE_FAST cell is probably from a
84    non-relay node, since relays never do that.  Implementing this
85    proposal would make that signal unreliable.
86
87    We should do this proposal anyway.  CREATE_FAST has never been a
88    reliable signal, since "FastFirstHopPK 0" is easy enough to type, and
89    the source code is easy enough to edit.  Proposal 163 and its
90    successors have better ideas here anyway.