[tptacek]

This topic has been beaten to death on HN over the last year (other people can provide links to discussions, with Moxie participating).

I think something worth keeping in mind is that almost everyone who works in secure messaging agrees on one thing: that electronic mail is not the future of secure communication.

There's no fundamental reason why that should be the case. The store-and-forward model used by SMTP could be made to work for asynchronous secure group messaging. You can get forward and future security with it. It can interoperate with existing email addresses. All of that can be made to work.

But it is the case. Email won't be a secure group communication system. The reason for that is that email is federated and thus permanently mired in the lowest common denominator of mainstream email clients.

I think reasonable people can disagree about whether it's tractable to create a federated secure group messaging system with what we know right now. But I do not think it's reasonable to suggest that the concern (federation = lowest common denominator security) is invalid. And that's what this piece does.

[Arathorn]

"lowest common denominator" security is not necessarily that bad, as long as that denominator ends up being a relatively high value and there's a way to ratchet it upwards overtime (by excommunicating obsolete/broken implementations).

My assumption with Matrix is that if some fatal flaw is found in the Olm/Megolm E2E implementations, we'll work with the major clients/bots/etc to implement a (if necessary) incompatible fix... and fork the community. Folks stuck on old insecure conversations will be isolated and shamed into upgrading - much like insecure HTTPS algorithms get killed off by pressure from browser vendors.

Yes, this process takes longer than a centralised solution which can flip the switch serverside and then worry only about upgrading all the apps, but in exchange you get freedom, as well as some level of security.

[tptacek]

That's the problem: there isn't a way to ratchet it up over time. It stays anchored at the lowest common denominator. It's tough to find counterexamples; see, for instance, the waking nightmare that is the XMPP ecosystem.

Obviously, email is the best case in point. There's been a decade and a half of concerted effort to get some baseline level of crypto security for email, and all of it has run aground on the installed base of dumb email clients.

To believe we should be cavalier about the risk of this happening again is to assert that we know enough now not only about how to design a secure group messaging system, but also how to safely implement it, that we should freeze the current state of the art in amber by standardizing it.

Personally, I can resolve this for myself quickly. I log into my Linux server, type "man 4 random", see that we can't even properly standardize the secure way to generate a random number, and quickly conclude that I'd rather use a single system that Moxie and Trevor are actively designing and evolving than adopt the consensus protocol of a menagerie of different unrelated messaging projects.

[Arathorn]

Firstly, I completely agree that it's easier to flip a centralised switch, make an incompatible change to fix a security issue, and force all their clients to upgrade to continue working.

However, I don't think that decentralised solutions have to end up in the worst-case scenario we see with SMTP (or even random(4)), or the medium-case nightmare of (say) phasing out SHA-1 TLS certs. There's a spectrum of nightmare here, and you can engineer both the tech and the governance to enforce a culture of security awareness and aggressive upgrading until things move fast enough. In practice, this means:

* Set a cultural precedent that obsolete clients are a bug, not a feature, and should be killed off or upgraded.

* Ensure that the most popular clients are actively supported to implement security features. If necessary, the standards body itself should get off its ass to do the work in order to protect the integrity of the ecosystem.

* Set a cultural norm of shaming users and developers who don't upgrade for security features - the same societal pressure that generally stops people wandering around in public if they're covered with chickenpox.

* Enforce it in the largest public communities of the ecosystem - in Matrix, this would be #matrix:matrix.org and a bunch of other huge >5000 user rooms, where if one day we had to make an incompatible protocol change, it'd suddenly be abundantly clear that folks on old clients would be excommunicated until they upgraded. We believe that users would rapidly find a way to switch client or encourage their developers to upgrade if it meant they were no longer able to participate in the biggest rooms!

* It's obvious, but: layer the protocol so that functions can be swapped out easily, just as Matrix allows arbitrary future E2E protocols in addition to today's m.megolm.v1.aes-sha2.

SMTP's woes stem from innocently trying for backwards-compatibility at all costs; not layering the protocol; having no governance model or culture which shamed ancient or obnoxious MUAs into being abandoned or fixed.

Slowness of SHA-1 phase-out in HTTPS is more the community again being conservative about backwards-compatibility, and a rather cautious attitude from the browser vendors in deploying the upgrade due to fear of upsetting everyone's expectations that The Web Never Breaks. Again, if you had more of a willing attitude that sometimes there's a security disaster and everyone has to upgrade (assuming that the software mechanisms are in place to upgrade and you haven't baked into hardware etc), perhaps people would be more willing to move faster.

So, with Matrix, we're trying to instil that attitude from the outset, whilst ensuring that the tech can support it. Time will tell whether it will work :) Better worth trying than to give up on federation and decentralisation entirely, though: privacy has no value without freedom.

[ddevault]

"non-federated" and "secure" in the same sentence is a joke. Signal's other problem is Google Play Services which has absolutely no place in a supposedly secure system.

[ajamesm]

Federation concerns availability, not security. "unplug the ethernet and write plaintext to /dev/null" is extraordinarily secure and 100% decentralized, though badly unavailable.

[Forbo]

It can also affect security depending on what jurisdiction the servers fall under. Federation means that while it may be illegal to run the service in, say, China, it can be run elsewhere without those concerns. This is becoming more apparent with the widespread use of National Security Letters.

[ajamesm]

Sorry, am I missing something? It's my understanding that Signal is ETE encrypted. All an NSL would get you is ciphertext and metadata.

[Forbo]

The scenario I'm imagining is that Google and OWS receive NSLs requiring them to push a modified APK that could do nefarious things.

[haffenloher]

This is a common misconception: NSLs are a legal tool that can be used to extract certain types of information (such as subscriber information and maybe a little bit of transactional information) that a service provider already has stored on their servers [0]. However, they cannot be used to force a service provider to write and deploy code.

[0] NSLs are not magic - https://www.youtube.com/watch?v=YN_qVqgRlx4&t=20m16s

[sliken]

Google can't push a new Signal APK, it's signed by OWS, not google.

3rd parties can download the signal source and compile it. Not sure if there's enough information available to product a bit identical (and thus verifiable binary).

I guess a NSL might compel OWS to push a binary specifically for a targetted user. If that's in your threat model you definitely need to take additional steps.

[x0x0]

Google/Apple could also receive a NLS ordering them to write and install a keylogger on your specific device in their next OS update. There's really not much you can do about that.

[hkt]

This does somewhat break Signal's security model..

[sliken]

Why? Google doesn't know who you are chatting with, or even the size of the messages you are sending. Google just sends a "wake up signal and check for messages". That's it.

[Sir_Cmpwn]

Keep reading the thread.

[tptacek]

Your argument on this thread is incoherent. You begin by suggesting that GCM is problematic because it's a component of a larger platform library that gives Google control of Android phones. When it's pointed out that GCM push can be supported without that platform library, your argument shifts: it's the messages themselves that are dangerous. When it's pointed out to you that the messages are empty, you invent a scenario in which GCM push messages enable a kind of traffic analysis that on-the-wire traffic analysis can't already accomplish.

Were this my argument, rather than pointing me to a thread where my points were continually and reliably refuted, I'd take this opportunity to instead restate my argument clearly.

[Sir_Cmpwn]

I think you're misinterpreting my arguments because it suits your preconceptions if that were the case. GCM is not just client code. I clarified when someone said the client could be replaced.

[tptacek]

Same issue, and here's Moxie himself on it:

https://news.ycombinator.com/item?id=13054940#13056554

[tptacek]

Signal's use of GCM has also been beaten to death: it's a platform issue that has no impact on security (but does make it harder to deploy Signal on nonstandard Android platforms).

[Sir_Cmpwn]

That is not true. It's (1) a remotely exploitable rootkit and (2) a tracking system that's (3) operated by a multi-billion dollar company whose entire business model is invading your privacy.

Google Play Services is not the standard Android platform. AOSP is the standard Android platform.

[dublinben]

You're conflating GCM and the wider Google Play Services that is installed on most Android devices. As someone who actually uses AOSP without Google, it weakens your argument when you conflate the two.

[Sir_Cmpwn]

GCM depends on Play Services, so I'm really not.

[dublinben]

GCM is merely one minor component. The existence of the microg project proves that you can implement one without the other.

[zimbatm]

If browsers are able to deprecate old encryption layers I don't see a reason why matrix client wouldn't be able to do the same. And as with browsers, if the clients or servers don't get upgraded then at some point they will stop working.

[meredydd]

That is only possible at all because web browsers are an oligopoly. There are only four organisations whose opinions matter, so they can coordinate to make breaking changes. (Even so, SHA1 deprecation is happening 1000x slower than, say, Whatsapp's rollout of E2E encryption.)

This level of oligopoly would not be tolerable to those who want to federate Signal-like apps. The whole point is to make it practical to use a small operator that's not such an easy target for one government's intervention (eg an NSL). But that ecosystem looks much more like email than web browsing - diverse, but fragmented, and impossible to upgrade in this way.

[Arathorn]

In the end it's a governance problem. If you create an ecosystem which sets a precedent of taking security seriously and thoroughly excommunicating insecure clients, netsplitting them out of the mainstream, then I think you'd see a lot more interest in client vendors and users routing around obsolescence and upgrading to whatever the current best practices are. This is particularly nice if the protocol is designed to let you enforce this, by ratcheting up to new versions.

Email never had this, and it shows. SHA-1 in HTTPS is a kinda intermediary example; browser and server vendors have been petrified to break legacy systems and generally not accorded that much priority to security updates. In Matrix, we hope to avoid this by setting a precedent that if Olm/Megolm is found broken tomorrow, we'd work with the major client authors to upgrade them, patching their clients ourselves if we have to, or providing a localhost shim or whatever, and then take the biggest community anchor points (e.g. #matrix:matrix.org) and throw the switch to the new protocol, and make it abundantly clear that folks on old clients have been left out in the cold for security reasons and need to get upgraded immediately. If you're a big enterprise with a private deployment who doesn't want to upgrade rapidly, that's fine. But the societal pressure will enormously be to get with the program and upgrade. Let's see how well that works though - we haven't really had to make any backwards incompatible changes yet since we started in Sep 2014.

(p.s. hi! :D)

[vertex-four]

A reasonable upgrade path is to do "room versioning". Each server would have a maximum supported room version, and publish it to each room they participate in, and every room has a version. When every server in the room agrees on a new version, they can publish a message to update the room version, and start talking over the new protocol. Older servers then can't join the room unless they agree to the room's new protocol.

Clients can then warn when they're in rooms with older versions than the latest supported, and since nobody wants the people they're talking to to receive scary warnings about insecurity, they'll upgrade.

And, of course, we can do similar with client versioning.

[x0x0]

This is remarkably contrary to how people actually use software. What people see is "click this button to make annoying red flashing shit stop so I can do what I want to do".

ala http://i.imgur.com/H0uVqFe.jpg

[vertex-four]

There's a reason web browsers just don't allow users to easily get past the annoying pages when there is a chance they're being attacked. I see no reason that Matrix clients would be required to allow users to break security without having a persistent banner saying "this room is insecure".

[x0x0]

Which they will ignore.

[acqq]

Especially dishonest of Riot promoters is to even introduce it at this very moment to the "normal" users, because

"Riot’s encryption is not yet fully stable and, more importantly, it is not yet enabled by default in chats (you have to enable it manually). This will be changed in the future, but makes it more likely for users to make mistakes until then."

Users "make mistakes"? By using the defaults? I consider it a mistake to promote it to the users with such defaults. A "secure" product which "doesn't encrypt by default"? And "it's not stable"? What does that mean? The encryption either works or not. "Almost working" is still "not working."

Then please don't write

"An alternative to Signal is Riot." It is not. As far as I understand it just "could once be an alternative."

But based on the responses I've received here to my questions about Riot, it's promising: according to them, I will be able to set up my own network of people (e.g. just my family) with which I'd like to communicate. Yay! (thanks to mxuribe and NoGravitas for the answers)

[vertex-four]

Right now, in practice, Matrix is "a better IRC". It provides bouncer-like functionality by default, federation across the whole network so you only have one identity vs having to register with each server on which there's a community you want to talk to, file sharing, voice/video chat, proper message formatting, and more.

Encryption currently works on Riot Web, iOS and Android, certain bugs excluded - but it's missing a lot of UX work. (Among other things, you have to manually verify each and every device the people you talk to use, there's no way for them to say "these are all my devices, if you trust me, you trust them" yet. You also lose chat history at present if you switch devices or log out.) If you're able to work around the UX, the underlying protocol is fine and has been audited, with certain tradeoffs discussed in the report.

[acqq]

Thank you. This is exactly what I wanted to read: clear explanation what works and surely not "it's not stable." What are the current encryption-related bugs, that is, what is their worst consequence?

I surely don't have a problem with the manual verification.

[vertex-four]

The current bugs are basically that occasionally, you can't decrypt a message. Supposedly this has actually been fixed (and wasn't a security issue), but I've seen it once or twice since. And as I say, you lose your chat history if you log out or bring in a new device. This is an important bug to fix, but it requires some UX work.

[Arathorn]

We are still chasing down the final unknown session ID bugs actually, although many have been fixed. The other big issue is to warn when unverified devices are added to a room. We are working on them all currently.

[Arathorn]

Just to be clear, the blog post here is not connected to the Matrix.org and Riot teams and is entirely independent of us. We've tried to be crystal clear that E2E is still in beta, as per https://matrix.org/blog/2016/11/21/matrixs-olm-end-to-end-en.... We are not recommending or introducing it yet to normal users.

I think the intention of Titus' article is to comment on where things are going in future... hence the title: "Why Riot (and not Signal) is the future".

[jcrites]

I think you make good points, but I think email works well as a secure group communication system for private organizations, and may improve over time as a federated one.

One important benefit of email is that you're not reliant on any single provider for your communication. Slack and Signal and systems like them are provided by single companies, and the continued function of those systems depends on the companies. Your long-term happiness with those systems could be influenced by how those companies interact with foreign or domestic governments' requests for surveillance, for censorship, etc. What will happen if one of these companies is ordered by a government to, like Lavabit, backdoor their system, or defeat the encryption on a device like Apple? Perhaps it will happen through secret court order and we'll never know, or perhaps the company will decide to shut down like Lavabit - as a user both are bad options.

With email, you can host your own email server, and take the fate of your group's secure communication into your own hands. For anyone to get your data they'll need to come after your devices directly; they can't just send a court order somewhere to obtain information about your communication - not even metadata. Although systems like Signal may not have the preexisting ability to eavesdrop on the substance of your communication centrally, they may be able to eavesdrop on your metadata and contact list, and it's possible that they or any vendor involved in app distribution such as app stores, OS vendors, telecom providers, device manufacturers, could be ordered to collect your data or metadata, or even build and deploy a backdoor.

As far as security, I think email is adequately secure for private group communication for most purposes. Many of us do rely on email for just that purpose within our organizations (e.g. companies). If your organization has a central mail server that authenticates its members, then you can get to a pretty good state fairly easily. Microsoft Exchange and Active Directory are an example of this. Gmail for business. Postfix with an LDAP server.

All modern email clients communicate with mail servers over TLS and will authenticate the server, just like a browser authenticates an HTTPS website. Modern email servers authenticate the client. What important security property do we get from the alternatives that we don't get from email? End-to-end encryption is the only one that occurs to me, and in an organization where we can trust our central server that's OK not to have. I suppose this is an easier proposition for companies than for loose groups of people organizing over the Internet. If you use a hosted email provider then obviously you must trust them, but self-hosted options are available and realistic (Exchange, Postfix).

Now, granted, what I am describing is a private organization rather than a federation. What's really cool though about email is that we get secure group communication within the organization, and also federated communication to other organizations on the Internet.

The security story for communication between organizations is weak, I'll grant. The primary weak link I see is not end user clients, but the communication between servers. Specifically, the lack of support in standards and servers for authentication of receiver by the sender, and for the receiver to declare that all incoming connections should come over TLS with a path-validated certificate. There is an Internet-Draft out for this called SMTP Strict Transport Security [1], but I don't know where it stands as far as support and adoption. DMARC+DKIM already provides authentication of the sender's organization by the receiver, and for declaring that all outbound messages from the sender's organization must carry a signature to be valid.

There's a fair amount of surface area in this model though: in particular, both end users and their mail servers need to be trusted. If in your communication between two organizations, you are willing to trust both organizations' central mail servers, then basic email setups will get you to a pretty good situation.

Some colleagues have recently made the case to me that S/MIME could fill in these gaps, and mentioned that folks in the industry are working to flesh out support for it. There are a number of problems to solve to make S/MIME practical, but with the will of a few major players I think we could get there. Some pieces that are missing include first-class client support, a key exchange/discovery/revocation system, and a scalable certificate issuance system. But solving S/MIME is only necessary to get to end-to-end encryption, and for most purposes it's practical to trust your organization's and partner organizations' email servers.

Even if email is not the secure group communication of choice, it's still used for a lot of secure communication and is worth improving IMO. I'm glad that Google and other have been investing in this: https://blog.google/products/gmail/making-email-safer-for-yo...

[1] https://tools.ietf.org/html/draft-margolis-smtp-sts-00

[sliken]

It's all well and good to run your own mail server. The biggest problem is 99% of who you send to/receive from will be in one of the big 3 mail servers.

[jcrites]

Could you elaborate on why that's a problem?

If the threat model for the communication within your group is concerned with attack or coercion from hostile governments, then you have the ability to set up your own email server and convince your participants to switch to it. It's not really much to ask -- it's fairly routine for companies and organizations to issue email accounts to employees/members and require their use for official business.

Consider that it may be easier to ask your communication partners to start using a new email account you've provided them than to adopt a new communication platform.

On the other hand, the people you're communicating with have chosen to trust the organizations that they're using to provide them with those services. Whatever service they're using is not radically different to trust than it is to trust the Signal developers, or the Google Play Store or Apple App Store to distribute the Signal application to your mobile device, and so on. Even if your participants are using Signal to communicate, they may have online backups enabled with their device to Apple, Google, etc., such that without your awareness your communication partners are trusting them just as much as if they were email providers.

[upofadown]

I just had a quick look at a email list I run for a local sporting organization and it looks like the big 3 are less than 50% of addresses. There were a lot of local ISP addresses, businesses and educational organizations.

[JupiterMoon]

2 things to consider. A lot of people use more disposable accounts for mailing lists. And a lot of businesses and educational orgs use Google apps or MS's equivalent with their own domain name.

[sliken]

Are you basing the 50% based on what is after the "@", i.e. gmail.com and yahoo.com? Or are you looking at what server the MX points at. It's very easy to have your own MX for your domain point to a google mail server.