Update recommended and required protocol versions for "LinkAuth"

LinkAuth method 1 is the one where we pull the TLS master secrets out of the OpenSSL data structures and authenticate them with RSA. LinkAuth method 3 is the one where we use the RFC5705 key export mechanism and Ed25519 signatures; it is not supported in 0.2.9.

Right now we list method 1 as required for clients and relays. That's a problem, since we can't reasonably support it with NSS.

We should at least say that method 1 is not required for clients, and method 3 is recommended for everybody.

Should any method be required for relays? I don't think so currently, since we don't want to kick anybody off the network.

changed milestone to %Tor: 0.3.5.x-final

added 032-backport 033-backport 034-backport component::core tor/tor milestone::Tor: 0.3.5.x-final owner::nickm parent::26631 priority::high resolution::implemented reviewer::teor severity::normal sponsor::8 status::closed type::enhancement labels

I have a patch for 0.3.2 as ticket27286_032, with PR at https://github.com/torproject/tor/pull/291

Trac:
Keywords: N/A deleted, 032-backport 033-backport 034-backport added
Type: defect to enhancement
Status: assigned to needs_review

This looks fine to me.

Just confirming: once authorities deploy this fix, all 0.2.9 and earlier tors will start warning their users to upgrade?

Trac:
Status: needs_review to merge_ready

Trac:
Reviewer: N/A to teor

That is correct, yes.

Trac:
Priority: Medium to High

To make sure I understand: (a) does that mean that nss-based Tor clients won't be able to establish a link connection to 0.2.9 relays or bridges? Since quite a few of the big relays are still on 0.2.9 -- including guards -- that limitation could be a big deal. Specifically, of the 1919 guards, it looks like 345 of them are on 0.2.9. I guess we figure nss-based clients won't be that relevant for another couple of years, by which point 0.2.9 will be dying away?

And (b) it seems weird to say that we support a version if, when you run it, it tells you to upgrade. I guess the choice is between "be able to implement newer client variants and not be disobeying our spec" vs "have existing versions that we claim to support tell people that they need to upgrade"?

If it really is a choice between these two, is there any rush to push through the "start warning" part?

Replying to arma:

To make sure I understand: (a) does that mean that nss-based Tor clients won't be able to establish a link connection to 0.2.9 relays or bridges? Since quite a few of the big relays are still on 0.2.9 -- including guards -- that limitation could be a big deal. Specifically, of the 1919 guards, it looks like 345 of them are on 0.2.9. I guess we figure nss-based clients won't be that relevant for another couple of years, by which point 0.2.9 will be dying away?

It is correct that with NSS, we can't connect to 0.2.9-based bridges or guards.

And (b) it seems weird to say that we support a version if, when you run it, it tells you to upgrade. I guess the choice is between "be able to implement newer client variants and not be disobeying our spec" vs "have existing versions that we claim to support tell people that they need to upgrade"?

We support 0.2.9, but we wish people running it would/could upgrade. I don't see a contradiction there: we'll keep it working and keep fixing important bugs in it, but it is subject to inherent limitations (RSA1024) that mean it sure would be nice for people to upgrade.

That said...

If it really is a choice between these two, is there any rush to push through the "start warning" part?

I guess we could refrain from adding 3 to the recommended list, so that neither of the two protocols is described as recommended or required. We could wait at least until 0.3.5 (which will be the next LTS) is out.

I have removed LinkAuth=3 from the recommended list, and merged it.

Trac:
Status: merge_ready to closed
Resolution: N/A to implemented

closed

mentioned in issue #27288 (moved)

mentioned in issue #33286 (moved)

moved to tpo/core/tor#27286 (closed)

mentioned in issue tpo/core/tor#27288 (closed)

mentioned in issue tpo/core/tor#33286 (closed)