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

 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.

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

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

 >
 > The spec and the code are also out of sync: the spec talks about
 FlowCtrl, but the code doesn't have FlowCtrl.

 Yes, that is what the original comment mean on my part is that I didn't do
 this yet because I wasn't sure it was the right approach with the
 `SendMe`.

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