Re: [tor-dev] Proposal 221: Stop using CREATE_FAST
On Thu, Oct 31, 2013 at 2:47 PM, Roger Dingledine wrote: > On Mon, Aug 12, 2013 at 09:14:19PM -0400, Nick Mathewson wrote: >>I propose that in 0.2.5.x, Tor clients stop sending CREATE_FAST >>cells, and use CREATE or CREATE2 cells instead as appropriate. > > I'm a fan. Especially since some relays (like mine) have upgraded to > Tor 0.2.5.x but their OpenSSL isn't new enough to have the new ciphers > for stronger TLS. I've tried to get this right in a couple of branches, as described in ticket #9386. Thanks! -- Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 221: Stop using CREATE_FAST
On Mon, Aug 12, 2013 at 09:14:19PM -0400, Nick Mathewson wrote:
>I propose that in 0.2.5.x, Tor clients stop sending CREATE_FAST
>cells, and use CREATE or CREATE2 cells instead as appropriate.
I'm a fan. Especially since some relays (like mine) have upgraded to
Tor 0.2.5.x but their OpenSSL isn't new enough to have the new ciphers
for stronger TLS.
There's one problem that I foresee though: in circuit_build_failed():
if (circ->cpath &&
circ->cpath->state != CPATH_STATE_OPEN) {
/* We failed at the first hop. If there's an OR connection
* to blame, blame it. Also, avoid this relay for a while, and
* fail any one-hop directory fetches destined for it. */
[...]
log_info(LD_OR,
"Our circuit failed to get a response from the first hop "
"(%s). I'm going to try to rotate to a better connection.",
channel_get_canonical_remote_descr(n_chan));
n_chan->is_bad_for_new_circs = 1;
[...]
entry_guard_register_connect_status(n_chan_id, 0, 1, time(NULL));
In short, if the circuit fails before it's established its first hop,
the Tor client blames the or_connection, marks the relay unusable,
and moves on.
That behavior makes sense in the land of create_fast, since not getting a
response is a sign of a real problem with the TCP connection to the relay
(most commonly this happens because the TCP connection is dead but the
kernel hasn't told us yet).
So, if we implement this proposal, it seems to me that we're going to
have to teach circuit_build_failed() about *why* the circuit failed, so we
can blame the or_conn if it's a timeout (see circuit_expire_building()),
but not blame it if it got an explicit destroy cell.
I also pondered whether we would have weird interaction with our cbt
code, e.g. if some of our guards have long delays for processing creates,
and some don't. But I guess maybe that is a feature not a bug?
--Roger
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 221: Stop using CREATE_FAST
On Mon, Aug 12, 2013 at 09:14:19PM -0400, Nick Mathewson wrote: >I propose that we change "FastFirstHopPK" from a boolean to also >allow a new default "auto" value that tells Tor to take a value from >the consensus. I propose a new consensus parameter, "usecreatefast", >default value taken to be 1. > >Once enough versions of Tor support this proposal, the authorities >should set the value for "usecreatefast" to be 0. I like the idea of leaving this consensus param in place, as another way to be able to ask clients to back off of producing load on relays in emergency situations (e.g. another bot invasion). --Roger ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 221: Stop using CREATE_FAST
On Mon, Aug 12, 2013 at 9:14 PM, Nick Mathewson wrote: [...] >We might just change the default for FastFirstHopPK to 1 in >0.2.5.x-alpha. It would make early users of that alpha easy for >their guards to distinguish. The above paragraph should instead begin "We might just change the default for FastFirstHopPK to 0". (Spotted by Ian Goldberg.) -- Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Proposal 221: Stop using CREATE_FAST
Filename: 221-stop-using-create-fast.txt Title: Stop using CREATE_FAST Authors: Nick Mathewson Created: 12 August 2013 Target: 0.2.5.x Status: Open 0. Summary I propose that in 0.2.5.x, Tor clients stop sending CREATE_FAST cells, and use CREATE or CREATE2 cells instead as appropriate. 1. Introduction The CREATE_FAST cell was created to avoid the performance hit of using the TAP handshake on a TLS session that already provided what TAP provided: authentication with RSA1024 and forward secrecy with DH1024. But thanks to the introduction of the ntor onionskin handshake in Tor 0.2.4.x, for nodes with older versions of OpenSSL, the TLS handshake strength lags behind with the strength of the onion handshake, and the arguments against CREATE no longer apply. Similarly, it's good to have an argument for circuit security that survives possible breakdowns in TLS. But when CREATE_FAST is in use, this is impossible: we can only argue forward-secrecy at the first hop of each circuit by assuming that TLS has succeeded. So let's simply stop sending CREATE_FAST cells. 2. Proposed design Currently, only clients will send CREATE_FAST, and only when they have FastFirstHopPK set to its default value, 1. I propose that we change "FastFirstHopPK" from a boolean to also allow a new default "auto" value that tells Tor to take a value from the consensus. I propose a new consensus parameter, "usecreatefast", default value taken to be 1. Once enough versions of Tor support this proposal, the authorities should set the value for "usecreatefast" to be 0. In the series after that (0.2.6.x?), the default value for "FastFirstHopPK" should be 0. (Note that CREATE_FAST must still be used in the case where a client has connected to a guard node or bridge without knowing any onion keys for it, and wants to fetch directory information from it.) 3. Alternative designs We might make some choices to preserve CREATE_FAST under some circumstances. For example, we could say that CREATE_FAST is okay if we have a TLS connection with a cipher, public key, and ephemeral key algorithm of a given strength. We might try to trust the TLS handshake for authentication but not forward secrecy, and come up with a first-hop handshake that did a simple curve25519 diffie-hellman. We might use CREATE_FAST only whenever ntor is not available. I'm rejecting all of the above for complexity reasons. We might just change the default for FastFirstHopPK to 1 in 0.2.5.x-alpha. It would make early users of that alpha easy for their guards to distinguish. 4. Performance considerations This will increase the CPU requirements on guard nodes; their cpuworkers would be more heavily loaded as 0.2.5.x is more adopted. I believe that, if guards upgrade to 0.2.4.x as 0.2.5.x is under development, the commensurate benefits of ntor will outweigh the problems here. This holds even more if we wind up with a better ntor implementation or replacement. 5. Considerations on client detection Right now, in a few places, Tor nodes assume that any connection on which they have received a CREATE_FAST cell is probably from a non-relay node, since relays never do that. Implementing this proposal would make that signal unreliable. We should do this proposal anyway. CREATE_FAST has never been a reliable signal, since "FastFirstHopPK 0" is easy enough to type, and the source code is easy enough to edit. Proposal 163 and its successors have better ideas here anyway. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
