Treat Namecoin to non-Namecoin CNAME as insecure

[JeremyRand]

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?

[hlandau]

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]

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

I'm curious, have other non-DNS TLD's addressed this issue or analogous ones? For example, does Tor Browser consider .onion URL's to be in a different security scope to DNS URL's? Might make sense to do whatever Tor does rather than making policy separately.

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZNSzjAAoJELPy0WV4bWVwuRUQAJgd3q2jUY/y2MoTvTUINPNQ 0g6ZTEsJFVmb9VBIoKZzwjQv0Xi2RgL8pdwCN/urk8PuFt1Uz9pNG4aLrDoMz4bd VVM49RnGFDf/eGs5IbpeqVOhMy0fAkEPCoYsUG+HjUoocmQJVcSzDaiOe2pA8lon zCgD3Vb5ZKqP7PrnD0cKxp7NhxxiaT5+JHBMNd4rKFv+wh/Nn9tlaWYXoxPiAehK d+o5cSGPpXmgurpTYd0RX6CK+yfUETX3OLNiZy13Vf/rUohYcz2o6JAy9on8koeS miiPF9YUBO4ZPfsifw7WUpVWYdWtVv6QOWY1cK8HJnwo9FgZJ18hTY+8J6ihNgkm lZBhXLd4/WLG+3bVpVMaZlxPGbVOWt/s4EN3pmjs2qVNw9HHMPR375mpooC+qPZB jqpDz4QWHpJf2PmZlFpojo3m5DHEXvJQV5pOUkfMOQpLK6+STTHRzX1DvamIhBE/ hOH0IMI4bRg9CUW4ZdjyjLJBqoaE6W5w+Zq9uWJUc7TY8k1YVkko5er8SirntfhG 57qvODQmbd5uyA6fewzt0WLRv3onoxdN4DkBvgwH071rmsh30Tl942vmjmjDJyWI lK5ocjm+tElDI5FwPQFmlXZFt82FTSYNtk7P2xb7c54XOtkEo3SLIEa36vSClrpj TXXNqrkIpGCemVClwpk7 =CYyg -----END PGP SIGNATURE-----

[JeremyRand]

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

JeremyRand:

I'm curious, have other non-DNS TLD's addressed this issue or analogous ones? For example, does Tor Browser consider .onion URL's to be in a different security scope to DNS URL's? Might make sense to do whatever Tor does rather than making policy separately.

I just briefly searched the Tor Trac, and wasn't able to find any examples of such a discrimination policy. The closest thing I could find was the behavior in these links:

https://trac.torproject.org/projects/tor/ticket/22320 https://trac.torproject.org/projects/tor/ticket/17334 https://trac.torproject.org/projects/tor/ticket/9623

If I'm reading the relevant code properly, it appears that destination DNS names are treated identically to destination .onion names in terms of Referer policy.

Also, AFAICT Tor Browser actually treats HTTP .onion URL's as less trusted than HTTPS DNS URL's. (The latter are allowed to run Javascript in Medium Security mode; the former are not.)

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.

Consider this issue WONTFIX from my point of view.

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZOeeQAAoJELPy0WV4bWVwMmAP/3toKZcDv5ErgkRUW2KumUlH bdU6Gj0zowedje2mThQT5u+W12hDsL7iWYqRgETuPThbGno/tsgkCzL+yaDOE36r 0Hnh3IZdG7070ptFLrv9YteViryKGhGyvHLrWzcKAu0pP/lVOEMuW4gc8fAslpOt 24lagrXHze0pIsoPOB6oqA3iKJfVphA05VlJvoq/xWfO1FTD09xfQly8uCuZUTzR 7uqo5OqFEYulKmBl8wUPxGfSCIKvXWTQwZb6pThwBVEn+mptAi9o8KYey1HUsIkV lJKeJ4pQTHKbYRLQlvWcLCTTPIEdxA+kIYUl3fEkK1BQD5lSxz2sQ4lj56pdk/UU ZWAdOPBqiFPLikPtl/dR1lR2G20I54PME7BcdkBO/bGVqoY1dVT9Z4jwex71p887 QK3NwUSYFHaj6Z+XiXxTfYUo+uv2qQas3LRGul7ConzYy4ayXJpMKMbucWeAQwMi TFurDTUdBWwRkFqjlIpHwZwJ+KdPrp3/4EQuasru9P8e/WkI2azUT2oTI3dmoUeX udmBGeVsbe5086YToK2eJfHJfcgxhIimvNWuLEsNL7BJK16VwSvg+C7PH6tav2V1 0Jv8HjEZ5koYmSn3+ZsitQPaoYhXJQXP7fuHFV+4wuyD2FLYIHtwkyHI7hlQ4oik rYHSPaRshrnHYVm4RGg3 =uN8G -----END PGP SIGNATURE-----

[JeremyRand]

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]

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]

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.