Towards Federated Key Transparency
soatok.blog
soatok.blog
It would be like setting up certificate transparency without logging domain names - no point.
What am I missing.
People mostly don’t use real names on Mastodon, so essentially, you are your username. Impersonating a username is like impersonating a domain name for a website.
Are you talking about the directory server in isolation or how it's going to be integrated into the E2EE for the Fediverse proposal? It's not clear for your comment which use case you're imagining.
The thing is: With the E2EE proposal, you don't just encrypt something to a complete stranger based on the Directory Server's contents. Instead:
1. You poke their instance for their user ID, and which directory servers they use.
You can have further client-side checks, gossip protocols about username<->ID mapping, etc. to keep the instance honest about which ID maps to which user. I just don't want to deal with GDPR's "right to be forgotten" and usernames (which may be PII) at this layer.
2. You poke the directory server for the public keys, and proofs of inclusion in the SigSum ecosystem; including co-witness signatures.
3. Your software verifies these proofs, automatically, client-side. It refuses to move forward if anything is amiss.
4. Now that you have an Ed25519 (or post-quantum) signing key, you then query the instance for one of their SignedPreKey bundles.
5. You verify the signature on the SignedPreKey bundle, then use that to establish an untrusted comunciation with the user in question.
After step 5, if you want to verify their identity, something like Signal's safety number for user trust can be implemented to allow out-of-band verification.
It's important to take a step back and think about what the instance admins can and cannot do to mess with this process.
Scenario A. A new user wants to enroll in E2EE messaging. The instance admin can pretend to be them and push an AddKey on behalf of the user, thereby locking them out of enrolling. Evidence of this becomes immutable and public, and the user can mitigate this by getting the hell off that instance.
Scenario B. A malicious admin wants to snoop on the private messages of a user that has previously enrolled. The protocol forbids AddKey messages from being published by anyone but the user that possesses an incumbent signing key, which the instance admin does not have. They are thwarted by this policy.
Scenario C. A malicious admin remaps the user's ID and enrolls a new AddKey, and selectively reveals one ID to some users and another to other users. This would be a challenge to pull off in a useful way, since the API to get a user's ID from the instance to lookup in the Directory server will not necessarily reveal who's asking for it.
Third parties that publicly map User IDs and broadcast them on Fedi can mitigate this issue by alerting users to a difference. Although this would be annoying to integrate with a transparency log, having a watchdog service that your client software polls to ensure others see the same ID. Even as simple as automatically posting "user@instance is now at <random id here>" every time it changes would make this sort of misuse easily discoverable.
This is out of the scope of the Directory Server design, but worth considering for the overall E2EE system. Since the blog post was focused on the Directory Server design, I didn't feel like speculating when I wrote it.
Scenario D. A malicious admin remaps the user's ID and enrolls a new AddKey, but instead of selectively revealing one at a time, replaces them for all future DMs for everyone. Client software can easily detect this attack by noticing that the user's ID has changed, but the user didn't publish a MoveIdentity to their new ID.
Scenario E. A user loses all of their secret keys and wants to start the enrollment over again. The user asks the admin to perform the exact same steps as a malicious admin from Scenario D, but for legitimately honest reasons (i.e. the AddKey for the new identity actually came from the user).
Ultimately, distinguishing Scenario D and E is a social problem, not a technology problem. Detecting the behavior doesn't necessarily mean malice.
In particular, to decide what's in scope, it's important to distinguish between users and their client software, and to decide what the user's input is to the client software. The user has to somehow get their intention across to their messaging software about who they want to contact.
For TLS, there's an assumption that people know which domain name they want already. Figuring out the right domain name is out of scope; that's a social thing. A lot of times, it's part of a URL. Maybe they're trusting Google. Or when sending email, we assume the email address is already known to the user, somehow.
For TLS, the IP address doesn't matter, because the domain name is part of the URL and part of the certificate and what matters is which server holds the private key. Securing DNS isn't part of the system [1] and transparency logging isn't needed for IP address changes.
Domain names are kind of trust-on-first-use. People hear about a domain name somehow and the important thing is that the owner doesn't lose control of their domain name after they've publicized it and people start linking to it. Similarly, here, I think the important thing is the user doesn't lose control of their username unless they really screw up, like in the scenario you describe.
I don't entirely follow what you're doing and I'm not sure if a directory needs transparency logging as a directory. It's sort of like DNS. The sensitive bit is generating the public/private key pair. But I think maybe you've combined roles, so that the directory server is also the certificate issuer?
About Scenario A:
> The instance admin can pretend to be them and push an AddKey on behalf of the user, thereby locking them out of enrolling. Evidence of this becomes immutable and public, and the user can mitigate this by getting the hell off that instance.
There will be lots of AddKeys happening all the time. If the AddKey doesn't contain the username and they don't recognize the ID (because they had nothing to do with it), how does anyone know when an AddKey refers to them? Maybe the server tells other people that an AddKey refers to them, but privately? Possibly the user would find out through gossip, but the log isn't enough evidence by itself, and if the gossip isn't entirely trusted either, they don't have a clear case. It seems a lot less straightforward than scanning a transparency log for your domain name.
[1] Though, it comes back in again when Let's Encrypt checks that you control your domain name.
It has nothing to do with the identity verification a la Keybase, unfortunately, as that would be a really good and useful feature for the fediverse, but I think it would be a lot harder to do.
... thinking it through, maybe not. I guess if a client initiates AddVerification for some twitter handle, and the directory service sends that handle a private twitter message with some guid, and then the client sends AddVerificationStepTwo with that guid, the directory service could append both of those messages to attest that that user is associated with that handle. A malicious directory service (or a real directory service that's calling a malicious twitter clone) could fail to correctly verify someone, but it wouldn't be able to add a verification for the wrong client or for a client that didn't initiate it, which is probably good enough?
edit: just realized you're the author, thanks for working on this stuff!
The real problem with encrypted communications is: how do you properly distribute public keys, make sure they receive it, they receive the right one, etc ?
- giving them by hand, directly or through web of trust, doesn't scale
- trusting a server involves... trusting it, which you might not be able to do for many reasons
- use the first one you receive from your recipient (TOFU) kinda works, but it's not really enough
The beginning of a solution here is general transparency for everyone: everyone sends their public key to everyone, everyone records everything, and so if someone else changes my key without my consent I can tell everyone "SOMETHING IS WRONG, THIS IS NOT ME". For scalability, of course, keys aren't sent to everyone. The nice thing with this is that by design you don't need to trust anyone, you just have to watch everything by yourself.
Keybase still needs to trust all third-party services, although it's assuming that each one isn't super reliable and the real trust comes from multiple independent third-parties. It's slightly in the middle, with the advantage of reusing existing stuff, but the inconvenient of making said existing stuff more important
What's the relationship with the fediverse ? None, really; the concept is generic for any kind of communication, but ActivityPub is slowly becoming a protocol for generic communication anyway so might as well do it for AP.
What project/spec is this?