Merge HSv3 spec fixes we found during onionbalance creation

There are a few issues with the v3 spec that we found out as we were implementing onionbalance. We should merge them.

Examples:

• https://github.com/asn-d6/stem/pull/2#discussion_r348847261
• The MAC description in the descriptor encryption is wrong.

changed milestone to %Tor: unspecified

Trac:
Parent Ticket: #26768 (moved)

added component::core tor/tor milestone::Tor: unspecified network-team-roadmap-2020Q1 network-team-roadmap-september onionbalance owner::asn parent::26768 points::0.2 priority::medium resolution::fixed reviewer::dgoulet scaling severity::normal sponsor::27-must status::closed tor-hs tor-spec type::defect labels

Trac:
Owner: N/A to asn
Status: new to assigned

Move s27 must tickets into new roadmap.

Trac:
Keywords: tor-hs scaling onionbalance network-team-roadmap-september tor-spec deleted, scaling, tor-spec, network-team-roadmap-2020Q1, tor-hs, network-team-roadmap-september, onionbalance added

More:

• CONSENSUS_ARRIVED is marked as STATUS_GENERAL but it's actually STATUS_CLIENT
• Did we document the crosscertification issue?

Disaster SRV computation is: H("shared-random-disaster" | INT_8(period_length) | INT_8(period_num)) and not the other way around.

[Note to self: This is not a spec change, but I wrote a test vector for hashring computation in bug31648 and this should also get in little-t-tor at some point]

Replying to asn:

[Note to self: This is not a spec change, but I wrote a test vector for hashring computation in bug31648 and this should also get in little-t-tor at some point]

Example test vectors are actually a useful part of specs.

Please see https://github.com/torproject/torspec/pull/112 for the spec fixes that came out of onionbalance v3 development.

Trac:
Status: assigned to needs_review

Trac:
Reviewer: N/A to dgoulet

I think we need to define the length in bytes for mac_key_len and salt_len ?

Code is forcing it to 8 bytes:

  crypto_digest_add_bytes(digest, (const char *) &mac_len_netorder, 8);
  crypto_digest_add_bytes(digest, (const char *) &salt_len_netorder, 8);

Trac:
Status: needs_review to needs_revision

Replying to dgoulet:

I think we need to define the length in bytes for mac_key_len and salt_len ?

Code is forcing it to 8 bytes:

{{{ crypto_digest_add_bytes(digest, (const char *) &mac_len_netorder, 8); crypto_digest_add_bytes(digest, (const char *) &salt_len_netorder, 8); }}}

Hey. Isn't htonll already specifying that it's a uint64_t and hence 8 bytes?

Oh hmmm, yes indeed lets go with that since this is not an ABI but rather a hash construction.

Merged to tor-spec!

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

closed

changed time estimate to 1h 36m

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