Federating Security or Spam?

When considering federation, if you are dealing with sensitive, valuable, regulated, or classified communication, there is only one legitimate choice to make. At Wire, our approach to federation, like everything we do, is designed to deliver the highest possible security while making it delightfully invisible to end users, enabling the highest possible productivity and agility.

Application Design Reveals Its Priorities

When dealing with security-related products, it’s easy to get lost in a sea of fancy technical terms. All the more when you’re talking about cryptography, which only a tiny fraction of even technical people really understand at any depth. However, what often gets overlooked is that application design has a significant impact on delivering security. By looking at how the application is designed–the choices it makes, you can understand what it prioritizes and whether or not that matches your organizational priorities.

SignalGate gave us a case study in the role played by application design choices (as opposed to cryptography). Signal uses a very competent cryptographic key exchange protocol and end-to-end encryption, yet it still enabled one of the most scandalous breaches in recent memory. Why? Simply speaking, Signal is not designed to create and protect boundaries for the purposes of securing corporate or government communications. That’s why it has no concept of “internal” vs “external” or “guest” members in a group. It’s designed for casual consumer use, with a vast, open global pool of participants to encourage viral adoption, similar to a social media app. Choosing to use Signal for classified communications was gross malfeasance because it’s clear that it was never designed for that. You could say the same for WhatsApp, which is why it’s so terribly risky to allow it for use by any security-sensitive organizational setting.

Keep this notion of application design choices in mind when examining federation.

Federation: Open vs Moderated - to What?

Technically speaking, federation, in its simplest terms, means that two or more servers that are administratively autonomous can communicate and exchange information using a common protocol. There are two very different ways to operate a federation–open and closed.

Open Federations: Designed for Growth, Not Security

“Open” federation is a design choice to deploy federation such that any server can freely connect and communicate with any other server, without prior approval. This means that federation is:

• Decentralized (disaggregated) and permissionless
• Anyone can set up a server and join the network
• Servers can automatically discover and federate with others 

Examples of open federations are email powered by SMTP, and in the case of “secure communications,” Matrix/Element.

The design goal of an open federation is to prioritize ecosystem growth by lowering the barrier to entry. However, this goal exists in opposition to prioritizing security, since, by nature, it’s impossible to prevent spam, phishing, and other abuses and threats. It places all the burden of moderation and data protection on individual server administrators, and you can’t make the overall model meet security or compliance standards in any predictable fashion.

Note that this design goal is very similar to the social media orientation of Signal or WhatsApp – create a global, viral community. And the dangers are similar. In the case of Element and Matrix there is a fascinating difference from Signal. Signal is a singular service and not an open federation, so it doesn’t suffer from spam and phishing problems, whereas the open federation model of Matrix/Element, much like email/SMTP, most definitely does. The default Matrix homeserver doesn’t require you to even use an email to validate your account, so it allows anyone to sign up and set up a server, which is why, like email, Matrix has had so many issues with spam and phishing.

Open federation means open to viral growth, but also to spam, phishing, and other accompanying threats. If you are a corporation seeking secure messaging and collaboration for out-of-band or crisis communications purposes, or are handling sensitive, valuable, or classified information, you should never opt for an open federation model. Just as Signal is an inappropriate choice for these organizational use cases, so is any application deployed with an open federation operating model, even if, like Signal, it employs competent end-to-end encryption (E2EE).

Moderated Federations – Designed for Security, Privacy, and Compliance

Moderated federation means that the application is designed to protect boundaries and whatever is inside those boundaries. Typically this means that the federation is:

• Manually configured or based on a whitelist
• Interoperability is based on known servers
• Based on a controlled trust model

One prime example of a moderated federation model that prioritizes security and meets the criteria above is SSO federation using SCIM, OAuth2, or OIDC, because they always operate within a predefined trust relationship between an Identity Provider (IdP) and a service provider (e.g. GitHub or any other application). In SSO federation, there’s no automatic discovery, no open or permissionless connections. In fact, there’s no way for a third party to participate in a federation without prior approval. And that’s entirely appropriate because the whole point of SSO is to deliver a straightforward yet highly secure application onboarding and login experience to end users.

If your organization is looking to use a secure messaging or collaboration app for the purposes of protecting sensitive or classified data, a moderated federation model is the only possible consideration for you. That’s why Wire implements a moderated federation model, with tons of administrative controls, and with enterprise-class scale, including automated domain-based SSO routing between federated Wire instances across our Wire Cloud, private cloud, and on-premises Wire back-ends.

Furthermore, Wire’s free, public service is operated with a similar design ethos. Unlike the anonymous account creation in Matrix’s homeserver, Wire requires an email at a minimum for account validation, so there are no anonymous sign-ups, which deters bots and sockpuppet accounts. Wire allows users on the same server to find each other if they know the other user’s handle, but admins can configure rules to constrain search visibility. And Wire used real-world trials to find the most secure way to enable contact requests, so that even in the Wire Cloud with a free account community of millions of worldwide users,the possibilities to spam are reduced. There are no massive global directories or rooms, so spammers can’t easily scrape usernames or broadcast junk. Wire avoids spam by its design choices, even in its free service.

Closed federations are designed for security, not for spam 😉.

It’s Possible to Build a “Moderated” Federation Model and Make it Insecure Anyway 

Here’s a great case study in contradictory application design, as applied to federations. Microsoft Teams supports federations between Teams instances in the Microsoft 365 cloud service. By design, it was built to be closed. However, Microsoft intentionally defaults all Teams instances to be configured with federation turned on and open to accept any connection permissively (!). If you don’t explicitly go in and turn that off, your corporate messaging is at high risk. Sadly, this has had real-world implications, as hackers have set up Teams instances, scanned other Teams instances, identified unremediated configurations, established federations, and impersonated IT personnel at companies, thereby exploiting their data. Mind-blowing but true.

There is No Inherent Difference in Scaling Open vs Moderated Federations

A myth promoted by certain vendors in the industry is that only an open federation can scale.

The ultimate example of a moderated federation that is massively scalable is the Internet. Internet routing is a permissioned, federated system. Firstly, to advertise routes on the Internet, as an organization, you need to register and obtain authorization with an Autonomous System Number (ASN). Then you need to agree with other organizations that are authorized to operate Autonomous Systems, to peer with them and exchange routes. There is no default open peering. Internet routing is clearly highly scalable. No problem there. And it is moderated by design because an open federation model would replicate the security problems of email, albeit in a far more severe and damaging manner. It would make the Internet unreliable as a communications infrastructure.

In the non-Internet routing world of secure messaging and collaboration apps, pretty much all servers (including Wire, Element, etc.) use some form of TLS to communicate with each other for the purposes of federation. There’s no inherent difference in scalability there.

So let’s banish this thought that a moderated federation system can’t scale. However, you must make a design choice, such as in Internet routing, to utilize a moderated federation model to maintain security.

Scaling Federations Doesn’t Have to Mean Insecurity

If a vendor’s answer to scaling is to fling the doors wide open to the wild west of open federation, you’re getting the “scalability” of convenience, but it comes at the price of high security risks. If you’re building large-scale federated system of servers for communications between gamers, that sounds fine. But if you’re trying to establish secure communications across subsidiary or supply chain organizations in a critical or regulated industry, it is a risky move.

In the case of Wire, we’ve been chosen by some of the largest organizations in the world to secure large-scale sets of federated subsidiary organizations and even third-party supply chain providers, due to our scalability. Wire allows you to federate many instances across on-premises, private cloud, and Wire Cloud with no problem in scaling. Furthermore, by federating with Wire Cloud, you can also access millions of free and paid users around the world.

Our scalability goes beyond federation. Wire is the only secure collaboration platform that utilizes the Internet standard Messaging Layer Security, which provides a massive leap in scaling E2EE group communications over previous protocols such as Signal, Olm/Megolm, etc.

Open Federation Often Comes with Weak Authentication

Another consideration about federation security and design choices is authentication rigor. The lower bar that is usually set for open federation models affects the caliber if security measures such as authentication. For example, in Matrix, federation authentication is done via public key verification discovered via well-known URLs, key servers, or DNS records. This method is considered vulnerable to DNS hijacking, prone to misconfigurations, and delays in revoking keys. Another example is that open federations usually allow-all by default. For example, with Matrix, any server can attempt to federate unless explicitly blocked, which means that it’s possible to launch federation-focused exploits.

Moderated federation models favor more rigorous security measures. For example, Wire operates in a deny-all federations by default mode, so an administrator must specifically allow federation with a particular domain. Once that permission is configured, the Wire admin must provide the certificate of the other domain, issued by a trusted Certificate Authority. This prevents DNS hijacking attacks and makes man-in-the-middle (MITM) attacks nearly impossible.

A Security Comparison of Moderated vs Open Federation

Following is a breakdown of security dimensions and how moderated federations behave as compared to open federation models.

“Secure Communications” with “Open Federation” is a Contradiction in Terms. Choose Wisely.

Would you ever consider an SSO system that allowed any entity to set up a server, then automatically discover and connect with your Salesforce instance and let random people crawl around your sales data? Let’s hope not.

Likewise, you should not choose a “secure communication” app that operates on the basis of open federation. To do so is to open yourself to spam, phishing and possibly worse.

Learn more about how Wire delivers the most secure, MLS-based E2EE communications that scale to enterprise and government requirements.

Download the Whitepaper.