Since I've kind of been summoned, some observations to several mails in a single reply.
On 11/18/2013 10:30 AM, Andreas Kuckartz wrote: > Peter Saint-Andre some time ago wrote: >> > On 7/16/13 4:27 AM, Carlo v. Loesch wrote: >>> >> Since XMPP isn't suitable for keeping meta-data private I would >>> >> presume that e2e privacy is out of scope for this mailing list, >>> >> really. >> > >> > True. > Where would the topic e2e privacy for XMPP be "in scope" ? That's the point, XMPP not being really suited to today's needs of privacy. > There exist people who mention XMPP as belonging to "faulty > technologies" for which they want to create alternatives: > http://youbroketheinternet.org/ #youbroketheinternet emerged out of the Social Swarm and GNU consensus initiatives since this summer we realized that it is not enough to just fix social networking. We need to fix the entire network stack. We consider transaction data security one of the primary aims we strive for for future communication technology. We didn't really detail why, but if you ask me I would say because if taken in on a global scale, social graph data gives you enough information to be a threat to liberty and democracy of entire populations. I presume you can find plenty of scientific analysis, if not regarding the Internet, then regarding the operation techniques of the "German Democratic Republic." The Stasi obviously being ridiculous compared to what we are experiencing today. #youbroketheinternet is only ironically pointing a finger, since we know that governments are operating in best intentions like everyone else.. unfortunately however some of them ignored all the constitutions, leading us on a slippery slope towards totalitarian control (that's why constitutions exist). > And I try to find out what can be done to improve XMPP regarding > security and privacy. What happened to Encrypted Sessions? I think it was something similar to OTR, but properly integrated to avoid typical failures like OTR trying to send over a channel which no longer exists and whose DH key exchange has long vanished. Still that is just end-to-end encryption and not very sufficient in the face of the global not-always-passive adversary. No surprise advanced users are using OTR on silo servers to avoid federation, and combine it with Tor. On 11/18/2013 01:53 PM, Florian Zeitz wrote: > On 18.11.2013 13:38, Steffen Larsen wrote: >> Well you can alwaysâ run XMPP on top of TOR if you like that, if it is >> the S2S routing that bothers you. :-) Not so simple.. S2S protocols expect you to have a well-defined domain name so it takes some tweaking to use a XXX.onion instead - especially if you'd like to have enhanced forward secrecy by embedding TLS: how the hell will you validate a .onion certificate? This would require a whole new XEP and a certification strategy to go with it. > I think we might actually have gotten to the point where stanza routing > is what bothers people. > I.e. having a to and from stamped on a stanza. I don't think it's > possible to get around the servers knowing this in XMPP. Between > servers, we hope encryption helps to hide this information. The reliability of TLS within servers is another large pain, but yes, the froms and tos are the problem and I am very doubtful of strategies that simply try to obfuscate those with temporary aliases. Onion routing has an advantage: it has been peer reviewed by the best financed cryptography institution on earth. On 11/18/2013 02:04 PM, Hannes Tschofenig wrote: > I briefly looked at a Mumble project, which uses IM over Tor, when it > was mentioned on the IETF perpass list. Here were my thoughts: > http://www.ietf.org/mail-archive/web/perpass/current/msg00215.html Let me cite from that mail. > I might be incorrect in my assessment. I found some information but it was > mostly irrelevant to make a good assessment about the security and privacy > properties about it. It's easy. Mumble uses a star topology with clients connecting to a server. It uses TLS with a persistent certificate. Clients pin down that certificate for all time and generate a client certificate for authentication with the server when asked for. If the user loses its certificate, the username is gone. Reserve a name and build up reputation. TOFU strategy on both sides. If an attacker wants to listen in, it needs to MITM the very first exchange. With Tor in the mix the model changes a lot, see below. > There seems to be the (wrong) believe that if you publish software as open > source then everyone can look at the code and the quality will be good. But it is also unfair to criticize software for not having been reviewed yet, especially if it solves problems that other software doesn't solve. In that case the criticism should read "This software could be interesting, somebody should finance a good peer review ASAP." We can't always wait for a whistleblower to show us material that tells us that the world's largest cryptography expert group wasn't capable of breaking it. > From what I can tell the software does not interoperate with anything else > other than their own silo, which is bad. That's inaccurate. Having no federation at least doesn't introduce yet another huge possibility for security problems and as long as you own the source code and aren't forced to use anybody's specific offering it is highly inadeguate to call such a software a silo. Facebook is a silo. Calling Mumble a Facebook is not nice. > If you use a provider that runs that VoIP service then you have to trust > him like with any other VoIP providers. Of course you can run your own server > but then your friends have to be on your own server as well, if I understood > it correctly. Yes, which so far hasn't been a big deal. Installation works with an apt-get command and a half, and then you just tell people where to meet for conversation. Why trust some "VoIP provider" ? This just has to get even simpler for regular folks. Have DSL routers with Tor and Mumble on them. > Maybe that's a great idea that everyone should have their own server and if > you want to talk to someone then they create an account at your server and > start communicating with you. Mumble isn't being used as a presence system usually, so you usually make appointments out of band - let's meet on server x at time t. Mumble hasn't solved the social presence scalability problem either, but at least it doesn't try to. > From the point of view what we are trying, namely to develop globally > interoperable VoIP solutions, this is obviously a step backwards (maybe 20 > years). Mumble offers bandwidth-efficient push-to-talk group conferencing. Something that VoIP has failed to deliver so far - but you are welcome to establish a standard and upgrade all the existing VoIP hardware. In my life I have installed SIP phones on my hard drive several times, but I don't recall ever successfully having a conversation with them. Always the hassle with accounts somehow somewhere and the federation protocols functioning even worse than XMPP (at least concerning firewall traversal etc). I hope this is all getting better, but still Mumble is there and, especially on Android, just works out of the box. Also in the face of personal privacy, what sort of goal is interoperability? Here we are at a point that PRISM has proven that it is nonsense to entrust companies with personal privacy. Even if they intend to do everything good - at some point the ownership will change or the government will knock at the door. There is no credible business model for privacy. By conseguence interoperability and "open standards" are no relevant goal: They were introduced in order to make companies have their proprietary technology speak a common language - but since proprietary technology by design cannot be reliably respectful of privacy, we must design our future communication paths free of proprietary contributions. That means that the protocol standards etc become a lot less important: As long as there is a well-defined and reviewed GNU licensed codebase, all applications can be made interoperable even if the protocol wasn't documented. Of course that is not recommendable and in fact a proper review implies documenting the protocol fully - but it is very distant from today's notion of necessity of a protocol standards body. A protocol can thus be driven by efficiency needs rather than lobby interests. Luckily there are always plenty of industry standards that need to get standardized, so there is enough work outside the privacy area. Tor is a good example of the new thinking. It has just recently split to a second implementation for Android - but until then it was just one, and hundreds of applications just use it. Tor is the protocol and the localhost socket is the API. It depends on hundreds of relay nodes and DHT servers to run, but if suitably configured, Tor will use a diverse set of relay nodes operated by different unrelated institutions, making it hard even for a global adversary to figure out where your data is flowing. Only a very characteristic flow of packets going in and out of the network risks of being correlated. And Tor is only the beginning. If you look at the specs for GNUnet and GNS there is a whole future of more advanced technology rolling along. > What is worse, in my point of view, is that adding Tor to Mumble may not > actually provide you any additional privacy/security benefits. If you trust > the VoIP provider than you could very easily create an end-to-end security > solution. Without Tor the other party would most likely still see the IP > address of your device (or the IP address of some NAT). That's what Tor > (or other tunneling technologies) could hide. The VoIP provider still knows > who you are talking with and, depending on how the details look like, he may > still be able to decrypt the VoIP communication. I have the impression you have a wrong idea of what the role of Tor is in this. 1. Tor allows people to run their Mumble servers at home. NAT traversal etc no longer a problem. 2. If the server is run on an .onion, Tor protects the physical placement of the server device - it is hard for any institution to figure out which home they have to visit. 3. For an undefined time period it might even be safe to be running the server on dedicated server hardware. Pervasive scanning of server hardware in computer centers may still not be in place. But that's just a question of time until servers are generally unsafe for private data. 4. Tor cannot hide that users are using Tor, and the characteristic bursts of push-to-talk traffic may even make it clear, that they are having an audio conversation - but the observer cannot tell WHERE they are having such a conversation and WITH WHOM. 5. Tor authenticates the server onion address, so there is no longer a TOFU scenario. The user can be sure she connected to the correct server and there is no man in the middle. Yes, the guy who runs the server gets to have all the audio data and probably knows who the voices are that are talking, that's why he should be a well-known member of the group. See why Mumble over Tor has an edge over old-fashioned VoIP technology? Since you are working in the VoIP business for a living, can I send you an invoice for giving you valuable insight into the future of the market? Would be better, if the middle node could be eliminated, and in fact we are planning for such an architecture in the secushare project. secushare implements multicast over GNUnet, which is just what it takes for a fully distributed push-to-talk conference system. Unfortunately Tor is by design unsuitable for multicasting, that's why we need a 3rd generation onion routing subsystem for use cases such as conferencing and social networking. Disclaimer: I am not involved with Mumble, but my company has produced push-to-talk chat systems using RTMP technology. In fact Mumble is pretty bad concerning usability and the implementation of audio mixing. On Mon, Nov 18, 2013 at 04:38:19PM +0100, Ralph Meijer wrote: > From a first glance, it looks like some PSYC proponents are involved > with this. Here is their stand on the brokenness of XMPP: > > http://about.psyc.eu/Jabber > > Also, hi fippo! I take responsibility for that collection of things that are well worth criticizing about XMPP. I always take feedback seriously to ensure that the page is accurate. I hope nothing is outdated. But since neither you or stpeter complained much last time I met each of you, I guess there isn't so much to say about it. XMPP is what it is, and it is being used anyway. No big deal. Best regards.
