DocTor should understand the shared randomness protocol

There are a few partioning attacks on the shared randomness protocol (#16943 (moved)) that are not easy to fix. The attacks are not that dangerous and they are quite detectable. It would be nice if DocTor could catch them.

Some detection ideas can be found in this mail: https://lists.torproject.org/pipermail/tor-dev/2015-September/009460.html

Thanks!

added component::archived/doctor owner::atagar priority::medium resolution::implemented severity::normal status::closed type::enhancement labels

Hi asn, actually this is something David and I chatted about at the dev meeting. Is shared randomness in tor and the dir-spec? Last I checked it wasn't and isn't actionable until it it.

I appreciate the link to the email but can you give me the TL;DR version? I haven't been following the discussion to know what 'Commitment Phase' is or any of the rest. All I honestly care about is the mechanics - 'take a look at field X in the vote, and if it's Y then send an alert of severity Z'.

Gonna resolve this since it doesn't look to be actionable right now. Feel free to reopen if you have a specific ask here.

Trac:
Status: new to closed
Resolution: N/A to user disappeared

See #16943 (moved), the shared randomness code hasn't been merged yet, and is still in proposal 250. (And it's not in the dir-spec yet.)

Ok. Feel free to reopen then when it's merged and if there's something specific you want monitored.

This has been merged to dir-spec.txt and moria1 has started to make commit so I'm reopening this so we can have it running before dirauth start to upgrade to 029.

Trac:
Reviewer: N/A to N/A
Type: defect to enhancement
Status: closed to reopened
Parent: #16943 (moved) to N/A
Resolution: user disappeared to N/A

Here is some information about what DocTor should look for:

https://storm.torproject.org/shared/nFWmJv7iSzzek1goqARb7IySKvkdIvKFFBYOjunDTSa

Replying to dgoulet:

Here is some information about what DocTor should look for:

https://storm.torproject.org/shared/nFWmJv7iSzzek1goqARb7IySKvkdIvKFFBYOjunDTSa

Took a look and I find the attack detection heuristics reasonable.

In section 3) Missing shared random value (SRV) we have:

Two lines we are looking for in the consensus:

    "shared-rand-previous-value ..."
    "shared-rand-current-value ..."

If one of those lines is not present in the consensus, warning.

I imagine that we are going to be missing an SRV for the first few months of deploying this feature simply because not enough dirauths support it. Do we actually want to warn everytime?

Maybe we should warn only after we've seen SRVs in the past? Or maybe if enough people had participated in previous rounds of the protocol? Not sure how easy these things can be done in DocTor.

Left this question on irc but might as well move it here. Is there any reason not to have the authorities start participate in shared randomness now, and do the DocTor checks afterward? Seems good to have the authorities in place well before it's used by clients anyway.

The DocTor checks will be easier to write and test when shared randomness is in the live votes.

Chatted from asn and we're gonna defer on this until after shared randomness is in the live consensus. Give me a nudge when it's live and I'd be happy to implement the checks.

@atagar, I was thinking, if you want to build that module in DocTor, we can totally use the test network to run it there as it's fully using shared random there. As you wish :).

Think I'll pass. There's no rush with this and I'd rather not teach DocTor to use the test network.

Oki! Now that 029 is stable, we already have 5 dirauth speaking that protocol which means that in around 36 hours, if all goes well, we'll have a shared random value created.

Thus this DocTor check is becoming important to have.

Hi David, just a quick note to say this has bubbled up to the top of my todo list (sadly in part by knocking #20969 (moved) off of it). Hopefully I'll have something here in the next few days.

Hi George, hi David. Sorry about the long delay here. Pushed checks #1-3 to my ticket1434 branch. Check #4 (closed) requires remembering values from hour to hour and DocTor is largely stateless so unless it's vital I'm passing on that one.

Mind reviewing the changes to make sure they're what you want?

https://gitweb.torproject.org/user/atagar/doctor.git/log/?h=ticket17434

Trac:
Status: reopened to needs_review

Looks good! No idea if it actually works but I'll trust you on that!

Is this detection is reasonable to do with DocTor you think? Quoting the tor-dev@ email:

It would also be useful if consensus-health fetched all the votes *seen* by an
authority, and not just the one it publishes. This way we can find attacks where
the attacker sends different votes to different honest auths. We can fetch the
alien votes seen by an authority using the URL tor/status-vote/next/<fp>.z .

Hi David. Downloading n^2 vote documents would be very expensive. If such a check is critical it could be implemented but it would be separate from the main consensus health script.

Pushing these new checks and giving 'em a whirl. Feel free to reopen if you need anything else.

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

closed

mentioned in issue #21102 (closed)

moved to tpo/network-health/doctor#17434 (closed)