[tor-dev] Proposal: Stop giving Exit flags when only unencrypted traffic can exit

[Tom van der Woerdt]

Op 05/01/16 om 10:22 schreef Tim Wilson-Brown - teor:
> 
>> On 5 Jan 2016, at 19:33, Tom van der Woerdt <info at tvdw.eu
>> <mailto:info at tvdw.eu>> wrote:
>> ...
>> Op 05/01/16 om 02:15 schreef Tim Wilson-Brown - teor:
>>>
>>>> On 5 Jan 2016, at 11:29, Tom van der Woerdt <info at tvdw.eu
>>>> <mailto:info at tvdw.eu>
>>>> <mailto:info at tvdw.eu>> wrote:
>>>> ...
>>>> 2.1. Exit flagging
>>>>
>>>> By replacing the port 6667 (IRC) entry with a port 5222 (XMPP) entry,
>>>> Exit
>>>> flags can no longer be assigned to relays that exit only to unencrypted
>>>> ports.
>>>
>>> One consequence of this proposal is that relays that only exit to 443
>>> and 6667 will lose the Exit flag.
>>> But these relays do exit to an encrypted port, so this somewhat
>>> contradicts the goal of the proposal:
>>> "Exit flags can no longer be assigned to relays that exit only to
>>> unencrypted ports."
>>
>> ...
>>
>> (tlcr: any relay that currently holds an Exit flag and allows exiting to
>> 443 and 6667, but not 80 or 5222.)
>>
>> tiggersWeltTor1 Bandwidth=2600
>> smallegyptrela01 Bandwidth=22
>>
>> These two relays will be impacted, indeed.
> 
> Point taken!
> 
> How many Exits would lose the Exit flag intentionally based on this change?
> (That is, how many have 80 & 6667, but not 443?)

If we change 6667 to 5222, this changes (where 0->1 means it will become
an exit and 1->0 means it will no longer be one) :

  FruityOatyTorexit Bandwidth=17700 0->1
  Alice Bandwidth=25 0->1
  tiggersWeltTor1 Bandwidth=3100 1->0
  onionnetGOT01 Bandwidth=387 0->1
  icubdw2o2xipsdc Bandwidth=137 1->0
  miepernl Bandwidth=1420 1->0
  ReservoirPi2016 Bandwidth=114 0->1
  TORWeazel Bandwidth=98 0->1
  HelloWorld Bandwidth=820 1->0
  smallegyptrela01 Bandwidth=22 1->0
  AnonNodeFin69 Bandwidth=80 0->1
  Serveur Bandwidth=703 0->1
  Biverse Bandwidth=779 0->1
  comaTor1 Bandwidth=148 0->1
  Unnamed Bandwidth=138 1->0

Gained bw: 20034
Lost bw: 5637

Tom


(source of this data: https://paste.debian.net/360256/)


> 
>>>
>>> Why not make the rule: "at least one of 80/6667, and at least one of
>>> 443/5222".
>>
>> Also sounds good to me. I opted for the smallest possible change
>> (6667->5222) but what you're suggesting lgtm.
>>
>>>
>>> I am also concerned about the choice of XMMP "because the XMPP protocol
>>> is slowly gaining popularity within the
>>> communities on the internet".
>>> Shouldn't we focus on secure protocols that are widely used right now?
>>>
>>> Alternately, we could add other widely used SSL ports in addition to
>>> XMMP, and perhaps increase the rule to "at least two SSL ports".
>>
>> Imho the challenge is in finding port number(s) that accurately reflect
>> what Tor is for, while also having a sufficiently large user base for it
>> to be relevant. XMPP probably has more users than IRC, and is a good
>> match for what I think Tor would consider important (communication).
>> Also note that we now have Tor Messenger. Other protocols (SSH, IMAP,
>> POP3, SMTP) are indeed more popular but I feel that those less reflect
>> the goals of the project, and they are certainly abused more.
> 
> 80/443 get us anonymous web browsing, primarily through Tor Browser
> 6667/6697 get us anonymous messaging via IRC
> (I don't know if 6697 is common enough to be worth changing for.)
> 5222 get us anonymous messaging via Tor Messenger
> 
> I can't think of any others right now.
> 
> Tim
> 
> Tim Wilson-Brown (teor)
> 
> teor2345 at gmail dot com
> PGP 968F094B
> 
> teor at blah dot im
> OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
> 
> 
> 
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160105/b21deef0/attachment.sig>