The federation public key system is insecure

[jevolk]

The best way to obtain the identity (federation ed25519 public key) of a server is to contact it and ask. This process derives its security from the web's established TLS certificate system; like it or not this is the best way.

When the server is not online the key is not obtained under those assumptions. The key is instead obtained from another server. Other servers can fiction any key for the offline sever. Other servers can then (re)create messages, rewrite and take over, or crash rooms.

Querying multiple online servers to establish some agreement about the offline server (perspectives) is insufficient: ignoring the minority adversary to trust the majority in agreement is the foundation of a sybil attack; inversely, ignoring the majority in agreement merely because any minority exists is a denial of service. Thus the current system trusts some specific server to query: at present, all matrix implementations ship their software to trust matrix.org by default and have no realistic choice in refusing to do so. This is adequate for a centralized service, but is inadequate for a decentralized federation.

The solution proffered in #234 is insufficient. Storing keys in the room is insecure because the room with the keys might itself be fictitiously presented by an attacker faking keys.

Solution

Matrix is an internet based system already relying on domain names and the associated TLS certificate infrastructure. The security of that system must be leveraged for federation identities. When a server (domain based identity) is offline, proof of a message originating from that domain must be obtained. This can be done by using the TLS private key associated with a certificate signed by a certificate authority. The TLS private key must be used to sign the ed25519 federation public key which can then be obtained from any server regardless of it being online.

This solution involves adding that signature as another field in the verify_keys structure. The difficulty of implementing this solution is low, and can be shipped very quickly. Even if existing implementations are unaware of this new signature, and even if up to date implementations accept this signature not being present from old implementations: it is still imperative (and trivial) to add it now to the spec and implementations.

[ara4n]

Yup, the perspectives setup in synapse is broken. Speccing a fix is on the overdue hitlist for s2s r0; this bug can be the basis for publicly tracking that.

[richvdh]

whilst it's true that this is a problem, I don't think it's quite as bad as this issue makes out. There are a number of mitigations:

• As long as the server is online, we can ask it for its keys rather than ask the notaries. An attack can therefore only target servers which are offline, or which the attacker can make appear to be offline.
• The exchange of keys between servers is done over secure TLS, so the security vulnerability is limited provided you trust matrix.org. (It's certainly not acceptable that the distributed protocol relies on matrix.org as a central point of trust - this is merely a datapoint to demonstrate why the problem here is less severe than for TLS certificates.)
• Concerned administrators have the option of adding other notaries (possibly using matrix.org only as a fallback when other notaries do not have the relevant keys).

[richvdh]

I fleshed out the proposed solution at MSC1714, but as I wrote there, I am not convinced that it could be made to fly, and I think that MSC1228 represents a more fruitful avenue for investigation.

[cyphar]

Presumably this is fixed by 1.0 being released with a hard requirement for TLS for all homeserver federation and the removal of perspectives?

[tulir]

@cyphar It is not. This is about the federation signing keys, not TLS. Signing the signing keys with valid TLS certs was just one potential solution mentioned, but no solution has been implemented so far. matrix.org is still the default trusted key server and most people don't change that.