3 ms·

> Doesn't the fediverse already have a mechanism where each user can set a profile, which everyone else has a common view of and other people can't change? You

> Doesn't the fediverse already have a mechanism where each user can set a profile, which everyone else has a common view of and other people can't change? Your instance admin can change it. The goal of encrypting DMs is to protect against honest-but-curious instance admins, especially since often multiple have access to the stored DM contents on disk. > Couldn't a parallel mechanism distribute public keys in a similar way? How do you validate that the public key you're seeing is your friend's, and not a snooping administrator performing a MitM attack by substituting the public key with theirs? > What's the issue here - that the server where you have your account can replace your keys? Yes, partly. > I know SSL's "certificate transparency" tries to detect replaced and mis-issued certificates after the fact, by putting them all into an immutable log that can be searched by domain name. But if the entries in the log can be deleted, so there's no longer a log that would prove the attack had happened, wouldn't that prevent the log fulfilling its sole purpose? Consider https://defuse.ca/triangle-of-secure-code-delivery.htm#:~:text=are%20successfully%20attacked.-,Userbase%20Consistency%20Verification%3A,-Users%20of%20the https://defuse.ca/triangle-of-secure-code-delivery.htm#:~:te... The goal is to ensure everyone has the same view of which actor has which currently-trusted public keys. Additionally, the deletion of past log entries requires a legal takedown request. What this process actually looks like is out of scope for my specification, but I imagine it will usually involve lawyers.

michaelt 2y ago
> The goal is to ensure everyone has the same view of which actor has which currently-trusted public keys. But isn't the profile/bio already a mechanism that gives everyone the same view of some per-account details, set by the person who controls the account?
- some_furry 2y ago
  Not if the admin tampers with your bio! Not if the instance software itself gets hacked, either. See https://github.com/fedi-e2ee/public-key-directory-specification/blob/main/Specification.md#threat-model https://github.com/fedi-e2ee/public-key-directory-specificat... for a detailed threat model.
  - michaelt 2y ago
    Alas I'm not smart enough to understand your threat model, as I'm just a simple small town software developer who don't even know what a Edwards25519 curve or a SUF-CMA is. If an admin or hacker tampers with a user's bio - i.e. gains control of a user's account - isn't that essentially indistinguishable from a user who lost their phone/forgot their password? Is the intention that E2EE have a separate, parallel account recovery mechanism with more difficult requirements?
    - soatok 2y ago
      > Is the intention that E2EE have a separate, parallel account recovery mechanism with more difficult requirements? I'm not sure the wording here is helpful. Let's start with a simple diagram: https://github.com/fedi-e2ee/public-key-directory-specification/blob/main/Architecture.md https://github.com/fedi-e2ee/public-key-directory-specificat... (see the first one) A single Public Key Directory will serve many hosts. (You can further add replication and cross-directory checkpointing between directories, to ensure the whole network is transparent, but that's not our concern right now.) If a host decides to misbehave, there's an independently hosted record of every change to the state machine that maps Actor IDs to public keys. This state machine is backed by a Merkle tree, which includes a proof of inclusion for every change to its state, thereby making it an append-only ledger. In my design, you don't have to trust the hosts' admins to behave, because the directory keeps them honest. You also don't have to trust as single directory to behave, since its primary purpose is to be transparent and independently auditable. If a user wants to revoke their key, they can, but it's an additional protocol message appended to the directory's transparency log. If a user loses all their secret keys, one of two things can happen: 1. Their instance admin issues a BurnDown, which allows the user to enroll a new public key as if they were a new user. 2. If the user has issued a Fireproof message, the instance admin cannot issue a BurnDown, and the user is locked out of the protocol. This is a trade-off. Users can move hosts. Users can publish auxiliary data (e.g., SSH public keys), if the extension for that key type is defined and enabled by the directory. Even an attacker with root access to the host cannot arbitrarily or selectively replace a user's public key with their own. With your suggestion, this substitution is trivial. And that's basically how the system works. But that's not the focus of this blog post. This blog post is how to solve the seemingly incompatible design goals of: 1. Offer userbase consistency verification for users' public keys. 2. Don't cryptographically inhibit an EU citizen's rights under Article 17 of the GDPR. 3. Don't introduce backdoors to the transparency log that allow them to perform the same trivial attack that your suggestion enables.

michaelt 2y ago

> The goal is to ensure everyone has the same view of which actor has which currently-trusted public keys. But isn't the profile/bio already a mechanism that gives everyone the same view of some per-account details, set by the person who controls the account?

some_furry 2y ago
Not if the admin tampers with your bio! Not if the instance software itself gets hacked, either. See https://github.com/fedi-e2ee/public-key-directory-specification/blob/main/Specification.md#threat-model https://github.com/fedi-e2ee/public-key-directory-specificat... for a detailed threat model.
- michaelt 2y ago
  Alas I'm not smart enough to understand your threat model, as I'm just a simple small town software developer who don't even know what a Edwards25519 curve or a SUF-CMA is. If an admin or hacker tampers with a user's bio - i.e. gains control of a user's account - isn't that essentially indistinguishable from a user who lost their phone/forgot their password? Is the intention that E2EE have a separate, parallel account recovery mechanism with more difficult requirements?
  - soatok 2y ago
    > Is the intention that E2EE have a separate, parallel account recovery mechanism with more difficult requirements? I'm not sure the wording here is helpful. Let's start with a simple diagram: https://github.com/fedi-e2ee/public-key-directory-specification/blob/main/Architecture.md https://github.com/fedi-e2ee/public-key-directory-specificat... (see the first one) A single Public Key Directory will serve many hosts. (You can further add replication and cross-directory checkpointing between directories, to ensure the whole network is transparent, but that's not our concern right now.) If a host decides to misbehave, there's an independently hosted record of every change to the state machine that maps Actor IDs to public keys. This state machine is backed by a Merkle tree, which includes a proof of inclusion for every change to its state, thereby making it an append-only ledger. In my design, you don't have to trust the hosts' admins to behave, because the directory keeps them honest. You also don't have to trust as single directory to behave, since its primary purpose is to be transparent and independently auditable. If a user wants to revoke their key, they can, but it's an additional protocol message appended to the directory's transparency log. If a user loses all their secret keys, one of two things can happen: 1. Their instance admin issues a BurnDown, which allows the user to enroll a new public key as if they were a new user. 2. If the user has issued a Fireproof message, the instance admin cannot issue a BurnDown, and the user is locked out of the protocol. This is a trade-off. Users can move hosts. Users can publish auxiliary data (e.g., SSH public keys), if the extension for that key type is defined and enabled by the directory. Even an attacker with root access to the host cannot arbitrarily or selectively replace a user's public key with their own. With your suggestion, this substitution is trivial. And that's basically how the system works. But that's not the focus of this blog post. This blog post is how to solve the seemingly incompatible design goals of: 1. Offer userbase consistency verification for users' public keys. 2. Don't cryptographically inhibit an EU citizen's rights under Article 17 of the GDPR. 3. Don't introduce backdoors to the transparency log that allow them to perform the same trivial attack that your suggestion enables.