3 ms·

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 https://atproto.com/spe

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 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.

deleted 1y ago
[deleted]
magicalhippo 1y ago
> "DNSSEC is not required" 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.
- danabramov 1y ago
  >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? 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.
  - thisismissem 1y ago
    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. 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 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/internal/handle-resolver https://github.com/bluesky-social/atproto/tree/main/packages...
  - magicalhippo 1y ago
    I'm going off your post here. 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 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.
    - bnewbold 1y ago
      (I added a reply up-thread here: https://news.ycombinator.com/item?id=45469667 https://news.ycombinator.com/item?id=45469667)
    - thisismissem 1y ago
      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/ 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.

deleted 1y ago

[deleted]

magicalhippo 1y ago

> "DNSSEC is not required" 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.

danabramov 1y ago
>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? 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.
- thisismissem 1y ago
  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. 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 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/internal/handle-resolver https://github.com/bluesky-social/atproto/tree/main/packages...
- magicalhippo 1y ago
  I'm going off your post here. 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 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.
  - bnewbold 1y ago
    (I added a reply up-thread here: https://news.ycombinator.com/item?id=45469667 https://news.ycombinator.com/item?id=45469667)
  - thisismissem 1y ago
    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/ 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.