>allowing bad actors to post in my name, given the public key is part of the DID that you found from the DNS entry. Or?
DNS only resolves the Handle->DID, but you still need to verify DID->Handle mapping by getting the DID Document. It's bidirectional.
I guess I need to study that in more detail, as I don't immediately see how it's preventing DNS attacks.
> DNS only resolves the Handle->DID, but you still need to verify DID->Handle mapping by getting the DID Document. It's bidirectional.
Yes but if I've already hijacked the DNS to point to my own DID, what's stopping me from saying I go by your handle?
Sure older posts wouldn't verify, but a new post would be signed by the keypair I've put in the DID I hijacked, no? Or is that some other key in the DID?
New to AT so perhaps this is a non-issue. Main concern of mine is that DNSSEC seems to not have a very bright future, so not something new stuff should rely on IMHO.
The process of establishing "this handle points to this DID" consists of:
1. Resolving handle -> DID via HTTPS/DNS (part you're concerned about)
2. Downloading the DID Document from its host
3. Verifying that the DID Document contains the same handle
Hijacking the DNS does not help you with (2) and (3). The handle isn't considered associated with the DID until (2) and (3) are done.
This is noted in the did:web spec, which isn't from Bluesky PBC / AT Protocol: https://w3c-ccg.github.io/did-method-web/#dns-considerations
I should note though, that for many implementations, that'd mean poisoning a large DNS provider like google, cloudflare or quad8, since those are the DNS servers typically queried from servers, instead of going directly to the authoritative server itself.
There's more technical details here: https://github.com/bluesky-social/atproto/tree/main/packages...
1. I hijack the DNS entry so "_atproto.ruuuuu.de" TXT record now returns "did=did:web:iam.evilhacker.de" to the the actor doing the at protocol resolution.
2. To get the DID, the actor doing the at protocol resolution downloads the DID from "https://iam.evilhacker.de/.well-known/did.json", which I have full control over.
3. In the DID document, I put "alsoKnownAs": ["at://ruuuuu.de"], along with my own public key.
Wouldn't this make the actor doing the resolution associate me with your handle?
Again, maybe I'm missing something here. It just seemed to me this would allow me to hijack your posts when they are federated.
There's also did:webvh which isn't yet supported by AT Protocol, but may provide some better security, but is likely still susceptible to DNS poisoning.
However, the resolution of handle to DID happens at many different layers in the stack, so you'd have to manage to attack all of them at once. Handle resolution isn't something that typically happens on the end-users' machine, but rather on a server running a PDS, Relay or AppView. Those environments tend to be much harder to carry out DNS poisoning attacks.