#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 arma): s/teared down/torn down/g (three instances) might also want s/precedes/precedes (triggers)/ and s/preceded/predeced (triggered)/ s/have its StreamID=0/has its StreamID=0/ 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? 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? 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. Thanks! -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30365#comment:10> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs