[tor-bugs] #30365 [Core Tor/Tor]: prop289: Update tor-spec.txt with authenticated SENDME spec

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu May 30 12:09:15 UTC 2019


#30365: prop289: Update tor-spec.txt with authenticated SENDME spec
-------------------------------------------------+-------------------------
 Reporter:  dgoulet                              |          Owner:  dgoulet
     Type:  task                                 |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.4.1.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-spec, prop289, sendme,           |  Actual Points:  0.2
  041-should                                     |
Parent ID:  #26288                               |         Points:  0.2
 Reviewer:  arma                                 |        Sponsor:
                                                 |  SponsorV
-------------------------------------------------+-------------------------

Comment (by dgoulet):

 >  This fixup still leaves me first and Rob second. I think I put Rob
 first because he thought of the idea (and wrote about it in his sniper
 attack paper). Let's leave him first rather than revise history right when
 we close the proposal. :)

 Apologies! I've put back everyone in the right order. :S

 >  the other entries say a minimum and maximum and default. that would be
 useful here too. especially since we will eventually change the default,
 and then we'll want to annotate here what versions had which default.

 Good catch! I've also added the "First appeared:" ...

 > I'm confused that the digest of a version 1 sendme cell has 20 bytes,
 but then there's some mention of 4 also? I think the 4 is because that's
 what how many bytes we actually put in a relay header? What if one side
 remembers 4 bytes, but then gets a v1 sendme with a DATA_LEN of 20? Should
 it compare just the first 4 bytes? Or the last 4 bytes? As currently
 written, if the DATA_LEN in a v1 sendme is 6, then we're supposed to read
 20 bytes, which is unintuitively more than the 6 that it said it included?

 The original proposal said 4 bytes because that is the size of the rolling
 digest in a cell but at the OR/OP, we have access to the full digest so
 the full 20 bytes was used in the end.

 I've corrected the paragraph that talks about 4 bytes. Now it is all about
 20 bytes.

 >  Should we include in the spec some mention of leaving some bytes unused
 in some relay_data cells, to ensure there is unpredictable data going
 through?

 Yes! Added a sentence in the circuit-level section.

 >  And lastly, what did we decide on how directory mirrors should handle
 serving consensus documents once sendme_accept_min_version moves to 1? Did
 we make some exception for that situation, so clients who only emit 0 can
 still get the consensus to learn that their supported protovers are too
 old? Might be good to put that in the spec if we decided to build it.

 We did not go that way. The deployment plan in the prop289 should be
 enough and that is:

 1. Emit v1
 2. Protover goes to FlowCtrl=1
 3. Accept v1.

 At step (2), old clients will be phased out. I created this *GREAT* wiki
 page ;) in order for us to remember that we need to do that for a tor
 release:

 https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/ReleaseParameters

 Created 3 fixup commits to fix all the above (3 because changes span over
 3 files/commits :).

 Thanks!

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


More information about the tor-bugs mailing list