Security issues such as specific security problems or ideas for making the code as a whole more secure can be discussed here

Gervase Markham | 5 Jul 2012 10:37

IDN TLD whitelist, and .com

As some participants may recall, our IDN TLD whitelist was created in
response to the "payp-cyrillic-a-l.com" incident of 2005.

http://www.shmoo.com/idn/

Since that time, we have whitelisted over 50 TLDs after having inspected
their anti-spoofing policies.

http://www.mozilla.org/projects/security/tld-idn-policy-list.html

Recently, it was decided that a whitelist was not scalable in the face
of hundreds of new TLDs, and that we had to come up with a new approach.
We did, based on some suggestions from the Unicode Consortium:

https://wiki.mozilla.org/IDN_Display_Algorithm

The new criteria are not as strict as the old (for example, they can't
spot whole-script homographs (All-Latin "scope.tld" vs all-Cyrillic
"ѕсоре.tld"), but are the best we can do programmatically without a
manually-maintained whitelist, and without compromising other principles
(like "works somewhere => works everywhere").

Up until now, Verisign have not formally applied for inclusion in the
TLD whitelist, although preliminary discussions have occurred on more
than one occasion. Now, they have applied (for .com, .net and
..name), and their current policies do meet the new criteria:
https://bugzilla.mozilla.org/show_bug.cgi?id=770877

However, given that it was a .com domain which started all this fuss, I
thought it was worth posting publicly in case anyone had any comments.

(Continue reading)

headers

Daniel Veditz | 5 Jul 2012 17:39

Re: IDN TLD whitelist, and .com

On 7/5/12 1:37 AM, Gervase Markham wrote:
> Recently, it was decided that a whitelist was not scalable in the face
> of hundreds of new TLDs, and that we had to come up with a new approach.
> We did, based on some suggestions from the Unicode Consortium:
> 
> https://wiki.mozilla.org/IDN_Display_Algorithm

Big thanks to you and Simon Montagu for driving this forward!

Given that the new criteria are not as strict as our old policy, why
would we want to preserve the old whitelist system in parallel? The
big flaw in the whitelist policy was that a registrar's policy
applied to the domain labels directly issued by that registrar but
not to any sub-domains created by the domain owner. Those
sub-domains could be as many levels deep and as spoofy as they'd
like. The new algorithm, in contrast, applies to each label
separately and will prevent spoofy sub-domains.

If the stated policies of the currently whitelisted TLDs fall within
the new algorithm let's just scrap the whitelist. Even if some small
percentage of edge-case domains end up being flipped to punycode the
code and policy simplification on our end will be worth it.

If there were any such edge-case domains would they be shown as IDN
in any of the other browsers (besides Opera who uses the same
whitelist mechanism)?

> Now, they have applied (for .com, .net and .name), and
> their current policies do meet the new criteria:
> https://bugzilla.mozilla.org/show_bug.cgi?id=770877

(Continue reading)