For real we should ditch wallets and password managers and OAuth and instead use public keys + ActivityPub Actors + HTTP Signing. Though I guess it puts a lot of trust into the DNS layer?
@mauve problem with that is securely storing the private keys.
@thisismissem Yeah that too. In our case the answer to "what happens when I lose my keys or they are stolen" is "make a new keypair and add it to your actor object" which IMO is an improvement over "ha ha you lost your identity forever lol". Leaves a lot to be desired still though.
@mauve how can you add it to your actor object if you actor object is sogned with the previous key?
@thisismissem Err, do Actors need to be signed? I've only been using the signing for http auth. Didn't see anything about needing to sign the actor in any of the guides I looked at. 😅
@mauve well, in your system if te actor wasn't signed, I could mitm a server, add a new key to a copy of your actor object, and suddenly get that new key federated out.
@thisismissem Yeah! That's what I meant about being overly dependent on DNS. If you can't trust an HTTPS request the whole thing breaks.
@mauve I guess what I'm getting at is: key management and security is difficult, particularly distributed, and requires sneakernet verification often. So if you just blindly trust that a key mentioned in the Actor object is authentic, then that's the flaw in your security, because you service also doesn't want to be checking the origin's Actor object for every activity or federations-request, so would need to cache known keys, which would mean a single mitm would poison the key cache
Do you mind elaborating a bit on that? Is mitm of https (+ dnssec) a plausible attack vector?
I get the dangers of validating using revoked keys, though. That's certainly a security/efficiency trade-off.
@joelving @mauve so if the keys allowed come from a document that's not signed by the keys, and that document (and it's keys) get cached, then an attacker would need to just impersonate your server once to the attacked instance, ehich would then poison their copy of the document, and their knowledge of allowed keys
@thisismissem @joelving At the moment I'm using HTTP caching mechanisms (E.G. ETAG) to reduce how much data is being re-fetched. So it's a bit better than a one time MITM being able to poison the cache forever and a bit better than fetching for each authentication.
@thisismissem @joelving Yup! Tradeoffs
@thisismissem @joelving Every ActivityPub implementation needs to do some variation on this sadly.
@thisismissem @joelving Oh one last bit with ActivityPub in particular, you can send an Update activity to people's inboxes which can enable even more aggressive caching while still being able to invalidate the cache when needed.
@thisismissem Interesting. So they sign it with the old key instead of the new one? That'll cause some errors for my current setup. 🤔
@mauve yup! https://github.com/mastodon/mastodon/blob/main/lib/mastodon/cli/accounts.rb#L662
Because if you sign with the new keys how could you trust the update?
@thisismissem By fetching the actor data from their url instead of cache. For example what if you send the update but the server doesn't have your old actor cached already.
@mauve I would assume you wouldn't send the update then, because the remote server wouldn't be known.
@thisismissem Yeah, it's just that that assumption isn't part of the spec. 🤷 Probs just an edge case that will happen sometimes that folks don't need to worry too hard about I guess.
@thisismissem That's not the case I meant to refer to. The assumption is that all servers you've communicatd with have a cache of the actor already which is not something in the spec and therefore can break depending on the implementation.
@mauve i guess if you received an update but cannot validate the signature, it'd be fine to just refresh the Actor (it'd be omly if you DNS was MITM'd that this would be an issue)
@mauve well, why would you send an Update to a server you'd not previously communicated with?