-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/09/2013 08:09 AM, 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.
Yes. If anyone has a knowledge of some method (even theoretical research) that could be used for that, I would be more than happy to help adapt it to RELOAD. > > 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] > <mailto:[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] >> <mailto:[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<hannes.tschofenig@__gmx.net >> <mailto:[email protected]>> wrote Mon, 09 Sep 2013 11:26:39 >> +0300: >> >> | http://www.tschofenig.priv.at/__wp/?p=997 >> <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 >> <https://en.wikipedia.org/wiki/Mumble_%28software%29> [1] >> https://trac.torproject.org/__projects/tor/wiki/doc/__TorifyHOWTO/Mumble >> <https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Mumble> >> [2] >> https://guardianproject.info/__2013/01/31/anonymous-cb-radio-__with-mumble-and-tor/ >> >> <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) iQIcBAEBCAAGBQJSLeoMAAoJECnERZXWan7Ez2MP/ieorluowEjef33uWOvHnAxq rdz0u40hm43mkgDwWkVgPbs3yfzjo3ihGktUuJ26E3Jc8I/yLl2kvtBXIf5OOkb3 BfrjpDpfSMXUJarSZIk1/obH4ydClXZV7xPby3hg6qvBPYzHe6duTtYo5mI6L0TA vKCukG1aZqDcvfwnXRLt8RtizN7hsrqXGkarzKr70FVG53PmIMULjEqAst/zeU8c wUfp2nXoQz56bmop2SRONA+ivAqMmRMgPMVFNE7444ckymYlXUjWUO/i9GFEDAAe Oij9Fmos9WUkzX6yV3BysP7ro8/9g+usRRF5nhOmnAwkgaJ1ZOOXexytNLpiRMJL ualBjmAmKDrRnk2+M8/nlpP0RO1fw3FgTLi6ydO56iZBlMp0QtkJS0E7tJoCNKcw 4/ILK4ZCJHyO2dbGPjxUMQFq0xDzLg8pjbZn6aGDfwPKDq9IarcsVVup+D0MRO/6 hDbLYDIqOx4Kwzr/YBG/IT/3PMXRLEK7yVATy2Vt3/4CEEkQcjYyEyXeIUOFiutF cadMfCuJoooMKWmcJJe5C4UYArr2LVz8OBe+gqCBr24hRQ4ybehWHXjquWxbOlfM Tnn5COU7r8E1CkBBt4oAXqEM3Fz1jN1JR9Zx3P8zAEPKx7rF6IHoZACUauxDPWIh yus8YslnMJb8RKf5jl6S =7pYq -----END PGP SIGNATURE----- _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
