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 Mastodon & fedi software only deals with any of those fpr their webapps and extensibility use cases, not for federation
@thisismissem Yup! Exactly and so you have way more ways of making clients. IMO it'd be great if clients used signed requests to their inbox/outbox and if instances provided SPARQL or similar for querying data back out. Or better yet it'd be nice if clients loaded other peers' data directly.
@mauve I think you may be searching for solid with solid-tls for auth
@thisismissem Mind linking to a TLDR for how that works? Solid is defs something I'm interested in.
Is solid-tls the tls client certificate auth? I was ranting about how it sucks that isn't used more a few months ago :P
Sadly I couldn't get it working on Linux with chromium or firefox so I gave up on pursuing it further.
@mauve it's all available via the solid project website, it's one of the official specs but got superseded by solid-oidc, but I know TimBL still believes in it because OIDC annoys him
@thisismissem Neat yeah. I like the use of linking to profiles with the SubjectAlternativeName field in the certificate. Still wishing we had the future where we used client certs for auth. 😩
OIDC makes sense given the larger "identity" industry. Agree it can be annoying though. So many little pieces to keep track of.
@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
@thisismissem Yup I getcha!
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 I think the dynamics become similar to a password in the end but it makes it just a little harder to spoof requests and it makes it just a little easier to not have to deal with JWTs/UCANs/Bearer tokens