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

[Tor Bug Tracker & Wiki]

#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