Re: [tor-bugs] #20699 [Core Tor/Tor]: prop224: Add control port events and commands

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#20699: prop224: Add control port events and commands
-------------------------------------------------+-------------------------
 Reporter:  dgoulet                              |          Owner:  dgoulet
     Type:  enhancement                          |         Status:
                                                 |  accepted
 Priority:  Very High                            |      Milestone:  Tor:
                                                 |  0.3.3.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs, needs-proposal,              |  Actual Points:
  prop224-extra, tor-control                     |
Parent ID:                                       |         Points:  6
 Reviewer:                                       |        Sponsor:
                                                 |  SponsorR-must
-------------------------------------------------+-------------------------

Comment (by dgoulet):

 @asn, agree on `HSFETCH`, I think we should implement it on the "we need
 it" so we avoid bloating the control port with unused command.

 Now, the interesting case of `HSPOST` which is to upload a descriptor a
 crucial part of OnionBalance. I originally thought we could use it as is
 that is "here is a blob, upload to X".

 It is a bit more complicated in reality. If we want the command to make
 any kind of validation on the descriptor, we need to decode it and for
 this we need both the service identity key (onion address) and the blinded
 key or the blinding factors to recreate it. That would require us to
 extend the command to take both an onion address and a blinded key or the
 factors (num period and period length and a secret when client auth will
 be a thing).

 Another option is to only decode the plaintext part, extract blinded key
 then decode encrypted portion with it. We would still need the onion
 address for the identity key to compute the subcredential needed for
 decryption.

 Lets say we don't do that and only do basic validation that is decoding
 the plaintext part (like what directories do) so we can make sure the
 descriptor won't get rejected by the HSDir.

 Last option is to do NO validation whatsoever on the given descriptor. The
 v2 command does parse the given descriptor to extract the onion address
 and returns an error if that fails. Which brings us to the last part.

 Because v3 doesn't have the onion address in its descriptor like v2 does,
 we can't attach the identity key to a directory connection
 `hs_dir_conn_ident_t` which would make tor not be able to track the
 request and fire up an `HS_DESC` event with the correct information. And
 tor needs the identity key on the connection identifier to function
 properly, it can't only use the blinded key without a *major* re-
 engineering.

 All in all, (1) we need to extend `HSPOST` to accept an onion address or a
 base64 encoded identity pk (not sure which one is ideal) and (2) I would
 think that only doing plaintext validation is enough which is what the
 HSDir will do anyway.

 See prop284 changes here: `ticket20699_02`

 Introduces the `HSAddress=` optional field. I went for the onion address
 instead of a base64 encoded identity pubkey. Now is a good time to make an
 argument for the base64 instead of the onion.

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs