{"action":"created","issue":{"url":"https://api.github.com/repos/hlandau/ncdocs/issues/12","labels_url":"https://api.github.com/repos/hlandau/ncdocs/issues/12/labels{/name}","comments_url":"https://api.github.com/repos/hlandau/ncdocs/issues/12/comments","events_url":"https://api.github.com/repos/hlandau/ncdocs/issues/12/events","html_url":"https://github.com/hlandau/ncdocs/issues/12","id":79262638,"number":12,"title":"Ignore all TLSA fields from untrusted sources","user":{"login":"JeremyRand","id":244188,"avatar_url":"https://avatars.githubusercontent.com/u/244188?v=3","gravatar_id":"","url":"https://api.github.com/users/JeremyRand","html_url":"https://github.com/JeremyRand","followers_url":"https://api.github.com/users/JeremyRand/followers","following_url":"https://api.github.com/users/JeremyRand/following{/other_user}","gists_url":"https://api.github.com/users/JeremyRand/gists{/gist_id}","starred_url":"https://api.github.com/users/JeremyRand/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/JeremyRand/subscriptions","organizations_url":"https://api.github.com/users/JeremyRand/orgs","repos_url":"https://api.github.com/users/JeremyRand/repos","events_url":"https://api.github.com/users/JeremyRand/events{/privacy}","received_events_url":"https://api.github.com/users/JeremyRand/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/hlandau/ncdocs/labels/domain-names","name":"domain-names","color":"5319e7"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":8,"created_at":"2015-05-22T03:27:05Z","updated_at":"2015-05-26T02:51:02Z","closed_at":null,"body":"As a follow-up to https://github.com/hlandau/ncdocs/issues/11 , I propose the following:\r\n\r\nAll security-critical DNS records (e.g. TLSA and SSHFP) MUST be ignored if any of the following is true:\r\n\r\n1. The record is retrieved from a nameserver (delegated via NS) that does not have a corresponding DS record.\r\n2. The record is retrieved via a CNAME.\r\n3. The record is retrieved via a DNAME.\r\n\r\nThe following workarounds are RECOMMENDED:\r\n\r\n1. Have example.bit CNAME to ip.example.bit, have ip.example.bit NS to the untrusted nameserver, and have a TLSA record in the blockchain for _port._protocol.example.bit.\r\n2. Only CNAME example.bit, but do not CNAME _port._protocol.example.bit.\r\n3. Use multiple CNAMEs instead of DNAME, since DNAME is inherently insecure.\r\n\r\nThe wallet GUI's SHOULD automatically warn the user when an insecure configuration exists, and SHOULD offer to apply one of these workarounds.\r\n\r\nNon-security-critical DNS records (e.g. A and AAAA) MUST be unaffected by these rules, since the worst that can happen as a result of a successful attack is a DoS rather than a MITM.\r\n\r\nOpen questions: \r\n\r\n1. A trusted nameserver has its own untrusted delegation.  How easy is it to detect this case reliably?\r\n2. How does untrusted delegation via SRV or similar things get handled?  I assume we have to ignore all the TLSA records associated with those delegations?  How easy is it to detect this case reliably?"},"comment":{"url":"https://api.github.com/repos/hlandau/ncdocs/issues/comments/105368408","html_url":"https://github.com/hlandau/ncdocs/issues/12#issuecomment-105368408","issue_url":"https://api.github.com/repos/hlandau/ncdocs/issues/12","id":105368408,"user":{"login":"indolering","id":44454,"avatar_url":"https://avatars.githubusercontent.com/u/44454?v=3","gravatar_id":"","url":"https://api.github.com/users/indolering","html_url":"https://github.com/indolering","followers_url":"https://api.github.com/users/indolering/followers","following_url":"https://api.github.com/users/indolering/following{/other_user}","gists_url":"https://api.github.com/users/indolering/gists{/gist_id}","starred_url":"https://api.github.com/users/indolering/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/indolering/subscriptions","organizations_url":"https://api.github.com/users/indolering/orgs","repos_url":"https://api.github.com/users/indolering/repos","events_url":"https://api.github.com/users/indolering/events{/privacy}","received_events_url":"https://api.github.com/users/indolering/received_events","type":"User","site_admin":false},"created_at":"2015-05-26T02:51:02Z","updated_at":"2015-05-26T02:51:02Z","body":">@indolering Specifically what use case requires DNAME? A DNAME is just an automatic generator of CNAME behavior for all subdomains; as far as I can tell that is not required for any major use cases.\r\n\r\n*indolering reads the DNAME spec*  Well argle-fucking-bargle.\r\n\r\nI largely agree with hl: if someone wants the full security offered by a .bit site, then they shouldn't be using another TLD.  I see this primarily being used by small blogs and other sites that don't need the full protections offered by .bit and I think a warning is good enough.  It's similar to a site operator deciding to use JS or other assets hosted on a regular domain.  Ultimately, the security for the site comes down to the site operator, not the user.\r\n\r\nI would support a non-standard record that enables an operator to specify a valid TLSA record but (if I understand this AD setting correctly) any option to not trust the TLD root should be turned off by default and hidden away behind something akin to about:config."}}