[tor-bugs] #26288 [Core Tor/Tor]: prop289: Implement authenticated SENDME

[Tor Bug Tracker & Wiki]

#26288: prop289: Implement authenticated SENDME
-------------------------------------------------+-------------------------
 Reporter:  dgoulet                              |          Owner:  dgoulet
     Type:  enhancement                          |         Status:
                                                 |  needs_revision
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.4.1.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  prop289, 035-roadmap-master, 035     |  Actual Points:
  -triaged-in-20180711, prop289-assigned-        |
  sponsor-v, 041-proposed-on-roadmap, network-   |
  team-roadmap-2019-Q1Q2                         |
Parent ID:                                       |         Points:  21
 Reviewer:  nickm                                |        Sponsor:
                                                 |  SponsorV
-------------------------------------------------+-------------------------

Comment (by teor):

 Replying to [comment:20 dgoulet]:
 > Replying to [comment:19 teor]:
 > > I reviewed the protocol parts of this patch:
 > >
 > > Phase 3 of the transition plan requires old clients and relays to
 download a consensus so they learn that they should stop trying to connect
 to the network. But since 0.2.8, clients (and censored relays that can't
 access any DirPorts) will try to use the ORPort to download a consensus.
 But ORPort circuits from legacy clients will fail during phase 3.
 >
 > This is what the new protover version is all about. We would flip
 `FlowCtrl=1` _before_ the consensus param `sendme_accept_min_version=1` is
 set. This would effectively exit() every clients/relays that can't support
 v1.

 You're right, old clients and relays that download a consensus while
 FlowCtrl=1 is required, and while v1 sendmes are accepted, will cache that
 consensus. Then they will refuse to connect to the network as long as they
 have that cached consensus.

 But when we start rejecting v1 sendmes, old clients will fail to download
 a consensus. (Most old relays will still be able to fetch consensuses,
 because they use DirPorts.) These old clients may be new installs of an
 old version, clients or relays which clear their data directories, or
 clients that are only launched occasionally.

 How will we handle them?
 We'll shut down most old clients that are already installed. Is that
 enough?
 How much time do we need between setting the protocol version requirement,
 and rejecting v1 sendmes?

 What will an old client do if we reject its sendmes?
 How many old clients will it take to bring down the network?
 Do we need to keep testing old clients without a cached consensus, but
 with v1 sendmes rejected?

 We need to talk about these issues in the proposal.

 > Then we can enforce *only* accepting v1 through the consensus (if that
 param is needed at all).
 >
 > >
 > > Here's what I think we need to do:
 > > 1. always allow legacy sendmes for BEGINDIR for the consensus, and
 everything that is required to validate a consensus:
 > >   * authority certificates,
 > >   * relay descriptors (for bridge clients),
 > >   * anything else?
 >
 > I'm quite reluctant to keep legacy SENDMEs even when the protover
 _and_/_or_ the consensus param is flipped. The whole point of that
 protover is that we don't have to deal with clients not supporting v1. And
 we can NOT flip the "min accept" param before that protover.

 I agree: having to keep legacy code is a really bad outcome.

 > > 3. Don't remove the section about extensive testing using chutney:
 > > {{{
 > > -   We'll want to do a bunch of testing in chutney before flipping the
 > > -   switches in the real network: I've long suspected we still have
 bugs
 > > -   in our sendme timing, and this proposal might expose some of them.
 > > }}}
 > > 4. Do the chutney tests now, and do them again when we want to
 implement each phase on the public network
 >
 > I don't see the point of that in a proposal to be honest. Chutney tests
 have been done extensively to develop that branch so I'm not sure what
 this (4) is about here?...

 Future Tor changes can break our transition plans.

 > Any switch we flip in the consensus, especially something like this,
 needs to be tested a lot. Not doing so is a bit reckless on our part and I
 doubt having it in the proposal saying "we need to test this" is useful at
 all...
 >
 > What I recommend we do is actually describe the "ordering" of all the
 pieces in the transition plan. And then document what we should NOT do so
 in 10 years, we have a reminder of what to do (because I don't see Phase 3
 being done until many years!).

 You're right, writing it down doesn't help that much.

 Here's one way to regularly test future transition plans:

 1. We write a script that runs chutney tests that test each part of the
 transition plan, for old and new clients, and clients with and without
 cached consensuses
 2. We set up a repository on Travis with a cron job that runs once a week,
 to make sure that future changes don't break the transition plan

 Are there other ways to make sure we don't break our future transition
 plans?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26288#comment:21>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online