#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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs