-
Notifications
You must be signed in to change notification settings - Fork 17
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.
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
IDN Name Handling #14
Comments
I heard an interesting idea at the ENS workshop yesterday, where different character sets could be displayed in different colors. That might be ugly, but could be a nice security measure. Of course, since it's about display, that idea would be a UI feature, and wouldn't really have a place in this module. |
I believe that there are a few steps that we could take. The first is to restrict names to characters that come from a single language, using block identifiers as per https://en.wikipedia.org/wiki/Unicode_block This avoids the issue where someone attempts to spoof a name using a single homograph in an otherwise-latin name (e.g. using аcompany with a cyrillic 'а' rather than the latin acompany). The workable rules that have been found are a bit more complex, and found in the IDN display algorithm link in the OP. The second is to use some sort of reduction-to-latin. In this step, names such as 'ѕрасе.eth' would be reduced to their latin 'space.eth'. At this point there can be a check of the latter name to see if it resolves to an address (and specifically a different address to the non-latin version) and if so flag as suspicious. The issue here is that the restrictions are tighter than those for registering an .eth domain so it will cause some registered names to be unresolvable. Of course, that's kind-of the point of doing this but we have to consider that there might be some valid names that end up being unresolvable. I would suggest that we can start off handling this with PRs to whatever specification we put together, either to upgrade the algorithm or to add to a whitelist. It's also worth pointing out that these are a subset of an idea that I'm working on that should provide more validation points and make provide a clearer indication as to if a name, and its resolved address, should be considered valid. I'll try to get some more details of this out in the next week. |
Existing browsers have sets of conditionals for performing name lookups and partially mitigating homograph attacks. In their case, DNS is ascii based so they can resort a punycode.
Since ENS is Unicode-based, it's unclear how clients like Metamask, MEW or Status should handle this problem.
https://www.chromium.org/developers/design-documents/idn-in-google-chrome
https://wiki.mozilla.org/IDN_Display_Algorithm
http://www.unicode.org/reports/tr39/#Restriction_Level_Detection
The text was updated successfully, but these errors were encountered: