Opened 5 years ago

Last modified 20 months ago

#12254 new enhancement

Bridge authority should sign its bridge networkstatus doc? Or maybe change format to v3-style vote?

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: bridgedb-parsers, metrics-db, bridgeauth, tor-bridges
Cc: isis, karsten Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Isis points out that Tonga doesn't sign its networkstatus-bridge documents.

See networkstatus_dump_bridge_status_to_file() in src/or/networkstatus.c for background.

In fact, it looks like it's writing out a sort of hybrid smear of various formats. And metrics has learned to read this hybrid smear.

Adding a signature here wouldn't make a huge difference, since Karsten sanitizes the documents before publishing them, so the signature wouldn't be in the public version (and would be wrong anyway). So it is really only a slight improvement over the current "ssh from one trusted machine to the other before processing" chain of custody.

Seems to me that if we're going to add a signature and make the various metrics tools adapt, maybe we should move to having Tonga write out a v3 style vote? Then we'd get various other updates for free (if there are any, I haven't investigated), and also the format would keep up-to-date (which makes it sound like a good thing -- "would keep changing" is the less fun way to say it).

Putting in Tor: unspecified since I don't even know if it's a good idea.

Child Tickets

Change History (5)

comment:1 Changed 5 years ago by isis

Keywords: bridgedb-parsers metrics-db bridgeauth added

I'm willing to write a patch for this one.

Before I write a patch, I'd prefer to first hear some feedback on whether doing 2b is worth the extra effort:

1. Is this desirable?

I mostly just want the BridgeAuth's (tonga's) signature on the networkstatus-bridges file before BridgeDB parses, since BridgeDB's parsers are taking the BridgeAuth's word as gold... to the extent that @type bridge-server-descriptors are thrown out entirely if the BridgeAuth didn't include them in the networkstatus-bridges file.

2. Which patch do you want?

2a. Make the BridgeAuth sign, or,

So far, I only care about this one.

2b. Make the networkstatus-bridges file analogous to V3 networkstatus files

Someone should outline what these are, and probably what benefits/drawbacks they provide. It would be interesting to know how difficult it would be to reuse the functions which create @type network-status-microdesc-consensus-3 documents to also create @type bridge-network-status documents.

comment:2 Changed 5 years ago by nickm

You probably don't want to make a consensus unless we get a design for multiple bridge authorities. A consensus is explicitly the result of combining votes from multiple sources in a deterministic way.

Doing a v3 networkstatus _vote_ is a more reasonable thing in the long term. It's a nontrivial variation on the current code, though. To generate one, you have to construct a networkstatus_t, and pass it to format_networkstatus_vote. You might want to do this in a new file not called "networkstatus-bridges", so that code that relied on the old format could still work. You would need to add a new field for the networkstatus_t.type field -- this is neither exactly a vote nor exactly a consensus. You would also need to add support for a bridge authority to have the same kind of identity key/signing key separation that v3 dirauths have.

If this all sounds too hard, signing the networkstatus-bridges file would be very simple.

comment:3 in reply to:  1 ; Changed 4 years ago by shamrock

Replying to isis:
[...]

2a. Make the BridgeAuth sign, or,

So far, I only care about this one.

If you choose to implement 2a., may I recommend for the new design to permit storing the signing keys and performing the signature operations on an HSM? Even if the initial iteration of the implementation does not leverage hardware-protected cryptographic keys.

comment:4 in reply to:  3 Changed 4 years ago by isis

Replying to shamrock:

Replying to isis:
[...]

2a. Make the BridgeAuth sign, or,

So far, I only care about this one.

If you choose to implement 2a., may I recommend for the new design to permit storing the signing keys and performing the signature operations on an HSM? Even if the initial iteration of the implementation does not leverage hardware-protected cryptographic keys.


I actually do not know how general support for all HSM devices could be implemented trivially. For the TPM world, I believe the standard is to use libtrousers. However this would be a different set of major changes to tor to add such support, and so, if it were to be done, I think it warrants its own ticket (and discussion).

comment:5 Changed 20 months ago by nickm

Keywords: tor-bridges added; removed
Severity: Normal
Summary: Tonga should sign its bridge networkstatus doc? Or maybe change format to v3-style vote?Bridge authority should sign its bridge networkstatus doc? Or maybe change format to v3-style vote?
Note: See TracTickets for help on using tickets.