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. Reflections: The ecosystem is moving (Moxie Marlinspike)

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.

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. https://gitlab.com/hanno/ejabberd-config

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.