Are decentralized services unable to innovate?
Hanno Böck
https://hboeck.de
Introduction
Hanno Böck, freelance journalist and hacker.
Writing for Golem.de and others, writing monthly Bulletproof TLS Newsletter.
Fuzzing Project, funded by Linux Foundation's Core Infrastructure Initiative.
Running free software friendly hoster schokokeks.org.
Signal
What Signal gets right
- Signal uses sane, modern and secure crypto.
- Signal is encrypted by default.
- Signal is free software (GPL 3).
Signal crypto
Combination of well understood technologies with smart innovations that allow forward secrecy in asynchronous mode.
Sane crypto isn't obvious. A lot of apps use very questionable crypto constructions (notably iMessage and Telegram).
Encrypted by default
Signal encrypts all messages. There is no fallback to unencrypted messages in any circumstance.
Signal problems
- Signal uses proprietary Google Cloud Messaging (GCM) service.
- Depends on proprietary Google libraries (can be replaced with gmicro).
- Signal account is connected to a phone number.
- Signal is not available in a free app store like F-Droid.
- If you fork Signal you're asked not to use Signal's servers.
- Signal does not federate.
Signal and Free Software
While Signal technically is free software it doesn't feel like free software.
You can change it, but then you're no longer welcome in the Signal ecosystem and can't send messages to other Signal users.
"[...] SMTP, IRC, DNS, XMPP, are all similarly frozen in time circa the late 1990s. To answer his question, that's how far the internet got. It got to the late 90s.
That has taken us pretty far, but it's undeniable that once you federate your protocol, it becomes very difficult to make changes.
XMPP
XMPP and End-to-End encryption
- Old OpenPGP encryption (XEP-0027, obsolete, no signatures, no FS)
- OTR (not exclusively for XMPP, FS, no offline messages)
- ESession (XEP-0116, obsolete, FS, no offline messages)
- OMEMO (XEP-0384, FS and offline messages)
- New OpenPGP encryption (XEP-0373, no FS)
- Soon: OTR v4
Do you know XKCD 927?
Plaintext
XMPP has a wide variety of encryption technologies, yet none of them is the default.
In practice applications will often fall back to plaintext.
Is Moxie just right?
OTR (v3 and earlier)
Never standardized and doesn't play well with existing XMPP features.
No offline messages due to forward secrecy, which means most OTR implementations fall back to plaintext.
Lack of offline messages means it's impractical as a default encryption mode.
OMEMO (XEP-0384)
OMEMO (XEP-0384) uses Signal-like crypto (forward secrecy, but offline messages still possible).
Needs server support.
Client support is poor (only Conversations and Gajim).
Probably most likely candidate for standard encryption.
Variety isn't stopping
XEP-0374 (new OpenPGP for XMPP) contains justification why this standard exists alongside OMEMO (message archiving), but it feels like a poor justification.
Similar feature could be achieved by separating message and storage encryption.
And one more...
There's now OTR v4 in development.
It's about choice?
There's a widespread idea that choice is always good.
Is it good to idealize choice and sacrifice interoperability and security?
Choice? Always?
HTTPS by default and HSTS is bad, because people should have the choice to be insecure?
Should OpenSSL have an option "enable_heartbleed_bug"?
Should we have X different encryption methods and fall back to plain text every time we can't agree?
Attempts to bring XMPP forward
Encryption manifesto
There was an attempt to push transport encryption (TLS, not end-to-end) to the XMPP network in 2014.
This seems like a good idea: Get software developers and server operators to agree on network improvements.
Encryption manifesto problems
Many things optional - not changing the default.
Some of the recommendations are outdated (SSLv3).
Some are contradicting each other (mandatory to implement vs. forward secrecy).
The manifesto was signed by many software developers who didn't implement the recommendations in it.
Can we agree on modern XMPP?
XEP-0375: XMPP Compliance Suites 2016
Only prosody is currently able to fully comply.
This does not contain any End-to-End-Encryption.
Gamification
Source: xmpp.net
Defaults and documentation
Often efforts are made to establish modern XMPP features, yet they aren't enabled by default, aren't always available and are not well documented.
If you run ejabberd: We're sharing our server config file.
Complexities
Protocols often have implementation complexities that you don't want to inflict upon users.
Separation of account and software
This is a concept often inherent to decentralized services, yet it's highly counterintuitive.
Show Diaspora
Run your own infrastructure?
The community around decentralized services often prays the "run your own infrastructure" mantra.
There are people who can't (skills) or shouldn't (security risk) run their own infrastructure.
You can get the tools to run your own infrastructure
versus
You should run your own infrastructure
It's totally okay to say people should be able to run their own infrastructure and get the tools to do so, but not everyone should necessarily do it.
Abuse management
Challenges with abuse management
Centralized and proprietary services have considerable advantages when it comes to abuse management.
For example: Phone numbers cost money and are often tied to real-life identities.
Abuse management often relies on big data.
We haven't figured out a good way to tackle this.
The web
The web was stuck in the early 2000s.
Microsoft had just pushed all browser competitors out of the marked, Internet Explorer 6 had a quasi monopoly.
IE6 lacked support for many modern CSS features, yet development of IE had basically stopped.
The web is thriving
The web has some advantages
The situation is often considerably simpler: A server and a client.
In many cases the server doesn't even need any software support for modern features.
Browsers have well-funded, highly qualified development teams.
Sometimes fallbacks are less problematic
HTTP/2, Brotli compression, WebP images and many other modern web features are performance improvements.
It's okay to support them opportunistically - use them when they're there, fallback to older technology (HTTP/1.1, gzip/deflate/no compression, PNG/JPG images).
The same isn't true for security features. Fallbacks have security implications. ("Use crypto if it's there, fallback to plaintext if not.")
Changing defaults is hard even for the web
A considerable amount of effort has been put into making HTTPS the default.
With HSTS we have a mechanism to set defaults for certain domains.
We're not even close to disabling HTTP.
Takeaways
- Innovation in decentralized networks is possible, but it's hard.
- Idealizing choice can mean sacrificing security and interoperability.
- "Run your own infrastructure" should be an option, not a requirement.
- Abuse management is an unsolved problem.
A final comment on the Signal debate
Yelling at Moxie probably won't help.
Nobody is stopping you from creating a messaging system as secure as Signal, but at the same time free of proprietary dependencies, decentralized, federated and whatever else you wish.