[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