[tor-bugs] #31823 [Core Tor/Stem]: HSv3 descriptor support in stem [encoding]

[Tor Bug Tracker & Wiki]

#31823: HSv3 descriptor support in stem [encoding]
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:  atagar
     Type:  defect                               |         Status:
                                                 |  needs_revision
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Stem                        |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs scaling onionbalance          |  Actual Points:  2
  network-team-roadmap-september tor-spec        |
Parent ID:  #26768                               |         Points:  5
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------
Changes (by asn):

 * status:  needs_information => needs_revision


Comment:

 Thanks for the fixes atagar! They seem to work just fine, so I resolved
 all previous comments on the GH PR and added three new ones. Good news!
 I'm testing a stem created descriptor with little-t-tor and parsing seems
 to work just fine! :)

 >> One of the goals of my old _get_middle_descriptor_layer_body() function
 here was to make the output of stem indistinguishable from the output of
 Tor.
 > Sorry, I'm not quite understanding this. The _descriptor_content()
 arguments are simply default values for mandatory fields - if a caller
 would care to provide their own desc-auth-ephemeral-key (rather than use a
 default value) they simply need to provide it...

 Hm. I understand that _descriptor_content() arguments are default values,
 but what defines a good default value here? In particular, the `desc-auth-
 ephemeral-key` and `auth-client` fields of the outerlayer are usually fake
 data in little-t-tor which are easy to generate (see my old
 `_get_middle_descriptor_layer_body()`). It's true that a caller can
 provide their own fake data, but why not make the default value more
 sensible (so that it matches with the one from little-t-tor)? The benefit
 here will be that stem descriptors will be closer to identical with
 little-t-tor's, so that a client cannot tell if a descriptor was made by
 stem or little-t-tor (without the individual applications having to
 explicitly do this themselves).

 In any case and regardless of the above, we do need to provide a single
 fake `auth-client` line otherwise the descriptor won't get parsed by Tor
 (it's a `T1N()` element in `hs_descriptor.c`). I left a comment in the PR
 about this.

 ----

 Back to you now! Over the next few days I will be testing this deeper
 through onionbalance (and as key blinding becomes usable again)!

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