Clients flip out when two routers use the same identity key

If two routers are set up to use the same identity key, the authorities will sometimes list both. This confuses clients. Instead, authorities should only allow one server per key.

[Automatically added by flyspray2trac: Operating System: All]

changed milestone to %Tor: unspecified

added component::core tor/tor milestone::Tor: unspecified needs-proposal priority::low resolution::fixed severity::normal status::closed tor-relay type::defect version::0.2.0.18-alpha labels

Probably, this needs a proposal.

Indeed, this needs a proposal. I'm going to kick it out of "due in 0.2.1.x-final", since it needs some design work, and since the fix should go in at the authorities rather than at the clients.

The problem is that, by our current voting rules, it's possible for two servers with the same ID to each get enough votes from different authority sets for the consensus to include both. We should probably just add another rule saying, "If the consensus algorithm results in having two servers with the same ID included, arbitrarily break the tie in favor of ..." the one with the lower IP:Port? The one whose server descriptor fingerprint appears first?

Trac:
Parent: N/A to N/A
Keywords: N/A deleted, N/A added
Milestone: post 0.2.1.x to Tor: 0.2.2.x-final

Kicking this out of 0.2.2.x-final; nobody wrote the proposal. Again. :/

Trac:
Milestone: Tor: 0.2.2.x-final to N/A
Description: If two routers are set up to use the same identity key, the authorities will sometimes list both. This confuses clients. Instead, authorities should only allow one server per key.

[Automatically added by flyspray2trac: Operating System: All]

to

If two routers are set up to use the same identity key, the authorities will sometimes list both. This confuses clients. Instead, authorities should only allow one server per key.

[Automatically added by flyspray2trac: Operating System: All]

Trac:
Milestone: N/A to Tor: unspecified

Is this bug still possible with the current directory protocol?

Trac:
Points: N/A to N/A
Actualpoints: N/A to N/A

I believe so?

Trac:
Keywords: N/A deleted, needs-proposal added

Trac:
Keywords: needs-proposal deleted, needs-proposal tor-relay added

Trac:
Component: Tor Relay to Tor

This is no longer possible with how directory authorities work today.

Trac:
Status: new to closed
Severity: N/A to Normal
Sponsor: N/A to N/A
Cc: nickm,Sebastian to nickm, Sebastian
Resolution: None to fixed
Reviewer: N/A to N/A

closed

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