Subject: [idn] RRP and language tags

From: Erik van der Poel <[email-masked]>
Date: Sat, 19 Feb 2005 06:01:59 -0800

[Removing [email-masked] and adding [email-masked]]

Yesterday, it seemed like some people agreed with me that, in the 
general case, the language tag being passed in the RRP protocol is not 
just naming a character table to filter against, but, more generally, a 
set of rules that the registry applies to determine registerability.

Ignoring for now whether we can decide that there is consensus on this 
issue, I'd like to explore the issues some more, and ask a few 
questions, if that's OK.

First, the language tag is just a name, so in some sense it does not 
really matter *what* it is naming, whether that be a human language, a 
registry's table of characters, or a registry's set of rules. But if we 
can show that ISO 639 is not an adequate namespace, then we may wish to 
consider a new namespace.

One reason that 639 might not be adequate is that some languages are 
used in more than one part of the world, and that usage may differ 
enough from one community to another that we want to assign two separate 
codes instead of a single 639 code. A very common way to go about this 
is to simply add a country code (ISO 3166).

However, currently it seems like the trend is to have a number of sets 
of rules, one at each NIC. The .jp registry has a table and some rules, 
the .de registry has a table, and so on. Some organizations appear to be 
working together to unify their methods. China and Taiwan come to mind. 
This trend might lead one to think that the RRP tag should not be a 
language, but simply the name of a NIC or TLD or pair of TLDs.

But this might be too restrictive. What if some organization or 
individual comes up with a set of rules that is desirable for a number 
of reasons, such as the inclusion of a large number of characters? Some 
registries may wish to allow registrars (and by extension, registrants) 
to specify the use of such a set of rules.

This would argue for maximum flexibility in the RRP tag namespace. I.e. 
it should not be limited to 639 or to 639+3166 or to ccTLD name. It 
could just be a separate namespace, possibly with an IANA registry, 
similar to the numerous other namespaces registered there. Charsets come 
to mind, but there are many others. Such a new namespace would even 
allow for private agreements, which usually have names that start with 
"x-" in other IANA namespaces.

Any thoughts on these ideas?

And now for the questions: Where is this RRP spec? Is it an RFC? Which 
RRP document specifies the language tag we have been talking about?

Do all of the registries use RRP? If not, what do they use? And do they 
have language tags?

Thanks,

Erik

---

From: "Edmon Chung" <[email-masked]>
Date: Sat, 19 Feb 2005 09:57:35 -0500

----- Original Message ----- 
From: "Erik van der Poel" <[email-masked]>
> RRP document specifies the language tag we have been talking about?

There is an RFC for RRP: 3632, but I believe it may not be the most updated version due to some additional features that VeriSign has added.  However, I would let Scott/Pat speak to it more definitively.

> Do all of the registries use RRP? If not, what do they use? And do they 

EPP (Extensible Provisioning Protocol) is the ICANN preferred protocol going forward I would say, but again, I would really defer to Tina for more authoritative position.

There was an IDN-over-EPP BOF held earlier in the last IETF and there were some presentations done during the Capetown ICANN in Dec 2004.  Currently we are trying to setup a mailinglist to further discuss the matter in fact, and the matter has been initiated and is with the Apps area director Ted Hardie at the moment.

Personally, I think this is definitely an item that we should work on and provide a standardized framework for.  In fact during the ICANN meetings, the presentations at ccNSO and at the Registrar Constituency yielded good results and interest.  The ccNSO also reported support for efforts to standardize the EPP extension approach for IDN.

Edmon

---

From: Erik van der Poel <[email-masked]>
Date: Sat, 19 Feb 2005 08:29:36 -0800

Regarding the IDN spoofing issue, I'd like to offer the following 
analysis, and hope that people will point out anything that's missing.

For IDN names, there are 2 different times:

1. registration time
2. lookup time

At each of these times, we start with textual symbols, give them codes 
(Unicodes), perform nameprep and encode into punycode. After a lookup, 
we might also display the name for the user. There are other details and 
various cases to consider, but this is the big picture. These are the 
basic stages that a name progresses through.

Now, the IDN spoofing issue is one of look-alikes. We can attack this 
look-alike problem by focussing on an early stage, an intermediate stage 
or a late stage. The terms often used for stages that progress from one 
end to another are upstream and downstream.

If we were to try to solve the look-alike problem all the way upstream, 
we would focus on Unicode. This character encoding gives distinct codes 
to textual symbols that look similar or are even identical, in both form 
and function. Michel even admitted that many of the Latin letters in the 
Cyrillic block were added only to keep people from having to switch 
scripts midstring. So these characters are identical in appearance and 
use. Ignoring for the moment whether this is realistic, one way to solve 
the look-alike problem is to have Unicode get rid of these look-alikes. 
In Unicode parlance, it would then become a glyph encoding, rather than 
a character encoding.

Going further downstream, we have nameprep. This is another possible 
place to solve the look-alike problem. We could have a new version of 
nameprep that maps homographs to base characters. I.e. the look-alikes 
are folded. After this kind of nameprepping, we have characters that all 
look different. Again, no statement about whether such a change to the 
spec is realistic. This is just an analysis.

Downstream some more, we have the rules applied by the registry. The .jp 
registry seems to be well aware of the look-alike problem, and they have 
strict rules, with a well-defined table of characters to filter the name 
through. If the name contains characters outside that table, that name 
is rejected.

Going all the way downstream at lookup time, we have the string that is 
displayed to the user. Various people have been suggesting various ways 
to display the look-alikes so that the end-user will notice when 
something phishy is going on.

This concludes my analysis. It is rough, of course, but this is intended 
to be the big picture, and I hope it's complete. If this big picture is 
not complete, please point out what's missing.

Having concluded my analysis, I will now discuss which solutions are 
realistic. As far as I'm concerned, Unicode is an immovable object. 
There is probably zero chance that anybody could talk them into getting 
rid of look-alikes.

So what about nameprep? Should nameprep have chosen Unicode or some 
other character encoding? This part of nameprep is probably 
unchangeable. I doubt we could get consensus on switching nameprep from 
Unicode to some other encoding.

But what about the other parts of nameprep? Would it be possible to add 
another kind of mapping to it, namely from homographs to base 
characters? This would be a rather large change, and might even require 
a new prefix (i.e. something other than xn-- to allow migration). I 
don't really know whether this kind of change is realistic.

Next we have the registries. Kudos to .jp and all the others that 
carefully avoid look-alikes. But what about .com? As it turns out, in 
their current set-up, when VeriSign does not have a table for the 
requested language, the registry allows *any* Unicode to be registered. 
This is particularly egregious. They ought to fix this part, at least. 
Is VeriSign an immovable object? I don't know.

However, even if VeriSign were to have tables for all the languages, we 
would still have a look-alike problem. Consider a Russian name that 
consists entirely of Latin homographs. One solution is to make the 
language tag available to the application, possibly via a new DNS 
record. This is just an example, but the application could then put an 
icon of the Russian flag next to the domain name or URI. An American 
user *might* then realize that something phishy is going on. (Or they 
might not notice the icon, or ignore it.) The app could put up a dialog 
with a warning. It could do that the first time. But this is not a 
seamless user experience. Most app vendors aim for seamless.

Or the app could have different colors for different Unicode scripts. Or 
different colors for different language tags. They would do something 
special for the color-blind.

But, to me, all this just seems like we are foisting the problem on the 
end-user. Why oh why should they see any of this?

Or we could use heuristics, as Adam suggested, to try to detect 
phishyness. We could simply display the raw Punycode when the name is 
determined to be phishy. Maybe it's just me, but this is not very 
satisfying.

Can't we solve the problem upstream?

Erik

---

From: "Adam M. Costello" <[email-masked]>
Date: Sat, 19 Feb 2005 21:40:29 +0000

Erik van der Poel <[email-masked]> wrote:

> we might also display the name for the user.

Display time is independent of lookup time.  For example, the domain
names in the From: field of an incoming message is displayed, but not
looked up.  The mail application never looks up the name, even if a
reply is sent; a separate application (the MTA) does that.

In a browser, I might hover over a link before deciding whether to
follow it, so that I can see the domain name.  The domain name is not
looked up at that point.

We could consider advising all applications to start doing DNS lookups
on such occasions, just to get extra meta-info (like language tags) to
help display the name, but that seems too drastic, and there are still
situations where it's nice to be able to use applications offline.

> As far as I'm concerned, Unicode is an immovable object.  There is
> probably zero chance that anybody could talk them into getting rid of
> look-alikes.

Certainly.  The upheaval would be tremendously prohibitive.

> But what about the other parts of nameprep?  Would it be possible
> to add another kind of mapping to it, namely from homographs to
> base characters?  This would be a rather large change, and might
> even require a new prefix (i.e. something other than xn-- to allow
> migration).

It would certainly need a new prefix.  Also, names that get transported
in ACE form and converted back to Unicode for display would probably
take on a ransom-note appearance when single-script strings get
nameprepped into mixed-script strings.

> I don't really know whether this kind of change is realistic.

I think not.

> But, to me, all this just seems like we are foisting the problem on
> the end-user.  Why oh why should they see any of this?

You might as well ask why they should see domain names at all.
Maybe there's a way to abstract domain names out of the users' view
altogether, but until then, if users are going to see domain names, they
want to be able to tell whether the name they see is the name they think
they see.

> We could simply display the raw Punycode when the name is determined
> to be phishy.  Maybe it's just me, but this is not very satisfying.

The name can be flagged by displaying the Punycode, or by using a bright
color, or reverse video, or whatever.  As someone already suggested, the
ability to easily switch the display between the ACE and non-ACE forms
would be helpful.

> Can't we solve the problem upstream?

We don't know how many misleading names have already been registered
under .com and .net, so I don't see how we can completely solve the
problem upstream.

AMC

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 19 Feb 2005 15:32:03 -0800

Adam M. Costello <idn dot amc plus 0 at nicemice dot net dot

and later:

> The name can be flagged by displaying the Punycode, or by using a
> bright color, or reverse video, or whatever.  As someone already
> suggested, the ability to easily switch the display between the ACE
> and non-ACE forms would be helpful.

What about combining these two thoughts, and displaying the Punycode in
a tooltip (or elsewhere) when the user hovers over the domain name?

I realize that doesn't solve the problem for people who are *expecting*
a URL with non-ASCII characters, but it's a start.  It could be
implemented immediately in any IDN-aware browser, with no architectural
changes anywhere.

Apologies if someone already proposed this in one of the 278,000
previous messages on this topic.

-Doug Ewell
 Fullerton, California
 http://users.adelphia.net/~dewell/

---

From: Erik van der Poel <[email-masked]>
Date: Sat, 19 Feb 2005 16:07:54 -0800

Adam M. Costello wrote:
> Display time is independent of lookup time.

Good point. I did consider that, but I deliberately left it out of my 
"big picture". Perhaps I should have included it...

> Also, names that get transported

Over the years, the fonts seem to have grown, to include more and more 
of Unicode. A long time ago, in X Windows, it would definitely have 
looked like a ransom note. But these days, in Windows and even X Windows 
with larger fonts, it looks a lot better. So good, in fact, that it's 
hard to tell the difference between the homographs. (I was the chief 
architect of the multilingual font engines for the Windows and Unix 
versions of Mozilla. This is one area I'm really familiar with.)

>>I don't really know whether this kind of change is realistic.

Would you care to elaborate?

> want to be able to tell whether the name they see is the name they think

But then don't you think it's at least a little unfortunate that (a) 
Unicode chose to include duplicates and/or (b) nameprep chose to use 
Unicode? Previously, users only had to squint at ASCII 1 vs l. Now, with 
IDN, it has been taken to a whole different level. They have to endure 
colored letters that look identical but have been colored to indicate 
that their character codes are different. Most users don't even 
understand what character codes are. So I still feel that it's 
unfortunate that we now end up having to confuse users.

Of course, it's not clear that there will be very many of these phishing 
attempts, in which case the user will almost never see these colors. We 
may be blowing this issue out of proportion. Real phishers may find 
other, more devious ways to fool the user.

> under .com and .net, so I don't see how we can completely solve the

Actually, I've been thinking that one could write a program that 
determines which pairs of Unicode characters have been assigned the same 
glyph index in TrueType fonts on Windows. A registry could then check 
all the IDNs in their set to see which ones contain only ASCII 
homographs and ASCIIs. If there are only a few misleading names, they 
might be able to delete them by contacting their owners, etc. If there 
are many, well, I don't know.

But one thing these registries could do now or quite soon is to install 
some heuristic filters to try to stem the influx of bogosities. One can 
only hope...

Erik

---

From: "Adam M. Costello" <[email-masked]>
Date: Sun, 20 Feb 2005 11:08:17 +0000

> Would you care to elaborate?

Partly because of the ransom-note problem, partly because of the
deployment problem (new ACE prefix), but even if we dismiss those,
there's still the problem of characters that are supposed to use
different glyphs that are only slightly different and therefore easily
confusable.  So we'd be paying a fairly high cost (changing Nameprep) in
return for a disappointing benefit.

> don't you think it's at least a little unfortunate that (a) Unicode
> chose to include duplicates and/or (b) nameprep chose to use Unicode?

See Doug Ewell's post about how there's no good place to draw the line
for what counts as a "duplicate".  I don't think a different string
preparation or a different universal character set could have made
the situation a lot better in this regard; the scripts and characters
themselves (independent of any encoding) have too many shades of
similarity and distinction.  We can't limit ourselves to a set of
clearly distinguishable characters (some registries can, but a browser
can't), so we need to resort to other approaches, like looking at the
combinations of characters.

AMC

---

From: Erik van der Poel <[email-masked]>
Date: Sun, 20 Feb 2005 06:42:24 -0800

Adam M. Costello wrote:
> confusable.

I agree that some of the Unicode characters are only slightly different 
and therefore easily confusable.

But then, in the current climate, where phishing is becoming a larger 
problem and identity theft is growing fast, would you say that it is 
safe to use Unicode in *DNS*, one of the most important underpinnings, 
security-wise, of the Internet?

Let's take an analogy. The P.O. Box system. Right now, it uses numbers 
like P.O. Box 3256. What would happen if the Postal Service decided to 
use Unicode, where some of the characters are only slightly different, 
and the postman inadvertently put some important mail into the wrong 
box, one that was registered by an evil person, using a name that was 
only slightly different from the PO box of some company?

Wouldn't that company try to get the Postal Service to use a smaller set 
of symbols (say, digits) rather than this confusing Unicode? Maybe that 
company would even try to sue the Postal Service.

Erik

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 20 Feb 2005 09:22:00 -0800

Erik van der Poel <erik at vanderpoel dot org> wrote:

> Wouldn't that company try to get the Postal Service to use a smaller
> set of symbols (say, digits) rather than this confusing Unicode? Maybe
> that company would even try to sue the Postal Service.

Sadly, the Postal Service is fully capable of putting mail in the wrong
box without the help of Unicode.

Sorry.  Anyway...

The Postal Service probably would have instituted some type of subset of
valid characters for use in P.O. box identifiers.  (Or alternatively,
they would have a blacklist of invalid characters.)  At some point they
would discover, or have pointed out to them, confusables that they
hadn't thought of.  They would probably then amend their list to exclude
the newly discovered confusable.

THEN, because they are the Postal Service and have complete authority
over the entire system, they would be able to discontinue the use of the
evil P.O. box and require the user to change its name, or change it for
him, or refund his deposit.

Meanwhile, the reason they switched to Unicode in the first place was
precisely that they wanted to offer a wider variety of characters to
their users, for whatever reason.  Isn't that why domain names were
internationalized?  Isn't that the reason *anyone* switches to Unicode?
They must have had some benefits in mind by adopting a larger
repertoire.  By switching away from "this confusing Unicode" they are
giving up those perceived benefits.

If you have an application that lends itself to a limited repertoire,
like automobile license plates or P.O. box numbers or house numbers, use
that limited repertoire.  If you need a wider repertoire, you can use
Unicode and you can *still* implement a subset.  The problem, as always,
is in determining what the subset should be.

-Doug Ewell
 Fullerton, California

---

From: Erik van der Poel <[email-masked]>
Date: Sun, 20 Feb 2005 09:43:51 -0800

> is in determining what the subset should be.

Well put, Doug. It is easy to see how stringprep and nameprep got to be 
the way they are. First, you want domain names in local languages. 
Second, you don't want to mess with the myriad charsets used around the 
world for something as central as DNS, so you choose the only real 
alternative, Unicode. Third, it is a lot of work to create a subset (and 
it's controversial), so you punt, and just publish the RFC anyway.

Didn't some CEO say, "Does it compile? OK, ship it!"

These comments are probably very upsetting to various people on this 
list. Sorry! All I'm pointing out is that it is easy to see how we ended 
up like this, human nature being the way it is.

Moreover, it is grossly unfair for someone like me to come in so late 
and make all these comments, when I could have had my eyes on the ball 
at the critical time, instead of going off and working on something 
totally different all these years. Then again, I might have missed it 
too, or just gone along with the flow, even if I *was* here. It's really 
hard to focus on the critical issues when you have an open mailing list 
with all sorts of people bringing up all sorts of little examples from 
around the world. I looked at the archives of this mailing list, and 
there is a lot of noise.

Erik

---

From: "Adam M. Costello" <[email-masked]>
Date: Sun, 20 Feb 2005 23:42:56 +0000

Doug Ewell <[email-masked]> wrote:

> If you need a wider repertoire, you can use Unicode and you can
> *still* implement a subset.  The problem, as always, is in determining
> what the subset should be.

I'm with you both.  I wanted the IDN working group to define a subset,
but ultimately I was persuaded that it was not feasible for the IETF to
reach consensus on such a subset, and that subsetting could and should
be done on a per-registry basis, inside the registry rather than the
applications.  But the slash-homograph attack now makes that approach
(in its pure form) appear hopeless.

AMC

---

From: Gervase Markham <[email-masked]>
Date: Mon, 21 Feb 2005 00:00:26 +0000

> (in its pure form) appear hopeless.

Just to delurk for a moment... I'm currently kicking around ideas here 
at mozilla.org for dealing with this issue. We hope to be able to 
present a proposal soon.

What someone posted a day ago about "/" homograph attacks has meant that 
one thing we plan to do is have a short number of characters which are 
completely forbidden in IDN domains at any level - in that, mozilla.org 
products would refuse to recognise IDNs containing them.

My initial list includes the homographs of ":", ".", "/" and probably 
"\" too, plus all the space characters.

Of course, there may be some good reason why this doesn't fly.

Gerv

P.S. Of course, the slash homograph attack wouldn't fool the Firefox SSL 
domain security indicator anyway, which would still display the entire 
domain, fake slashes and all.

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 21 Feb 2005 04:53:11 +0000

Gervase Markham <[email-masked]> wrote:

> What someone posted a day ago about "/" homograph attacks has meant
> that one thing we plan to do is have a short number of characters
> which are completely forbidden in IDN domains at any level - in that,
> mozilla.org products would refuse to recognise IDNs containing them.

Please think twice before creating a precedent of a browser completely
blackholing a technically valid (albeit devious) site.  I think it would
be sufficient, security-wise, for the browser to inhibit the display of
domain names believed to be misleading, and to display them in ASCII
form instead, but still allow access to the site.

> "\" too, plus all the space characters.

I imagine you'd want all the characters that could immediately follow
the host name in a URI, so add "?" and "#" to that list.

But how well do average users know URI syntax anyway?  What would they
think of:

http://foo.com&bar.baz.xx
http://foo.com~bar.baz.xx
http://foo.com|bar.baz.xx

Maybe we either need to ban all punctuation (as in my proposal about
internationalized host names), or always make the boundaries of the
domain name apparent to the user (using color or highlighting or
underlining or something).

> P.S. Of course, the slash homograph attack wouldn't fool the Firefox
> SSL domain security indicator anyway, which would still display the
> entire domain, fake slashes and all.

Yes, but do users understand what that indicator means?  If they see
foo.com/bar.baz.xx in the indicator, do they understand that it is
unrelated to foo.com?

AMC

---

From: James Seng <[email-masked]>
Date: Mon, 21 Feb 2005 15:42:05 +0800

the way i look at the '/' problem is that it isn't a IDN problem but 
rather an URL specific problem. So i think the problem can be resolved 
in IRI do appropriate mapping.

-James Seng

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 21 Feb 2005 08:17:41 +0000

James Seng <[email-masked]> wrote:

> the way i look at the '/' problem is that it isn't a IDN problem
> but rather an URL specific problem.  So i think the problem can be
> resolved in IRI do appropriate mapping.

That's an interesting idea.  Maybe all homographs of the reserved
characters should also be reserved, which would mean they must always be
percent-escaped.

AMC

---

From: James Seng <[email-masked]>
Date: Mon, 21 Feb 2005 17:41:29 +0800

We do treat "." specially in IDNA because that's part of domain name.

Likewise, IRI should treat '/', '#', spaces etc specially as part of 
URL handling.

(if we ever get around to do email, i expect i18n email identifiers to 
handle a separate sets of symbols)

-James Seng

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 21 Feb 2005 11:17:12 +0000

> We do treat "." specially in IDNA because that's part of domain name.

Yes, but IDNA's special treatment of "." was motivated by user
convenience, not by defense against homographs of ".", so it's not
surprising that IDNA's special treatment of "." is insufficient to
prevent homograph attacks against ".".

For example, someone could register a name that looks like
"foo.bar.com", where the first dot was really U+0702.  This attack
would be equally effective no matter what larger structure (URI, email
address, etc) the domain name appeared in.

AMC

---

From: Gervase Markham <[email-masked]>
Date: Mon, 21 Feb 2005 23:37:20 +0000

Adam M. Costello wrote:
> blackholing a technically valid (albeit devious) site. 

If the site is devious, what possible benefit is there in allowing the 
user access to it?

If someone came up with a valid use for this character in IDNs, that 
would be different.

> the host name in a URI, so add "?" and "#" to that list.

Yes. It is looking a bit like "all punctuation", isn't it? But then, I 
bet there are some characters which look like punctuation. The Chinese 
character for the number 1 looks fairly like a hyphen.

> foo.com/bar.baz.xx in the indicator, do they understand that it is

Well, it would certainly be different to all the other times they'd 
visited mybank.com, so hopefully that would give them some pause.

Gerv

---

From: Gervase Markham <[email-masked]>
Date: Mon, 21 Feb 2005 23:34:37 +0000

> in IRI do appropriate mapping.

I'm afraid I don't understand what you are proposing. :-(

Gerv

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 21 Feb 2005 23:44:01 +0000

I wrote:

> IDNA's special treatment of "." is insufficient to prevent homograph
> attacks against ".".
>

On second thought, the "." homograph attack is less severe than the "/"
homograph attack.  The former only allows the attacker to spoof names
in the same domain that the attacker is registered in; therefore new
registrants can protect themselves from this attack by registering in
a domain with reasonable admission policies.  The "/" attack, however,
allows the attacker to spoof names in *any* domain, so there's nowhere
registrants can go and be safe from it.

The more severe attack can happen only when domain names are embedded
in larger structures, so a case could be made that each of these larger
structures should create its own recommendations for dealing with spoofs
of its delimiters.

On the other hand, non-technical users might be misled by all sorts of
punctuation, even symbols that don't resemble the true delimiters.

AMC

---

From: "Adam M. Costello" <[email-masked]>
Date: Tue, 22 Feb 2005 03:49:45 +0000

Gervase Markham <[email-masked]> wrote:

> > Please think twice before creating a precedent of a browser
> > completely blackholing a technically valid (albeit devious) site.
>

The user might be investigating alleged phishers (who are targeting
browsers less protective than the investigator's).

Users often guess domain names.  There might be cases where the common
name of an organization includes non-ASCII punctuation that browsers
would consider unsafe to display, but the organization might want to put
a web server there that redirects users to a safe name when they type
the unsafe name as a guess.

Finally, I don't think we can be sure that our automated phishing
detector has no false positives, so I think making sites completely
inaccessible is overkill when it would be sufficient merely to foil the
spoof by showing an unambiguous form of the name (like the ACE form, or
a Unicode form with certain characters percent-encoded).

AMC

---

From: "Martin v. Löwis" <[email-masked]>
Date: Tue, 22 Feb 2005 07:37:35 +0100

I may be missing something, but I think this cannot be registered:

 >>> u"foo\u0702bar.com".encode("idna")
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "/usr/local/lib/python2.5/encodings/idna.py", line 160, in encode
     result.append(ToASCII(label))
   File "/usr/local/lib/python2.5/encodings/idna.py", line 75, in ToASCII
     label = nameprep(label)
   File "/usr/local/lib/python2.5/encodings/idna.py", line 50, in nameprep
     raise UnicodeError, "Violation of BIDI requirement 2"
UnicodeError: Violation of BIDI requirement 2

So unless my IDNA implementation is incorrect, this label is banned.
Clients should reject it, but if they fail to, atleast the registry
should reject registration.

> in the same domain that the attacker is registered in;

I can't follow this reasoning, either: *if* foo.bar.com was possible,
then I choose foo=www, bar=microsoft, and put an A record for the
resulting label into DNS. The label would *not* be in the domain
microsoft.com.

Regards,
Martin

---

From: "Adam M. Costello" <[email-masked]>
Date: Tue, 22 Feb 2005 07:55:49 +0000

"\"Martin v. Löwis\"" <[email-masked]> wrote:

> > "foo.bar.com", where the first dot was really U+0702.
> 

Sure enough.  I didn't realize U+0702 was right-to-left.  That helps,
but I wonder if there's another dot-lookalike lurking in Unicode.

> > On second thought, the "." homograph attack is less severe than the
> > "/" homograph attack.  The former only allows the attacker to spoof
> > names in the same domain that the attacker is registered in;
>

Let use ! to denote the fake dot.  What I meant was that if the attackee
registers microsoft in the .com domain, then the attacker must likewise
register www!microsoft in the .com domain, and maybe someday the .com
registry will stop allowing such things.

Let's use % to denote the fake slash.  With this attack, the attacker
can register www.microsoft.com%foo in the bar.blah.deep.whatever domain,
unhindered by any restrictions that might someday be put on the .com
domain.

AMC

P.S. What's up with the literal quotes in your display-name?  Is that my
mail program acting funny, or yours?

---

From: "Martin v. Löwis" <[email-masked]>
Date: Wed, 23 Feb 2005 01:43:28 +0100

> mail program acting funny, or yours?

My mail program puts

=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <[email-masked]>

into From; this decodes to

"Martin v. Löwis"

So two of the quotes are mine (from thunderbird) - the other
two must, and the backslashes, must be yours.

Regards,
Martin