-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/09/2013 08:30 AM, Stephen Farrell wrote: > > Hi Brian, Dean, > > RELOAD [1] is a bit of a gigantic spec though but I agree could be > promising in this space. I wonder if anyone might be interested enough to > write a draft saying how to use RELOAD to be more privacy friendly?
I wrote a draft adapting some of the ideas of TOR to RELOAD: http://tools.ietf.org/html/draft-petithuguenin-p2psip-reload-anonymous-02 That was presented in Atlanta: http://www.ietf.org/proceedings/85/slides/slides-85-p2psip-1.pdf Interestingly the reason for this draft was not end-user privacy, but to prevent commercial entities to discovers competitors' customers in the context of VIPR. > > I've no idea if that'd be easy or a huge amount of effort for someone who > already knows the protocol, but I'm pretty sure it'd be a major task for > someone starting from scratch. > > S. > > [1] http://tools.ietf.org/wg/p2psip/draft-ietf-p2psip-base/ > > On 09/09/2013 04:09 PM, Brian Rosen wrote: >> I'm still worried about the role of the enrollment server. If it got >> compromised, then mischief would be possible (you may not know who you >> are talking to). I think MITM would be hard. >> >> I think we need to come up with a new way to come up with credentials >> that is less dependent on servers that are subject to co-opting by the >> authorities. >> >> It's a HECK of a lot better than conventional VoIP though. >> >> Brian >> >> On Sep 9, 2013, at 10:46 AM, Dean Willis <[email protected]> >> wrote: >> >>> I think we can mostly get there with RELOAD, but the implementations >>> are still pretty early. >>> >>> On Sep 9, 2013 6:53 AM, "Hannes Tschofenig" <[email protected]> >>> wrote: Hi Linus, >>> >>> thanks for the comments. >>> >>> I have indeed skipped that topic. I will have to read into the Mumble >>> project to see what security and privacy guarantees it provides. >>> >>> My current conclusion from using VoIP/IM systems without using Tor is >>> that you cannot really protect against collecting this transaction data >>> (i.e., you have to at least trust the two VSPs, our own and then the >>> VSP of your communication partner). While you can influence routing of >>> the data traffic to a certain extend it does not work too well when >>> your VSP is working against you. >>> >>> With IM you could at least set up your own server (e.g., by using an >>> XMPP server) but with VoIP that's more complicated because nobody else >>> will accepted your connection attempts (as explained in the >>> interconnection part of my write-up). >>> >>> I will come back to you on that issue. >>> >>> Ciao Hannes >>> >>> >>> On 09.09.2013 14:31, Linus Nordberg wrote: Hannes >>> Tschofenig<[email protected]> wrote Mon, 09 Sep 2013 11:26:39 >>> +0300: >>> >>> | http://www.tschofenig.priv.at/wp/?p=997 | | It contains a number of >>> recommendations, which are addressed to VoIP | providers and vendors >>> but have to be enforced by data protection | authorities. | | The >>> recommendations unfortunately highlight some challenges... >>> >>> Indeed. And still, I miss any mention on protection against collecting >>> data about who's talking to who. >>> >>> Without claiming any expertise at all in this area, the closest thing >>> to something implementing this that I've heard of is Mumble over Tor. >>> Mumble [0] is not standardised AFAICT. The Guardian Project wrote [1] >>> about this earlier this year. Some people seem to use it [2]. >>> >>> [0] https://en.wikipedia.org/wiki/Mumble_%28software%29 [1] >>> https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Mumble >>> [2] >>> https://guardianproject.info/2013/01/31/anonymous-cb-radio-with-mumble-and-tor/ - -- >>> Marc Petit-Huguenin Email: [email protected] Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCAAGBQJSLe90AAoJECnERZXWan7Es9IQAMoFgmtizT8jr/3B6QiD2v7B wKAGTMCW13MdiTXPBl7hOR2gLTwNzDDA4GYGe0o+HMLKCvaIvLeV8W0CnNdFBRll LXPxiTAm5A6t+aNTOi5Bl+GhA/ilvJZjXAyOHC8rUbhdIK46VQTNoEBixGIaC+BK /n6+1qngQ7FMxktSwBzpHcxU5ACm0UM0jU7bGS1xACVgxJyBxGg3tk818lYD+4P9 mMlOC/vp/bNdYoOlBq0IaTpcAKuLWme3xsfavaTG7zk5PQHhfgs9ZWkx0YYSUepk z3tDeKM54/8OB4ZXgfWWBvAOd4gaquH3CXmX1rr4saqE5lrtc49meYzPwU9thn2J iSGet3/K+3PylgG5gmKtNzyk4cp4MBV+If1ypsy9k1T3I93eaV7YV2r0+Xs3q+tw oVTQrKr6oISDlEDfj1/O9CHoF7RflN88dXHI+ZBn/hzLKAAb73/qlyZ5QAP4L1dK xxMrTob0X/ZPO9lVZc6kAZVcgfRJqNkBNG5kfqr18Fh1+5Apeek370ta/4SSQI8X 7PmQFSyE7rZbphkEZxdpz2Dyncss5arbakyLgd3i2ekSC44AX5pf/B8z/li69YHA Bu3QwfwYZWdKUseaPoyYaE6VqDndiOTHOxc04/XaJogARbZCg59fkQgArtOBPATw IwJcEkoA7TOI+YFLKTXK =/F/b -----END PGP SIGNATURE----- _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
