Is rend-spec's 'service-authentication' a thing?

Hi Nick, on #15004 (closed) I added hidden server descriptor parsing to Stem. donncha has been a fantastic help, providing test data and python crypto examples. Interestingly when we came to the rend-spec's service-authentication lines he wasn't able to find them in the tor codebase.

Were they never implemented? They're very strange fields, prefixing encrypted introduction-points with a plaintext field. Stem presently has (untested) support for them but if they're not actually a thing we should drop them from the spec.

changed milestone to %Tor: 0.2.8.x-final

added component::core tor/tor milestone::Tor: 0.2.8.x-final points::small priority::medium resolution::fixed severity::normal sponsor::R status::closed tor-hs type::defect version::tor 0.2.7 labels

It does appear that "service-authentication" doesn't appear under that name in Tor.

Here are the only tokens that are supported:

/** List of tokens recognized in rendezvous service descriptors */
static token_rule_t desc_token_table[] = {
  T1_START("rendezvous-service-descriptor", R_RENDEZVOUS_SERVICE_DESCRIPTOR,
           EQ(1), NO_OBJ),
  T1("version", R_VERSION, EQ(1), NO_OBJ),
  T1("permanent-key", R_PERMANENT_KEY, NO_ARGS, NEED_KEY_1024),
  T1("secret-id-part", R_SECRET_ID_PART, EQ(1), NO_OBJ),
  T1("publication-time", R_PUBLICATION_TIME, CONCAT_ARGS, NO_OBJ),
  T1("protocol-versions", R_PROTOCOL_VERSIONS, EQ(1), NO_OBJ),
  T01("introduction-points", R_INTRODUCTION_POINTS, NO_ARGS, NEED_OBJ),
  T1_END("signature", R_SIGNATURE, NO_ARGS, NEED_OBJ),
  END_OF_TABLE
}; 

/** List of tokens recognized in the (encrypted) list of introduction points of
 * rendezvous service descriptors */
static token_rule_t ipo_token_table[] = {
  T1_START("introduction-point", R_IPO_IDENTIFIER, EQ(1), NO_OBJ),
  T1("ip-address", R_IPO_IP_ADDRESS, EQ(1), NO_OBJ),
  T1("onion-port", R_IPO_ONION_PORT, EQ(1), NO_OBJ),
  T1("onion-key", R_IPO_ONION_KEY, NO_ARGS, NEED_KEY_1024),
  T1("service-key", R_IPO_SERVICE_KEY, NO_ARGS, NEED_KEY_1024),
  END_OF_TABLE
};

/** List of tokens recognized in the (possibly encrypted) list of introduction
 * points of rendezvous service descriptors */
static token_rule_t client_keys_token_table[] = {
  T1_START("client-name", C_CLIENT_NAME, CONCAT_ARGS, NO_OBJ),
  T1("descriptor-cookie", C_DESCRIPTOR_COOKIE, EQ(1), NO_OBJ),
  T01("client-key", C_CLIENT_KEY, NO_ARGS, NEED_SKEY_1024),
  END_OF_TABLE
};

Trac:
Milestone: N/A to Tor: 0.2.7.x-final

Trac:
Status: new to assigned

Marking more tickets as triaged-in for 0.2.7

Trac:
Keywords: N/A deleted, 027-triaged-1-in added

Trac:
Points: N/A to small
Keywords: N/A deleted, SponsorR added
Priority: normal to major
Version: N/A to Tor: 0.2.7

Trac:
Milestone: Tor: 0.2.7.x-final to Tor: 0.2.8.x-final

Bulk-replace SponsorR keyword with SponsorR sponsor field in Tor component.

Trac:
Keywords: SponsorR deleted, N/A added
Sponsor: N/A to SponsorR

Trac:
Keywords: 027-triaged-1-in deleted, tor-hs added
Priority: major to normal

I've pushed a branch to Github which removes this unimplemented field https://github.com/DonnchaC/torspec/tree/fix-15190. The branch also includes a commit which specifies the limit of 10 introduction points in a hidden service descriptor.

Trac:
Severity: N/A to Normal

Trac:
Status: assigned to needs_review

Looks good to me - thanks!

Can't push at the moment (visiting family), but will do next week unless Nick beats me to it.

Merged it; thanks!

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

closed

moved to tpo/core/tor#15190 (closed)