crackedactor@xxxxxxxxxxx wrote: > ----- Original Message ----- > > > On Wed, Aug 16, 2006 at 08:59:12PM +0000, crackedactor@xxxxxxxxxxx > > wrote: > > > > > > On Wed, Aug 16, 2006 Nick Mathewson wrote: > > [...] > > > Are you argueing with this definition of INVALID as opposed to the > > > original "Unverified" definition? Or are you now informing us that > > > for some whole now the term "unverified" has always mbeen > > > meaningless? if so for how long has this been so?) > > > > Hm? No, they both meant "attested to as likely to be ok". In the old > > days, directory authorities attested to servers as ok when they admins > > told them to, and the admins told them to as they got mail claiming to > > be from server admins. We thought that this was a bad idea and > > created a false sense of security. Now, directory authorities attest > > to servers as ok when the servers seem to be running, and the admins > > have not told them to consider the servers suspicious. > > > > OK currently what Mr Dingledine is saying is that INVALID "means pretty > much nothing to Tor". > > The problem is when I started as a Tor op (2 or 3 years back) I remember > (possibly the eff Tor site) seeing blurb about the "verified" operators. > Even today for the new term invalid the eff site reads as follows: > > "AllowInvalidNodes entry|exit|middle|introduction|rendezvous|... > Allow routers that the dirserver operators consider invalid (not > trustworthy or otherwise not working right) in only these positions in > your circuits. The default is "middle,rendezvous", and other choices are > not advised." I think most of us would read the word TRUSTWORTHY as > implying some sort of security/verification. I don't see the problem here. The option is called "AllowInvalidNodes" not "DoNotOnlyUseTrusworthyNodes". You can't assume that every node not marked as invalid is trustworthy. > > [...] > > > >Because "Verified" was a stupid name. It implied that we had a good > > > >way to go out and tell whether a node's operator was honest, > > > >upright, and competent, and whether the node was physically secure > > > >and non-eavesdropped. > > > > > > > It implied you at least knew who they said they were (not that you > > > knew they were what they said). > > > > Though that's what it meant in practice, that's not the interpretation > > of "verified" that I'd have made. Moreover, it's not IMO a useful > > property to have. Knowing who the adversary claims to be is only > > effective against an adversary who can't or won't lie about who they > > are. > > > > But it was better than NOTHING. > > Today you have absolutely NO safeguards whatsoever. ANY country can > flood their tor entry/exit server lists with high bandwidth snoops which > will guarantee tor is pretty much useless. But the users will never be > alerted to that fact and believe they are protected. No attempt is now > being made to disadvantage these snoops, even by a simple registration > process. I don't see how a registration would disadvantage "high bandwidth snoops". > I might just do that fork after all. Is there anyone out there who is up > for a fork? Any devs? Any servers?. > > Proposals for the fork... > > > Bring back - > > Level 1. Verification. - Personal visit to server with verification of > isp/org You would loose most of the running servers without solving any problems. For example I have no physical access to my Tor server. Even if I had and would be willing to let others inspect the whole server including all my private data, what would stop be from enabling a sniffer after the inspection is over? Are you intending to make daily visits without further notice? After all, reinstalling a clean image is a matter of minutes. > Add - > > Level 2. Registration - Web page based registration, Nic, contact email, > server id, proposed services desc, actual name and address verified by > web page credit/debit card transaction. It'll cost you a dollar or two > but that its. Again, I don't see the point. Good guys aren't the only ones with "actual name and address". Some of them might even have fake ones that can't be easily detected. > Retain - > > Level 3. Validation - as is - anyone who can muster a server If "mustering" includes access to the Tor server's keys, that would probably make the system less secure. You no longer have to run your own spying node, you just collect all the keys of the other ones. > 3. User friendly urls for Tor internal websites. They are cryptic for a reason. It's documented some where in the wiki. > 4. Free external (slowest) gateway nodes (no client required) into > Torland. (hw.xxxxxxxx.tor) I never used any, but I think there are already some onion gateways available (limited to http I believe). > 5. Multi-level performance for tor servers. > > Other possibles: include packet random size padding node to node, random > packet transit delay/position node to node, random packet multiplexing > (between big pipe nodes only). I don't think the Tor network could currently handle random packets, but I agree that it would be a nice feature. Fabian -- http://www.fabiankeil.de/
Attachment:
signature.asc
Description: PGP signature