Implement whitelisting of (email_address, gpg_key_id) pairs for encrypted, automated email bridge distribution
Roger told me that BridgeDB used to send bridges to a list of emails. It got those bridges from the reserved pool, and sent some of them to the members of the mailing list every so often.
This feature seems to be disabled now (for some reason), but it might be a good idea to revive it.
Activity
Replying to asn:
It got those bridges from the reserved pool
Do you mean the unallocated pool, or the pool reserved for the email distributor?
This feature seems to be disabled now (for some reason), but it might be a good idea to revive it.
Seems like a good idea.
Questions:
-
What if we were to sort the bridges in whichever pool you're talking about, take the ones with the lowest used-bandwidth to reported-available-bandwidth ratio, and send those to the mailing list?
-
What's the name of this list? Does bridges@bridges.tpo have posting permissions for it? Does/Should anyone else?
-
Can anyone subscribe, or only subscribers from gmail/yahoo accounts?
Trac:
Cc: sysrqb to sysrqb, isis@torproject.org
Keywords: N/A deleted, distributor, list, email added
Status: new to needs_information-
Replying to isis:
-
What's the name of this list? Does bridges@bridges.tpo have posting permissions for it? Does/Should anyone else?
-
Can anyone subscribe, or only subscribers from gmail/yahoo accounts?
It was a short list of a few individuals' e-mail addresses, not a mailing list. The list of recipients should not be published.
-
Replying to asn:
Roger told me that BridgeDB used to send bridges to a list of emails. ... This feature seems to be disabled now (for some reason), but it might be a good idea to revive it.
Do we have this list of email addresses? The easiest way to do this will be to add another distributor (maybe 1% of all bridges) and send bridges from it. I don't actually see the code for this, I wonder if it was removed for a good-reason-at-the-time.
Trac:
Cc: sysrqb, isis@torproject.org to sysrqb, isis@torproject.org, arma-
Replying to sysrqb:
The easiest way to do this will be to add another distributor (maybe 1% of all bridges) and send bridges from it. I don't actually see the code for this, I wonder if it was removed for a good-reason-at-the-time.
I believe it used a subset of the reserved bridge pool.
Replying to sysrqb:
Replying to asn:
Roger told me that BridgeDB used to send bridges to a list of emails. ... This feature seems to be disabled now (for some reason), but it might be a good idea to revive it.
Do we have this list of email addresses? The easiest way to do this will be to add another distributor (maybe 1% of all bridges) and send bridges from it. I don't actually see the code for this, I wonder if it was removed for a good-reason-at-the-time.
Yes, we have a small list of addresses. We can test the idea on this small list, and if it's useful we can start expanding the list.
Trac:
Cc: sysrqb, isis@torproject.org, arma to sysrqb, isis@torproject.org, arma, nima@redteam.ioReplying to rransom:
It was a short list of a few individuals' e-mail addresses, not a mailing list. The list of recipients should not be published.
Great! Then I propose this: no mailing lists. The only thing convenient about mailing lists is the automatic subscription management, and that is not a feature in our case since we don't really want any email/gmail/yahoo address to be able to sign up for this. Instead, I propose we whitelist (<email_address>, ) pairs, and we encrypt the automatic "mailing list" bridges that are sent out to those keyids. Does this seem sane? I would like to decrease the amount of plaintext emails with bridge addresses in them which are being bounced around.
Something else we need to take into account is pluggable transports. Right now we have 560ish regular bridges available for distribution using these emails. I don't know how many of those bridges support obfs2 or obfs3 (BridgeDB doesn't tell us that right now, we'll work on that).
To give us a rough idea, these are the number of transports bridges support for all bridges in BridgeDB: 2798: 0 150: 1 793: 2 2: 3
It's probably safe to assume that the ~800 bridges with two PTs support obfs2 and obfs3, which are likely the bridges we will want to distribute, and we only have 20% of that 800 that are not already allocated to the web and email distributor, leaving us with only ~160 obfs3 bridges to send in these emails. It might be good to start out providing only a few bridges to each person, and then we can easily increase the number they receive at a later point. If we separate obfs2 and obfs3 bridges then we'll be able to stretch these bridges a bit further, but I need to finish #9652 (moved) before that will be possible. We should also consider rebalancing the distribution of bridges if we are sending emails again. Currently 40% go to the web, 40% go to the email distributor and the rest are reserved for 'other' (such as these emails).
This isn't going to happen within the next week, but hopefully we will see these emails being sent before next year.
Whitelisting
(emailaddr, keyid)pairs it is, then.Changing the ticket title to reflect the new task.
Trac:
Status: needs_information to accepted
Summary: Revive the BridgeDB bridge-sending mailing list to Implement whitelisting of (email_address, gpg_key_id) pairs for encrypted, automated email bridge distribution
Cc: sysrqb, isis@torproject.org, arma, nima@redteam.io to sysrqb, isis, arma, nima@redteam.io
Keywords: email list distributor important deleted, bridgedb-email, bridgedb-dist added
Owner: N/A to isisThe whitelisting has been enabled in the config file, but it doesn't yet check GPG signatures on whitelisted emails. Instead, "whitelisted" mail goes through the same DKIM checks and timing interval checks as other providers, but it skips the
canonicalizeDomainName()check.We still need to implement checking GPG signatures before we allow whitelisted addresses to get a pass on DKIM. And we also need to implement encrypting responses to these addresses.
Trac:
Status: accepted to needs_revision
Trac:
Points: N/A to 2
Owner: isis to N/A
Sponsor: N/A to Sponsor19
Priority: Medium to Low
Status: needs_revision to assigned
Reviewer: N/A to N/A
Cc: sysrqb, isis, arma, nima@redteam.io to sysrqb, arma, nima@redteam.iomentioned in issue #10916 (moved)
mentioned in issue #12536 (moved)
mentioned in issue #12802 (moved)
