So any server storing such at:// links will need to do some DNS/HTTPS dance to get the canonical representation, or permalink as the author calls it.
Doesn't that make it quite fragile without functioning DNSSEC?
Haven't really thought it through but my immediate reaction is DNS poisoning seems like it could do some damage here, 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 poisoning is a concern in some situations, but not always.
The common case with at:// strings is to put in the DID in the "authority" slot, not the handle. In that case, whether resolving a did:plc or did:web, there are regular HTTPS hostnames involved, and web PKI. So the DNS poisoning attacks are the same as most web browsing.
If you start from a handle, you do use DNS. If the resolution is HTTPS well-known, then web PKI is there, but TXT records are supported and relatively common.
What we currently recommend is for folks to resolve handles server-side, not on end devices. Or if they do need to resolve locally, use DoH to a trusted provider. This isn't perfect (server hosting environments could still be vulnerable to poisoning), but cuts the attack surface down a lot.
DNSSEC is the current solution to this problem. But we feel like mandating it would be a big friction. We have also had pretty high-profile incidents in our production network caused by DNSSEC problems by third parties. For example, many active US Senators use NAME.senate.gov as a form of identity verification. The senate.gov DNS server uses DNSSEC, and this mostly all worked fine, until their DNSSEC configuration broke, which resulted in dozens of senators showing up in the Bluesky app as "invalid handle". This was a significant enough loss of trust in the DNSSEC ecosystem that we haven't pushed on it since. I think if we saw another application-layer protocol require it, and get successful adoption, we'd definite reconsider.
They'd need the private key to post as you. The DNS record just points to where the DID document is, but there's a verification check that the DID document points back, and this is automatically performed as a part of the resolution process.
DNSSEC would add additional security around DNS record changes, but not having it wouldn't allow someone to impersonate you, because your server would need to agree with that.
This is a bit beyond my understanding (I'll ping someone who may be able to answer), but https://atproto.com/specs/handle#dns-txt-method mentions "DNSSEC is not required" (though I'm also not sure that's what you're asking).
>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.
If you did hijack the DNS and say `TXT _atproto.<handle>` points to `did:web:mycontrol.example` then that's a plausible attack, I guess, against did:web, but not against did:plc. And it'd assume that software in between hasn't cached the previous mappings, which typically it has.
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.
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.
That is a risk for did:web, just as loosing control of your domain is a risk; The did method that is most widely used on AT Protocol is did:plc, which is https://web.plc.directory/
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.
Doesn't that make it quite fragile without functioning DNSSEC?
Haven't really thought it through but my immediate reaction is DNS poisoning seems like it could do some damage here, 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?