Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
In the last post I actually forgot to comment on the post I most agree with... On 11/19/2013 01:26 AM, Thijs Alkemade wrote: Federating over hidden services requires some extra work, but itâs not that hard. Iâve written a Prosody module for it, which can be found at [1]. Some more background at [2]. That's excellent news. Now the XSF should focus on migrating XMPP away from DNS/X.509 federation into the Tor network. There may be scalability issues involved however. Tor already offers forward secrecy, if I remember correctly it uses TLS with EDH. Unless you want to assert a clearnet identity, I don't see the added benefit of using TLS when accessing a hidden service. The key sizes aren't extremily high, that's why Jacob Appelbaum usually recommends to use an extra end-to-end encryption layer. He likes to use https over .onion and PGP over Pond. I personally think key size isn't the most important criterion - moving into Tor is a huge improvement for privacy. For s2s, you have the same solution as with most servers currently: dialback. .onion addresses being cryptographically verified makes this actually secure in this case. This would work even when federating between hidden services and normal XMPP servers (although the normal server needs Tor access, of course, and the hidden service must keep in mind to always use Tor to dialback). It's tricky because outside servers get connections from Tor exit nodes so they have to fully trust what the cryptography tells them and totally ignore where the packets are coming from. On Tue, Nov 19, 2013 at 06:14:23PM -0700, Jeremie Miller wrote: Carlo, I happen to working very hard on something that sounds almost exactly like what you're describing called telehash for many of the reasons you express, and once it's a little more functional I have a strong desire to demonstrate it working very compatibly/naturally with XMPP, of course :) I am familiar with TeleHash of course and wrote my $0.02 about it two years ago in the usual place: http://about.psyc.eu/Telehash - I'm glad you added encryption to the equation, but I still think you should - consider protecting transaction data (by using Tor for example) - that also liberates you from having to write your own NAT traversal - use a more advanced DHT implementation (check out GNS) - consider using a more efficient wire protocol (see http://lib.psyc.eu/bench/ for the performance shoot-out) - you may also want to consider many-to-many use case scenarios which you are currently not addressing If you don't intent to provide protection for transaction data and thus for the social graph, then there is nothing wrong with gatewaying to XMPP since the privacy assumptions are the same. I personally think systems that do not protect the social graph have this summer been proven to be bad for humanity - that's why I gave up on PSYC federation. But everyone has his or her own conscience. On 11/19/2013 05:29 PM, Andreas Kuckartz wrote: Carlo v. Loesch: 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, ... That is correct. Determining the social graph has for a very long time been one of the tools of all repressive regimes. THEN WHY OH WHY ARE YOU BY ALL VIGOROUS MEANS LOBBYING FOR FEDERATION AND NOT TAKING THE LOGICAL CONSEQUENCES!?!?!? Having followed recent discussions around #youbroketheinternet I fear that the second half of the sentence was not meant ironically. I definitely disagree with that best intentions statement. I merely think it is out of scope of this mailing list to question the actual motives behind our governments' actions. Whatever led them to do the wrong things they did, we can take legislational and technical measures to limit the damage. Unless of course activists are more busy patching up broken systems rather than setting up working ones. 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. I understand that #youbroketheinternet is not interested in interoperability and open standards. That is one reason why I am No, you didn't understand it. You are reacting to it as if it was just some folks' opinion like you have yours, but if you were scientific in what you think and do, you should either have a good reasoning to criticize those words or start acting on the basis of them being a fact. convinced that it will be far less relevant than some people hope it will be. Yes, just like Facebook is far less relevant. Facebook is the world leader in chat systems although it is
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
Carlo v. Loesch: 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, ... That is correct. Determining the social graph has for a very long time been one of the tools of all repressive regimes. #youbroketheinternet is only ironically pointing a finger, since we know that governments are operating in best intentions like everyone else.. Having followed recent discussions around #youbroketheinternet I fear that the second half of the sentence was not meant ironically. I definitely disagree with that best intentions statement. Different views regarding the motives of an attacker can lead to differences regarding attack models and defenses. 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. In case others are not yet aware: #youbroketheinternet is not only explicitly opposed to federation but not even interested in interoperability with federated communication networks. That is their decision but I do not think that this helps users. 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. I understand that #youbroketheinternet is not interested in interoperability and open standards. That is one reason why I am convinced that it will be far less relevant than some people hope it will be. Open standards can be reliably respectful of privacy. They do not necessarily contain any proprietary technologies. Maybe SMTP is bad due to privacy issues especially regarding meta-data. But I think it would be very wrong to underestimate the effect this standard has had in enabling worldwide communication using the Internet. And as far as I know the privacy issues were not built in deliberately. BTW: Both the Tor and the GNUnet projects even support users of Microsoft Windows while at the same time informing them that to Stop using Windows is important. As long as there is a well-defined and reviewed GNU licensed codebase, Which license exactly? One which is interoperable with ASF projects? Cheers, Andreas
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
[...] 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. In case others are not yet aware: #youbroketheinternet is not only explicitly opposed to federation but not even interested in interoperability with federated communication networks. There is the hypothesis that any federated network tends to cluster around a number of large nodes. E.g. for XMPP this would be gmail, jabber.org, jabber.ccc.de (applause to their efforts on making themselves unreliable!), ... Interdomain federation is hard, especially delivering the same user experience as between users on the same domain. I understand the rationale. I just don't agree with it.
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
Am 19.11.13 20:56, schrieb Philipp Hancke: [...] 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. In case others are not yet aware: #youbroketheinternet is not only explicitly opposed to federation but not even interested in interoperability with federated communication networks. There is the hypothesis that any federated network tends to cluster around a number of large nodes. E.g. for XMPP this would be gmail, jabber.org, jabber.ccc.de (applause to their efforts on making themselves unreliable!), ... Interdomain federation is hard, especially delivering the same user experience as between users on the same domain. I understand the rationale. I just don't agree with it. I don't agree with it either. What you end up having is silos that typically consist of proprietary technology with limited usability for the wider Internet user community. The benefits of XMPP are interoperability, the open standards process, and the large number of XMPP providers you can choose from. If you don't like one located in the US then pick it from some other country. If don't like any of them setup your own.
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/13 3:49 PM, Carlo v. Loesch wrote: snip/ Hi Carlo! I need to spend some quality time with your long message, but I don't have time for that right now. One quick point... 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. As you might remember, the original Jabber community was focused on code but also on defining and documenting an open protocol. There were no corporate interests pushing agendas (although some of the jabberd developers had some support from Webb Interactive Services), just coders making sure that clients and servers could interoperate. I think we need three things: open source, open standards, and an open community. In fact I wrote an article about it way back in 2003: http://www.onlamp.com/lpt/a/3660 But these days the threat model has changed and I think we need to go beyond merely open to trusted. Yes, trust is a slippery concept, but in my mind it's connected to things like hardware (e.g., PNRGs), build processes, transparency of releases, community governance, software that does what the user intends and no more, etc. This is something bigger than any particular technology, so this list might not be the best place to discuss it. Maybe a blog post or new discussion venue is in order... Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSi8mxAAoJEOoGpJErxa2pGIIP/3yupgKNsZDmeGFTCpiPh9jH jT67SKV+M/d8v0rBBoohvRY50IURnaMaoJQcPC4Y40yAASnUag9sfnhw5J1CI6W2 iilSdVd1O9j1btjDPyOiYSXfwiKWDLD1aODhgQpaZ02pYu0/8MJMVTUaxfRP+NMN YuVRizR/avRIwNt0Wq7WEfKYqR0xQ+uFEwzxhCctTbcI400P3f6zjt2FSUDig08J Uq0S/O9bK9FBzOo2krLqsiFx0NYdrjjpDi+RcAYPfZ6L1ShQtzBEziph8xer0olH 30O1NOZmJn6qE/kquR+L4FldgPyiXf+QmvUOpwuRpflU8CniWZpjJ82T6EoZYNTP 78nK8qL4o6cmUdFPT6YTKbgS9aIDyeZPTRt0901Ayj4EJQQLpqTTKMZcriymOWVA PUOJ4ghvtir9AyU4MGRtBNny/UrpJ7xmNP+bmz40NtQdrGLcrZTOnx2FAoPOG4Ec Ee0vgSfkbMryaEYSjXSi/rer8qSg39rvRAyJX50I6+IQc4K2V2WYLPkoL4qnYxs8 xfQXOVpFHAedDnY+gXy4DcIzXHR1AnQ8pe3+7+Hrp1Pizloy2oZLDCMbcW1Fg/5s 7PMbTs/E2U9s/5DLrF6/6M4pt2yi7ROrEN8rWIm23JXhSwjLcaEc8WoB1JKM0kPQ zQEqjyKa9LMg45QglJMV =C8IT -END PGP SIGNATURE-
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
Carlo, I happen to working very hard on something that sounds almost exactly like what you're describing called telehash for many of the reasons you express, and once it's a little more functional I have a strong desire to demonstrate it working very compatibly/naturally with XMPP, of course :) On Tue, Nov 19, 2013 at 4:30 PM, Carlo v. Loesch c...@mail.symlynx.comwrote: Oh.. I didn't receive some of the messages.. probably originating from Andreas.. strange. Again a multi-reply to avoid clogging the mailing list: On Tue, Nov 19, 2013 at 01:27:29PM -0700, Peter Saint-Andre wrote: Hi Carlo! I need to spend some quality time with your long message, but I don't have time for that right now. One quick point... lol! Hi Peter, was a pleasure meeting you this summer. As you might remember, the original Jabber community was focused on code but also on defining and documenting an open protocol. There were no corporate interests pushing agendas (although some of the jabberd developers had some support from Webb Interactive Services), just coders making sure that clients and servers could interoperate. The stuff I wrote wasn't specifically addressed, especially not at early Jabber. I know well that it was all created with best intentions. I wasn't happy about the choice of a document syntax for a messaging protocol, but the only thing I *really* complained about was the lack of providing a distribution strategy for larger recipient groups. I was just echoing basic things any IRC developer knows concerning multicast, but the Jabber community didn't believe the problem exists. So even today it's a problem to have more than a hundred friends on a federated XMPP network, then try to do social networking with them. The more time passed, the harder it got to tackle the problem, because by then there were companies earning money by selling scalable XMPP server solutions - a federation that actually scales properly would be detrimental to their business. Even if this maybe isn't how it actually went, it is a reason more why having corporations in the mix is bad for freedom. They can have an interest in blocking technologies from getting better, and they might be getting away with it by smart rhethoric and convincing representatives. This time however they are putting our civil liberties at risk, so we need to prioritize. Companies should be *users* of the Internet, not *owners.* But currently they are owning the majority of us. Again I'm not talking about the small players on this mailing list working to bring some earnings back home. I think we need three things: open source, open standards, and an open community. In fact I wrote an article about it way back in 2003: Back in 2003 I probably agreed, but by now I understand what Richard Stallman says when he's against open and underlines the necessity of free. I need no open source, no open standards, no open community. I want free software, free hardware and a free community. May sound similar but the political differences are actually big and the repercussions are being felt since June. But these days the threat model has changed and I think we need to go beyond merely open to trusted. Yes, trust is a slippery concept, but in my mind it's connected to things like hardware (e.g., PNRGs), build processes, transparency of releases, community governance, software that does what the user intends and no more, etc. This is something bigger than any particular technology, so this list might not be the best place to discuss it. Maybe a blog post or new discussion venue is in order... You just described what #youbroketheinternet is about. Somebody wrote: In case others are not yet aware: #youbroketheinternet is not only explicitly opposed to federation but not even interested in interoperability with federated communication networks. This reminds me of a word that I learned on this list years ago.. snarky I presume it is Mr Kuckartz writing, correct? For some odd reason I didn't get this mail. Anyway - it's a question of user expectation. You can't tell your grandpa that this is the first software that actually implements your constitutional right of secrecy of correspondence.. unless you add a friend via XMPP that happens to have her account on Google. It's too complicated. If you want to talk to people on Google use whatever tools you want to use - don't mix it up with a system that is supposed to give you completely different degree of privacy - and uses completely different technology to achieve that - so there is no technological advantage in supporting XMPP or SMTP anyway. It would be an add-on that breaks user expectations. No good. But if you look at the http://youbroketheinternet.org/map you can see several federation technologies in the upper right corner. Why? Because their expertise at designing web interfaces for social networking is still very welcome. We
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
Carlo v. Loesch: Somebody wrote: In case others are not yet aware: #youbroketheinternet is not only explicitly opposed to federation but not even interested in interoperability with federated communication networks. ... I presume it is Mr Kuckartz writing, correct? Yes, Mr v. Loesch, that is correct. If you want to talk to people on Google use whatever tools you want to use - don't mix it up with a system that is supposed to give you completely different degree of privacy - and uses completely different technology to achieve that - so there is no technological advantage in supporting XMPP or SMTP anyway. It would be an add-on that breaks user expectations. No good. One expectation of users is that they can continue to communicate with other people without much hassle. In some cases this is impossible to implement because terms of services of some proprietary platforms do not allow this. One reason for those ToS is to prevent alternatives from amplifying their network effects. Alternatives which are deliberately preventing users from communicating severely weakens network-effects which otherwise could work in favor of new technologies. If #youbroketheinternet is becoming somewhat successful then such add-ons will be created so it would be better to plan for that now. That #youbroketheinternet is not interested in that is a flaw in the concept and not in the interest of users. But if you look at the http://youbroketheinternet.org/map you can see several federation technologies in the upper right corner. Why? Because their expertise at designing web interfaces for social networking is still very welcome. We just need to replace the networking engine underneath. Hey, it even mentions Buddycloud. Yes, I had suggested to include buddycloud and Jitsi. But that was not simply because of their user interface but because they are using federated protocols and that including those projects would amplify network effects. They just need to see that XMPP is not the future neither for the necessary privacy nor for the necessary scalability to achieve what they intend to achieve: be a serious competition to Facebook. If that were the aim of buddycloud then restricting the social connections of users to those using #youbroketheinternet would be counter-productive and a guarantee for failure. No, I think it's in a wrong assumption of the federation principle, that you can trust your university, your company or your boyfriend better. Most people don't have any reason to trust anyone, so they pick what is likely to have the least interest in them personally - that's usually a large silo offering. In companies and other organisations it is usually those organisations deciding such questions and not the individual. And that is also true for smaller groups such as this mailing list using SMTP. But history repeats itself. When the first cars were developed, 90% of the engineers where probably focused on refining the efficiency of horse carriages. Motorized cars used the same road network as the horse carriages. People using the new vehicles were not limited regarding the set of places they could drive to by requiring them to use a new non-existing road network. The roads used by both cars and horse carriages were improved and only a long time later horse carriages were no longer allowed on many roads. Cheers, Andreas
[Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
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 ? Cheers, Andreas
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
IMHO, e2e security would probably make more sense as a XEP and working group that has the time to zoom into all the implementation details. S. On 18 November 2013 10:30, Andreas Kuckartz a.kucka...@ping.de 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 ? Cheers, Andreas -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
Hi, On 18 Nov 2013, at 13:07, Andreas Kuckartz a.kucka...@ping.de wrote: Simon Tennant: IMHO, e2e security would probably make more sense as a XEP and working group that has the time to zoom into all the implementation details. Can that be solved by an XEP ? What about this IETF draft? (I still have to read it) End-to-End Object Encryption and Signatures for the Extensible Messaging and Presence Protocol (XMPP) draft-miller-xmpp-e2e-06 https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e/ There exist people who mention XMPP as belonging to faulty technologies for which they want to create alternatives: http://youbroketheinternet.org/ And I try to find out what can be done to improve XMPP regarding security and privacy. Well you can “always” run XMPP on top of TOR if you like that, if it is the S2S routing that bothers you. :-) Cheers, Andreas On 18 November 2013 10:30, Andreas Kuckartz a.kucka...@ping.de mailto:a.kucka...@ping.de 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 ? Cheers, Andreas /Steffen smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
On 18.11.2013 13:38, Steffen Larsen wrote: Hi, On 18 Nov 2013, at 13:07, Andreas Kuckartz a.kucka...@ping.de wrote: Simon Tennant: IMHO, e2e security would probably make more sense as a XEP and working group that has the time to zoom into all the implementation details. Can that be solved by an XEP ? What about this IETF draft? (I still have to read it) End-to-End Object Encryption and Signatures for the Extensible Messaging and Presence Protocol (XMPP) draft-miller-xmpp-e2e-06 https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e/ There exist people who mention XMPP as belonging to faulty technologies for which they want to create alternatives: http://youbroketheinternet.org/ And I try to find out what can be done to improve XMPP regarding security and privacy. Well you can “always” run XMPP on top of TOR if you like that, if it is the S2S routing that bothers you. :-) 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. End-to-end encryption IMHO is a separate issue. It is currently in scope for the XMPP WG[1] at the IETF. I also doubt anyone will complain if it is discussed here, or on the XMPP-security[2] mailing list. I think currently our best bet is Matthew Millers E2EE draft. Though I have to say it's rather complex. It also depends on the JOSE work being finished. There is some hope though that implementations would be rather simple once JOSE implementations are readily available. Peter Saint-Andre has also repeatedly stated he is working with the OTR folks towards an RFC document describing OTR. A related issue I'd like us thinking about is trust, key distribution and switching devices in general. It would be good if we could come up with a way that allows each device to have its own private/public key pair, but not requiring users to trust each public key individually. Problems when switching resources during an encrypted conversations are also way to commonplace right now. I think if we want any acceptance these are issues we should try to solve. Regards, Florob [1] https://tools.ietf.org/wg/xmpp/ [2] http://mail.jabber.org/mailman/listinfo/security
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
It really depends what threats you are concerned about, Steffen. 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 Ciao Hannes Am 18.11.13 13:38, schrieb Steffen Larsen: Hi, On 18 Nov 2013, at 13:07, Andreas Kuckartz a.kucka...@ping.de wrote: Simon Tennant: IMHO, e2e security would probably make more sense as a XEP and working group that has the time to zoom into all the implementation details. Can that be solved by an XEP ? What about this IETF draft? (I still have to read it) End-to-End Object Encryption and Signatures for the Extensible Messaging and Presence Protocol (XMPP) draft-miller-xmpp-e2e-06 https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e/ There exist people who mention XMPP as belonging to faulty technologies for which they want to create alternatives: http://youbroketheinternet.org/ And I try to find out what can be done to improve XMPP regarding security and privacy. Well you can “always” run XMPP on top of TOR if you like that, if it is the S2S routing that bothers you. :-) Cheers, Andreas On 18 November 2013 10:30, Andreas Kuckartz a.kucka...@ping.de mailto:a.kucka...@ping.de 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 ? Cheers, Andreas /Steffen
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
On 2013-11-18 13:07, Andreas Kuckartz wrote: Simon Tennant: IMHO, e2e security would probably make more sense as a XEP and working group that has the time to zoom into all the implementation details. Can that be solved by an XEP ? What about this IETF draft? (I still have to read it) End-to-End Object Encryption and Signatures for the Extensible Messaging and Presence Protocol (XMPP) draft-miller-xmpp-e2e-06 https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e/ There exist people who mention XMPP as belonging to faulty technologies for which they want to create alternatives: http://youbroketheinternet.org/ 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! -- ralphm
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
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
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
On 18 nov. 2013, at 23:49, Carlo v. Loesch c...@mail.symlynx.com wrote: 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. Federating over hidden services requires some extra work, but it’s not that hard. I’ve written a Prosody module for it, which can be found at [1]. Some more background at [2]. Tor already offers forward secrecy, if I remember correctly it uses TLS with EDH. Unless you want to assert a clearnet identity, I don't see the added benefit of using TLS when accessing a hidden service. For s2s, you have the same solution as with most servers currently: dialback. .onion addresses being cryptographically verified makes this actually secure in this case. This would work even when federating between hidden services and normal XMPP servers (although the normal server needs Tor access, of course, and the hidden service must keep in mind to always use Tor to dialback). [1] = https://code.google.com/p/prosody-modules/wiki/mod_onions [2] = https://blog.thijsalkema.de/blog/2013/06/11/xmpp-federation-over-tor-hidden-services/
