fedimint
How can user authenticate a federation?
Currently a user acquires a list of guardian server websocket addresses, connects to them, and downloads a config containing all details to interact with the federation.
But how should the user validate that these servers are actually controlled by the federation guardians and not sybils?
I had the same question, which led me to open https://github.com/fedimint/fedimint/issues/744 for discussion. Cryptographic PeerIds could be used to authenticate the federation metadata (incl. connection endpoints).
- Federation meta data could be signed be all federation guardians using the corresponding secret key of their PeerId.
- Connection information (e.g. websocket addresses) can be volatile and should be treated separately. If you can establish an authenticated connection based on the cryptographic PeerId, the actual connection address becomes pretty irrelevant and doesn't need to be signed (and verified) by the other federation guardians.
IMHO, a user should only validate: "Here's a list of (cryptographic) peer ids who claim to maintain a federation. And that list was signed by all of them." I have to at least verify one of the peer ids using out-of-bounds communication (probably the federation guardian I trust most).
We need to distinguish the trust model and how we distribute config.
Trust model
Users fundamentally have to trust the one who is giving them the join QR code (or cross-check with others) or need some oob verification mechanism with a quorum of the federation members. No way around that.
Out-of-band verification is out of scope by definition. So we are left with trusting the supplier of the QR code. For that to be the case the QR code needs to commit to the config the one displaying it wants to convey. This can be done by:
- Including API endpoints of all members that can then be queried and checked for consensus on the config (current solution)
- Including a hash of the config and some way to fetch it from an untrusted source
- Including a threshold public key and some way to fetch it from an untrusted source. The key is used to verify the returned config. The benefit here is that parts of the config can change, the federation just needs to sign it again.
Config distribution
Fetching via web socket, from a HTTP server or a DHT work equally well here imo. A DHT would be useful if all guardians were behind a NAT (not supported right now anyway, but relevant to @yojoe's libp2p ideas).
I agree it makes sense to separate the authentication key from the network configuration, particularly if we end up supporting multiple client-server connection types like HTTPS, Tor and I2P.
It could be nice to use a single threshold key for authentication because it could easily be copied into a user client (e.g. by QR code) which might not be possible using individual keys for large federations. Configs could be signed by the threshold key and connections could be authenticated by proving to be a unique member of the public key set. Guardians could even post their public key share publicly to allow users to verify the threshold key they are using includes that guardian in its set.
I agree it makes sense to separate the authentication key from the network configuration, particularly if we end up supporting multiple client-server connection types like HTTPS, Tor and I2P.
Right now we don't implement any real client/server authentication and I just hacked it together with an nginx proxy+Let's Encrypt for the live federations. Ideally we would use Tor anyway and use its built-in authentication scheme. I don't think it's worthwhile implementing our own authentication scheme that re-uses the config signing keys given that Tor already has one and clients need the Tor addresses anyway which already contain a different key. But since the config will contain tor addresses these keys will automatically be committed to by the config signature.
Do we even want a threshold signature scheme here? Wouldn't we want all guardians to sign the config and otherwise use a different guardian set if they fail to do so?
@elsirion For v1, I think a list of Tor addresses is sufficient, but there might be benefits to switching to threshold key auth eventually. For instance if the network configuration changes, due to up to f guardians going down permanently, or if the Tor endpoints need to change, or the fed switches to other network protocols. Additionally, for large federations it might be difficult to copy all the Tor addresses into the client since the keys cannot be aggregated.
For non-network config changes (e.g. server compatibility or fees) we can just stick with the model of polling f+1 guardians for configs.