Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Treat Namecoin to non-Namecoin CNAME as insecure #18

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Treat Namecoin to non-Namecoin CNAME as insecure #18

wants to merge 1 commit into from

Conversation

JeremyRand
Copy link
Member

The DNS by design assumes that the ICANN root, registries, and registrars are generally trustworthy. As such, CNAME records in the DNS can delegate trust to a name, but not to a key. This assumption, however, doesn't hold in the case of Namecoin, which by design does not trust the ICANN root or any other part of the DNS naming system.

There's not really a good way to convey this difference in trust assumptions to DNSSEC software like Unbound. This PR picks what I think is probably the least bad way. It implements a domain suffix bit._insecure_bit., which mirrors bit. but is intentionally not trusted by DNSSEC software. Any CNAME record in a .bit domain that points to a DNS name is rewritten to point to the corresponding .bit._insecure_bit domain, which in turn points to the DNS name. The effect is that DNSSEC validators will see an insecure zone along the chain from the .bit name to the DNS name, and will therefore consider such CNAME records to be insecure. This does not make the records appear to be bogus. In practice, this means that applications that don't require DNSSEC will work fine (e.g. A and AAAA records), but applications that do require DNSSEC (e.g. TLSA and SSHFP records) will refuse to accept these records. Users who want to safely delegate to something outside of Namecoin have 2 main options:

  1. CNAME example.bit, but don't CNAME _443._tcp.example.bit.
  2. Use NS+DS instead of CNAME.

It should be noted that the intention of this feature is not to prevent name owners from being malicious or from misconfiguring things in highly inventive ways. There will always be ways to misconfigure a system to make it insecure. The intention is to remove a common, easily identifiable footgun, similar to how most web browsers treat anonymous DH ciphersuites, SSLv3, MD5 signature hashes, and Debian-bugged public keys as insecure.

Open questions:

  • Is there a less annoying way to convey this difference in trust assumptions to DNS software?
  • Will ICANN and/or IETF be pissed off that we're squatting on the ._bit_insecure TLD?
  • Will the use of underscores in the intermediate names break any common software?
  • Should something similar be done for SRV/MX records that point to DNS names?
  • Are there any real-world use cases that this breaks, which we want to support? It basically breaks DNAME. AFAIK DNAME is really rare in real-world deployment. Should we add a shorthand JSON field that generates CNAME records for a subset of subdomains (e.g. generating CNAME records for everything that doesn't start with _port._protocol)?
  • For that matter, do we want to support the use case of delegating trust to the ICANN root key? I think this is a really bad idea whose primary result will be footgunning. Is there a legit reason I haven't thought of for supporting this use case? If so, what's the best way to support it without being a footgun factory?

@JeremyRand
Don't trust the ICANN root key (i.e. cause Unbound to clear the AD bi…
2082ff8 
…t) in cases where a Namecoin name CNAMEs or DNAMEs to a non-Namecoin name.
@hlandau
Copy link
Member

hlandau commented May 25, 2017

NAK.

If a .bit domain owner wants to CNAME to an ICANN domain, that is their prerogative, and making policy about this is out of scope for ncdns.

The purpose of ncdns is to serve d/ zone data via the DNS protocol. It does this. The purpose of this PR is to make it not do that in certain ways to further a substantially political policy objective. It causes ncdns to act contrary to its defining purpose.

Moreover, the change acknowledges its own futility by pointing out it's impossible to secure domain operators from themselves. As such, even if the change was in-scope for ncdns, I don't think it's justified; it violates the principle of least astonishment and does something highly eccentric, all to fail to accomplish something.

@JeremyRand
Copy link
Member Author

JeremyRand commented Jun 5, 2017 via email

@JeremyRand
Copy link
Member Author

JeremyRand commented Jun 9, 2017 via email

@JeremyRand JeremyRand closed this Jun 10, 2017
@JeremyRand
Copy link
Member Author

So, I'm going to defer to the Tor developers on this. If Tor changes their policy on this, or if someone points out to me that I'm incorrect in assessing Tor's current policy, then I'll worry about re-opening this then.

Tor is considering changing their policy on this. H/t to George Kadianakis for tipping me off about this development. Re-opening this PR for now, but waiting to see what Tor's conclusion is before taking any action.

@JeremyRand JeremyRand reopened this Nov 27, 2017
@JeremyRand
Copy link
Member Author

In particular, the below scenarios described by Tom:

 7. HTTP Onion with HTTPS Subresources: Strikethrough
 8. HTTPS Onion with HTTPS Subresources: Strikethrough
 9. HTTPS Self Signed Onion with HTTPS Subresources: Strikethrough

Seem to reflect our situation rather closely.

@JeremyRand
Copy link
Member Author

If I'm not mistaken, this approach will still mark delegation of the form "Namecoin -> NS/DS -> nameserver -> CNAME -> .com domain" as secure. That doesn't disqualify this PR, since this PR deals with what is by far the most common case, but we should ponder whether we can do better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@JeremyRand @hlandau