Disable non-ASCII domain names until we've evaluated homograph mitigations

[JeremyRand]

Non-ASCII domain names are, on a technical level, vulnerable to homograph attacks that enable impersonation. In the DNS world, this risk is mitigated by DNS registry policies that disallow registering a domain name that is a homograph of an already-registered domain name. (Homographs of TLD's are mitigated by a similar policy at the ICANN level.)

Unfortunately, Namecoin's content-neutral design (specifically the fact that name identifiers are binary blobs without any processing performed as part of the consensus rules) makes it rather difficult for Namecoin to enforce a DNS-like policy on registration time. Enforcing a DNS-like policy on lookup time is probably possible, but it's going to be messy (I suspect that it will probably require adding an extra index, and it will probably also require keeping track of spent outputs).

As a short-term security stopgap until we've evaluated proper fixes, I'm recommending that we simply modify ncdns to refuse to resolve any non-ASCII domain names. The security improvement from disallowing homograph attacks outweighs whatever minimal usage of non-ASCII Namecoin domain names currently exists, especially since this is a security issue where we're currently significantly more vulnerable than the DNS is.

[JeremyRand]

My understanding is that @ryancdotorg agrees with my assessment and proposed stopgap fix -- Ryan, is that accurate?

[JeremyRand]

Some additional notes.

Punycode-encoded DNS labels begin with xn--. So blacklisting all .bit domains whose 2nd-level label has that prefix should be sufficient to prevent IDN's from resolving.

Various client-side and registry-side defenses exist. Some clients, e.g. Opera, only display IDN's if they are on a whitelisted TLD that is known to deploy registry-side defenses. As of 2017 April, Firefox and Chromium used client-side defenses that were exploitable.

Another vulnerability was reported to Firefox in 2017 January 20, and was closed as WONTFIX on 2017 January 25; Mozilla's position can be paraphrased as "this is the registry's problem, not the client's." I can confirm that Tor Browser 9.0.5 (latest release as of 2020 March 12) in "Safest" security mode is still vulnerable to the attack site.

ICANN maintains a set of IDN Implementation Guidelines, which are presumably what we would want to base our long-term mitigation on. Unfortunately, the draft 4.0 spec from 2018 May 10 states in Sec. 2.8:

It is important to understand that not all visual similarity issues can be addressed by IDN Tables and IDN policies. Other policies such as dispute resolution policies may be necessary to mitigate against abusive registrations exploiting visually similar characters. For example, even for ASCII letters,digits and hyphen (LDH)basedrepertoire, where the small letter "l" and digit "1" may be considered visually confusable characters,the mitigation policy for abuse is often addressed by dispute resolution policies, leveraging other bodies of knowledge (e.g. Trademark Law) to evaluate whether similarities between domain names causes confusion and abuse.

Given that Namecoin, by design, does not have any mechanism for trademark disputes, it appears that securely handling IDN's (in any mechanism other than not displaying them as Unicode) in the context of Namecoin-like systems is an unsolved research problem, and I would not want to place heavy bets on it being solved anytime soon.

[ryancdotorg]

I think blocking them for now is prudent.

The best mitigation I've seen is preventing characters from different languages being mixed, but this is complicated.

[JeremyRand]

I think blocking them for now is prudent.

Okay, thanks.

The best mitigation I've seen is preventing characters from different languages being mixed, but this is complicated.

@ryancdotorg That approach is still vulnerable to the attack that Firefox closed as WONTFIX. Any other reasons that you refer to it as complicated?