[Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
Carlo v. Loesch
CvL at mail.symlynX.com
Wed Nov 20 12:53:55 UTC 2013
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 . Some
> more background at .
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 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 a silo, and it is the largest
platform for mail-like messaging. How many people thought "oh my god,
this isn't SMTP. this isn't standards-compliant" when they started
mailing over Facebook? Please do not mention the XMPP and SMTP gateways
they have for political correctness - they are strategically not very
relevant. Fact is, Facebook can introduce platforms that do not care
much for existing standards. Same story with the success of Skype and
Whatsapp. Even Mumble is a success although it cares not for SIP etc.
The idea that something that isn't standards compliant will be far less
relevant has no foundation in real world numbers.
> Open standards can be "reliably respectful of privacy". They do not
> necessarily contain any proprietary technologies.
Let's imagine Pond over Tor becomes an open standard. That means that
companies would make hardware devices that implement the Pond protocol
in a freedombox style. How will you be able to control that privacy has
Maybe for the future we can get companies to release deterministic build
procedures so the code can be audited. So hardware could be an acceptable
business model for privacy under these conditions.
Ok, but still the "open standard" is only good if there are no proprietary
implementations that cannot be freely audited and reproduced. That makes
it a lot less important than in the past. With the privacy threat at hand,
the "open standard" is a minor priority.
Open standards are especially bad for humanity when they are actually
not doing their job well and at the same time impeding the development
of new ideas and alternatives.. because.. hey, we have a standard.
OStatus is a formidable example - it standardized things that aren't
working properly at all. There isn't a single federated social networking
platform that actually scales and functions well enough to challenge the
likes of Facebook, and yet there is this hype of wanting to standardize
things that do not work.
> 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.
OF COURSE NO-ONE HAS DONE ANYTHING DELIBERATELY. Please don't distract
by implying accusations that are completely absurd. PSYC has been an
unencrypted and federated protocol for a long time, because in the 90s
I wouldn't believe that anyone actually is so respectless to hoover up
the conversation packets on the Internet. I thought all this chatter
about Echelon was just paranoid.
But nonetheless there is no reason to stick to old broken recipes in
panic the new ones could not find acceptance. It's funny how we are
frequently criticizing our politicians for not fixing planet Earth
and at the same time we are panicking at the idea of having to
obsolete SMTP and similarly architected things in order to introduce
the necessary degree of privacy. It's the same typically human instinct:
Conservation. We try to conserve what is actually way dysfunctional,
thinking that we can somehow get back to the good old times. It's the
same with the world economy and the energy and ecology questions.
And on top of that you can put plenty of special interest.
By not embracing the new and rather fixing up the old we are acting
just like politicians.
> 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.
Which to you seems like a line of argumentation but it actually
isn't. As if replacing a Jabber client (that requires you to set up an
account on a server etc etc) with an end-to-end communications tool which
is actually easier to handle, could be comparable to requiring people
to install a new operating system. Apples and oranges!
>> As long as there is a well-defined and reviewed GNU licensed codebase,
> Which license exactly? One which is interoperable with ASF projects?
I am in favour of AGPL as it protects people from proprietary
derivates that risk their intimacy and thus questions the entire
usefulness of the project.
On 11/20/2013 08:50 AM, Andreas Kuckartz wrote:
> Carlo v. Loesch:
>> 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
That is not the aim of #youbroketheinternet. It makes no sense to
insist on ease of use if the necessary confidentiality can't be
guaranteed. If we don't intend to secure the social graph, then we
don't need to start working on anything at all. XMPP already delivers
what you want, why bother.
> 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.
People install communication software in parallel all the time.
If they understand the goodness in a new software they will just
start using it with a selected number of people.. and person by
person that numbers will grow, just the way Facebook overtook Myspace.
It's the same with PGP and OTR actually: you can't do OTR with
someone that hasn't installed it. So the difference is only whether
you ask folks to install an add-on or a real new approach. The
effort is the same, the difference in results huge. That's why
inciting people to install PGP is bad considering they could be
installing Pond instead.
> 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.
That is a flaw in your thinking that you refuse to understand that
the privacy of the users is more important that your wish for legacy
>> 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.
Well, those are the wrong reasons. I doubt federation amplifies anything
and federated protocols do not protect social graph data and thus are
to be avoided. You can't ask a project to step back from the reason it
is being launched.
The reason Buddycloud is in there is because I presume it has some
UI lessons to share and Jitsi even more.
>> 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.
Buddycloud has no users compared to Facebook. You don't compete with
Facebook by playing their game. You have to re-invent the game. You
have to produce something which is so cool that people will prefer
it over Facebook. What is the restriction? That people have to install
a new software that provides them with cool new features? Woah, now
that is a restriction!
>> 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.
For companies and other organisations federation will probably continue
to be the standard. But for the respect of constitutional privacy
individuals should better move on. And mailing lists... well, I presume
I'm not the only one who will be SO happy when they can be replaced by
something more private and more democratic. Mailing lists are a pest.
>> 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.
Yes, our technologies use the Internet, too.
More information about the Standards