[Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

Carlo v. Loesch CvL at mail.symlynX.com
Mon Nov 18 22:49:30 UTC 2013


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.




More information about the Standards mailing list