300132 - Add .lt, .info, .th, .ac, .io, .sh, .tm, .gr, .br to IDN whitelist

Status: RESOLVED FIXED

(Core :: Networking, enhancement)

Description

[Gervase Markham [:gerv]]

I have approved the following TLDs to be added to the IDN whitelist. As more
apply, I will add comments as I approve them. After a certain amount of time, we
will make and check in a patch.

Gerv

Comment 1

[Gervase Markham [:gerv]]

Approved:

.lt, .info, .th, .ac, .io, .sh, .tm.

Gerv

Comment 2

[Wil Tan]

I'm concerned about .ac:

Google cache:
http://66.102.9.104/search?q=cache:VqhSxRNehy8J:www.nic.ac/+nic.ac&hl=en&client=firefox-a
Way back machine:
http://web.archive.org/web/20041130033107/http://www.nic.ac/

The page has not been updated since 2004-november, and suddenly they have a
policy. In fact their FAQ page (to which they have unlinked from the home page)
is still there: http://www.nic.ac/idnfaq.html#4


Same goes for .sh, .tm, and .io:
http://www.nic.sh/idnfaq.html#3
http://www.nic.tm/idnfaq.html#4
http://www.nic.io/idnfaq.html#4 (copy and pasted from .TM verbatim)

Comment 3

[Jo Hermans]

(I checked the .tm registry, although they're all copies of eachother).

I don't think we should allow these registrars, becuase they accept ALL
characters ! This is the reason that we have the IDN whitelist.

>What characters are authorised in .TM IDNs?
>.TM Registry wants to give you maximum flexibility when it comes to protecting
>your assets on the Internet. Because .TM names can be registered and used
>worldwide, we did not want to put artificial limitations in the langage or
>script that can be used. Therefore there is no limit in the special characters
>you can use, providing your name can be translated in ACE form, and registered
>that way.

And further :
>It is your responsability to ensure that the ACE form produced by our Encoder
>is consistent with what you want to register.

This means they don't even check, and they don't want to take reponsability.

I tried with the infamous paypal-example from bug 279099, and their IDN encoder
accepted it (pаypal.tm --> xn--pypal-4ve.tm) ! Whois says that it's still
available :-)

Ok, I know that Turmenistan also uses the cyrillic script, and they might accept
the а. But the point is that it shouldn't be mixed with other scripts.

Comment 4

[Gervase Markham [:gerv]]

Approved: .gr, based on email assurances received.

Gerv

Comment 5

[Gervase Markham [:gerv]]

William: if they have updated their policies to meet our requirements, that can
only be a good thing :-) OK, the IDN FAQs don't match the newly-linked policy.
We should get them to clear that confusion up.

I assume their translator widget doesn't impose the same restrictions as their
backend systems.

Jo: they don't accept all characters any more; see the policy PDFs linked from
the URL in the URL field.

Gerv

Comment 6

[Gervase Markham [:gerv]]

Approved: .br.

Gerv

Comment 7

[Wil Tan]

Fair enough. As long as they do enforce it.

Comment 8

[Gervase Markham [:gerv]]

If they don't, I'm sure you'll be the first to follow the instructions at the
URL and email the Mozilla security group :-)

Gerv

Comment 9

[Darin Fisher]

-> gerv

Comment 10

[Gervase Markham [:gerv]]

William: the issues raised in your comment #2 have been addressed.

Gerv

Comment 11

[Hixie (not reading bugmail)]

gerv: will mofo be doing spot checks on these registrars? Would probably be a
good idea to be pro-active in checking that the people on our whitelist are
actually as safe as they claim.

Comment 12

[Gervase Markham [:gerv]]

Ian: good question. I wasn't planning to, for the following reasons:

- It's hard to check - the only real check is noticing a domain which has been 
  issued in violation of policy

- I'm sure that the registries know that if they start issuing homographic 
  domains, they'll get:
  * a load of negative publicity
  * angry phone calls from their ASCII customers that they might get spoofed
  * a security update from us disabling their TLD 
  * angry phone calls from their IDN customers, as their domains now look like 
    gibberish in Firefox
  * great difficulty in getting it re-enabled.

I suspect no registry sees that as a good business move.

Gerv

Comment 13

[Hixie (not reading bugmail)]

The kind of check I was thinking about was just going out and attempting to
register homographic domains. It seems like that would be a good idea to me.

I have no fear that the registrars would intentionally allow such registrations.
My fear is that they would unintentionally, through incompetence, allow them.
That is, after all, basically how the original "paypal.com" IDN domain got
registered -- the policies in that particular case would theoretically have
stopped it.

Comment 14

[Wil Tan]

For the record, Eric's "paypal.com" was registered not through Verisign's or
anybody's incompetence, but sheer negligence.

Comment 15

[Gervase Markham [:gerv]]

I think the profile of the issue has been raised so dramatically since then that
registries will be very careful in how they write and test their domain-checking
code.

Any independent security researcher is welcome to do such testing and, if
problems are found, report them to the Mozilla security group.

Gerv

Comment 16

[Hixie (not reading bugmail)]

Why would Mozilla not want to proactively check such policies?

Comment 17

[Wil Tan]

I agree with Gerv that the job of keeping tabs on various registries' policies
fall outside the scope of MoFo's main functions. That said, it is worrisome that
there could be discrepancies between what's advertised as policies and what's
really enforced. For example, Verisign com/net IDN policies goes something like:

1. Registrars are to submit the IDN to be registered along with the proposed
language that the name is intended to be.
2. The domain name is then checked against the list of allowable characters for
that language. The entire domain must fall inside the list of languages or the
registration would be rejected.
3. The currently deployed language tables are: Chinese, Japanese, Koren, Polish,
Greek, ...

What's in between the lines is that if you submit a language tag for which they
have no language table, the entire Unicode 3.2 (minus the ones prohibited by
IDNA) becomes the table.

See
http://www.verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/idn-standards/idn-character-variants/page_002089.html

This is a prime example of discrepancy between policy and implementation. And
the only way to find out is to actually try to register a name with the
respective registries.

A number of registries, such as .museum, are safe because the registration
process is manual, and requires the registrant to prove their eligibility.

If MoFo has the budget to periodically check on these registries, I'd be glad to
police the registries :)

Comment 18

[Gervase Markham [:gerv]]

OK, it's rollup time. This bug's bags are packed with the following TLDs:
.lt, .info, .th, .ac, .io, .sh, .tm, .gr, .br.
and it's heading out the door and down to the station for the 1.8b4 train.

Any further requests will go into a different bug, and probably be in the next
release rather than this one. There's a potential clash with bug 299927; we'll
try and get that in first.

Gerv

Comment 19

[Gervase Markham [:gerv]]

Attachment: Patch v.1

Here's the (trivial) patch. Requesting approval for 1.8b4, and rubber-stamp
review from jshin.

Gerv

Comment 20

[Jungshik Shin]

Comment on attachment 189765 [details] [diff] [review]
Patch v.1

rs=jshin

Comment 21

[Gervase Markham [:gerv]]

OK, this patch is actually post-checkin of bug 299927, so there will be no conflict.

Gerv

Comment 22

[Gervase Markham [:gerv]]

Fixed.

Checking in modules/libpref/src/init/all.js;
/cvsroot/mozilla/modules/libpref/src/init/all.js,v  <--  all.js
new revision: 3.584; previous revision: 3.583
done

Any more people, please email me in the usual way, as described on:
http://www.mozilla.org/projects/security/tld-idn-policy-list.html

Gerv