Subject: IDN security violation? Please comment

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 08 Feb 2005 13:11:53 +0100

May be IDN specialists will want to comment this.
http://www.shmoo.com/idn/homograph.txt
Is this exact? This is urgent as the IRI is based upon IDN and support of 
multilingualism is a WSIS priority and comments for the WGIG are to close 
the day after tomorrow.
Thank you.
jfc 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 08 Feb 2005 13:41:34 +0100

This is nothing new, analog to YAHOO.COM and YAH00.COM.

	jaap

---

From: John C Klensin <[email-masked]>
Date: Tue, 08 Feb 2005 08:39:14 -0500

> This is nothing new, analog to YAHOO.COM and YAH00.COM.

Well, it is a little worse because there are tools that make
detection of the YAH00.COM problem and its relatives pretty easy
and those tools are widely understood.  For example, forcing
those domain names to lower case makes them very distinguishable
(yahoo.com and yah00.com) are pretty clearly different) and
using fonts that make zeros and "o"s, ones and "l"s, etc.,
clearly different helps a lot too. 

With IDNs, the simple fact that there are tens of thousands of
characters with which one can try to create confusion, rather
than 37 or so, means there are going to be more "opportunities".
What is more important, perhaps, is that we just don't have the
experience with the design of user interfaces that make problem
detection easy.   For example, the moment I touched the Firefox
cursor to the examples at the examples at
http://www.shmoo.com/idn/, I realized that I really wanted to
see the punycode in the status line as well as the "native
character" rendering.  That hadn't occurred to me before,
despite having been thinking about the problems long enough to
have had precisely this Roman-A versus Cyrillic-A example on a
slide in a talk I gave in March of 2001.

There have been other suggestions along the line that would help
although the community (with some notable exceptions) hasn't
been good at deploying them and the IETF decided (perhaps
appropriately, perhaps not) that they were someone else's
problem.  For example, Mark Davis made a suggestion early on
that registration of labels containing mixed scripts be
prohibited.  If that had been done in the relevant zone, this
particular attack would have been impossible.  A corollary to
his suggestion might be a warning message from software that
interfaces with users that would flag mixed-script labels and
put up warnings.

Just as with the YAH00.COM case, no single measure is going to
"fix" or prevent the various problems we can encounter with
IDNs.  But a combination of some thinking, good policies,
adapting tools on the basis of experience, and the level of user
vigilance that seems a requirement for being attached to the
Internet at all these days ought to permit us to use IDNs at
risk comparable to that for LDH-style ASCII names.

I can only hope that our colleagues at Mozilla will rapidly
supercede their apparent advice to disable IDNs --advice that
seems to me to be equivalent to "you should be happy just using
English"-- with patches or extensions that enable punycode
display in addition to native-script display in the status line
and that they consider warnings about mixed-script labels.
And, while I am engaging in hope, I hope that the other
browser-producing teams will get with the program: The IESG has
warned, I have warned, Mark has warned, and innumerable others
have warned, that a compliant implementation of IDNA is _not_
sufficient for a competent implementation of IDNs.  This
particular problem, however exciting, is just another example of
that general principle.

   john

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 08 Feb 2005 15:18:10 +0100

Dear John,
you are right the lack of the really requested IRI in the bar is a true 
problem. But this would we appealing for babel-names (the IDNs which 
transcode in xn--squatting names such as "http://xn--cocacola.com").

Could not a correct solution be to have an option warning the 
user/preventing the use when the IRI's IDN part does not use codes 
belonging to the used language ccTLD IDN table?

This is because a ccTLD will have exactly the same homograph problems in 
domain name registration, so IDN Tables codes are expected to be/to adapt 
to what a usual script reader can expect (possibly on a country culture 
basis). I fully understand that gTLD may not enforce that and that IDN 
permits 3LD to be freely built, but this seems consistent with the ICANN 
recommendations. I also fully understand that this creates a confusion with 
the "RFC 3066bis" draft which did not wanted to consider that kind of issue 
and stay generic. We not only meet in DNS, but also in any text oriented 
formatted exchange (mail?) and application firewalling service (starting 
with OPES or sieve?).

jfc

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 08 Feb 2005 15:20:38 +0100

Hi John,

    

And for me personally this is not really new, because I have been
following the IDN debate from the beginning and seen the problems
of mixed scripts on other occasions.

The principle is not really new. And yes, it is a matter of tools
fonts, etc. The example at my machine displays quite different (in
than on the of a co-worker next to me (same operating system,
freeBSD; same browser (firefox)).  I just happen to have cyrillic
fonts installed.

We are likely in violent agreement. I've been using cyrillic
characters looking like Latin ones in my slides as well as examples.
And when I explained my co-worker what was going on, he also wanted
to see the punycode.
    
    prohibited.

That's what the polish registry does on the moment. Although it
isn't 100%

    If that had been done in the relevant zone, this
    particular attack would have been impossible.  A corollary to
    his suggestion might be a warning message from software that
    interfaces with users that would flag mixed-script labels and
    put up warnings.

But still, with some characters of one script looking like other
ones, it is still a possible ``phishing style'' attack. It will
lower the chance that one can make up something meaningfull.

Agreed. One of the things that had been proposed was ``bundeling''.
That would help a bit in this case (although I can imagine court
cases disputing whether the bundeling was done properly).

In full agreement here,

	jaap

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 09 Feb 2005 00:00:35 +0900

JFC (Jefsey) Morfin wrote:

> Is this exact? This is urgent as the IRI is based upon IDN and support 
> of multilingualism is a WSIS priority and comments for the WGIG are to 
> close the day after tomorrow.

That is a well known attack.

I made presentation in 1997 at Munich IETF warning that first 'C'
of MICROSOFT.COM may be Cyrillic character with a shape identical
to that of Latin 'S' that blank minded internationalization is the
bad idea unless all the characters are distinguishable by all the
users.

However, blank minded people thought Unicode were a good idea.

You are obserbing the inevitable consequances.

						Masataka Ohta

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 08 Feb 2005 16:12:21 +0100

> belonging to the used language ccTLD IDN table?

I agree that this can be part of the counter-measures to this security
problem.  I encourage application writers to implement that approach,
by using an API that is part of libidn:

http://josefsson.org/libidn/manual/html_node/TLD-Functions.htm

Alas, some ccTLDs doesn't appear to understand the problem.  Perhaps
we can raise awareness of the problem with them.  Then maybe ccTLDs
will publish lists of permitted code points under an acceptable
license.

Thanks,
Simon

---

From: James Seng <[email-masked]>
Date: Tue, 08 Feb 2005 23:21:16 +0800

For the 5th time today, it is already documented in RFC 3490.

http://james.seng.cc/archives/2005/02/08/idn_and_homographs_spoofing.html

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 09 Feb 2005 00:48:34 +0900

> characters looking like Latin ones in my slides as well as examples.

Russian people won't accept their 'C' shaped character represented
by anything (definitely not punycode) other than the 'C' shape.

> And when I explained my co-worker what was going on, he also wanted

It means that you can do with GIF images and ASCII URLs without
false internationalization by Unicode.

						Masataka Ohta

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 08 Feb 2005 20:31:40 +0100

Dear James,
A Registry can certainly take care of SLD, not of lower levels. IMHO the 
problem is no more with IDNs (no one want to change RFC 3490!), but to 
avoid to propagate the problem into the IRI. For that we need to have a 
precise langtag to precisely define the IDN locale in the IRI and precises 
rules concerning the way the IDN should the be built in the IRI (including 
the TLD). Obviously such rules should only be to inform the user (I do not 
thing there is way to force them), so may result from a BCP.

May be interesting to write it, rather than to leave it to ICANN or to ITU?
jfc

---

From: John C Klensin <[email-masked]>
Date: Tue, 08 Feb 2005 14:41:10 -0500

James,

At one level, you are clearly correct, and several other people
have made the same observation today and over the last four
years.  Certainly, as my note and others indicated even before
you posted yours, this is old news.  That fact doesn't change
things much, even if it has some limited "I told you so" value.
Obviously we could quibble about whether the warning about
implementation warnings in RFC 3490, or the IESG statement, or
the ICANN guidelines, separately or together, go far enough or
are precise enough about what is needed to be useful.  But we
have had that particular discussion several times and repeating
it here (or elsewhere) has ceased to be entertaining and is
probably not useful.  

It is perhaps worth noting that the 3490 suggestion that "visual
indications where a domain name contains mixed scripts" may be
problematic as a recommendation for actual implementations:
although inverting them would probably help, the tables for
which characters fall into which of the huge number of scripts
in the world represent far more baggage for an implementation to
carry around than the nameprep/stringprep tables required by
IDNA.

Similarly, for an application to check the characters/ scripts
supported by a particular ccTLD, as suggested by one of the
contributors to your blog, is problematic.  One would really not
like to carry around a list of ccTLDs and their permitted
characters in an application, first because that could be a very
large set of tables, second because the lists change as ccTLD
policies evolve and tables in deployed applications are
notoriously hard to update, and third because it does nothing
for gTLDs.   One could design a bit of protocol that would
permit querying the ccTLD for the accepted character list (or a
protocol similar to that described in
draft-klensin-name-munging-03.txt could be trivially extended),
but that would add overhead and raise issues about authoritative
and authenticated lists and do nothing for third level
subdomains and below.   One might, more plausibly, think about a
new DNS RR whose data field would contain the permitted
character list for a given zone, perhaps with some provision for
ranges (which would perhaps keep the DNS record from being
overwhelmed by CJK), but no one has even started thinking that
through carefully as to whether it would be either feasible or
useful in practice.

For the application to identify whether or not something is an
IDN (another suggestion that has been made several times) is
also not likely to be especially useful except in the short
term: homographic problems can be demonstrated as easily between
pairs of non-Roman scripts as between ASCII names and some other
script, with the combination of Greek and Cyrillic being one
example that is particularly rich with "opportunities".

I actually think the mini-flap about this example is helpful.
Sure, it is old news to the specialists (including everyone who
participated in the IDN WG and paid attention and everyone who
has read 3490 and the IESG note carefully).  But, despite that
specialist knowledge, the issue has not gotten the attention of
the community: within the last 24 hours, users and registrants
have been surprised, a few have even been horrified, and that is
probably a good thing.  Applications have been implemented that
support IDNA without any of the "maybe this is bogus" warnings
that we know how to provide, and think should be provided, and
perhaps this will get the attention of those implementers too.
And, without bashing any particular offender --despite the
implication in your blog, the one you single out is not unique
and it is not useful in any event-- perhaps this will help
convince registries who have been inclined toward either "IDNA
with no further restrictions" or "very broad ranges of
characters, intermixed" policies that the recommendations to
restrict labels to specific languages and/or scripts really are
important from a customer protection standpoint and that they
have some responsibility in that area.

Regards,
   john

p.s. Jefsey, the only relevant WSIS message here is that blindly
going off and enthusiastically implementing and deploying IDNs
(or IRIs), without consideration of these issues that have been
well-understood for years, puts users at risk to the point of
being irresponsible.  That doesn't imply in any way that IDNs
are bad, only that one needs to consider the systems of which
they are a part, do registrations and implementations with
appropriate safeguards and user education, and that handwaving
is not a sufficient way to address the issues.  And, again, that
is very old news -- to the extent that, if the WSIS process and
contributors don't understand it, it is a problem with their
processes.

--On Tuesday, 08 February, 2005 23:21 +0800 James Seng
<[email-masked]> wrote:

>> Is this exact? This is urgent as the IRI is based upon IDN
>> and support  of multilingualism is a WSIS priority and
>> comments for the WGIG are to  close the day after tomorrow.
>> Thank you.
>> jfc
>

---

From: Sam Hartman <[email-masked]>
Date: Tue, 08 Feb 2005 16:01:00 -0500

>>>>> "JFC" == JFC (Jefsey) Morfin <[email-masked]> writes:

    JFC> Dear James, A Registry can certainly take care of SLD, not of
    JFC> lower levels. IMHO the problem is no more with IDNs (no one
    JFC> want to change RFC 3490!), but to avoid to propagate the
    JFC> problem into the IRI. 

Handling this problem at the IRI level is inappropriate.  I don't
think that the domain slot in the IRI is any different than other
internationalized domain slots.  

I think we implicitly decided that this problem did not need a
protocol-level fix when we failed to require such a fix either for
IDNs or for all internationalized domain slots.

I think that there was sufficient discussion of the issue that people
were aware of the implications of this decision.

--Sam

---

From: James Seng <[email-masked]>
Date: Wed, 9 Feb 2005 09:45:10 +0800

John,

You are absolutely right. I believe there is a current discussion 
within the Mozilla community to flag out IDN. There would certainly 
help but would not help with 'sex.com' (as one guy noted on circleid) 
if 'sex' is all written in Cyrillic.

I am also concern about creating new protocols to say 'look up valid 
characters' within an IDN. Nice idea but would increase a lot of 
overhead to application developers and also to the network.

I taken a look at your name munging. I think we did an implementation 
of a similar idea back when I was in i-DNS except we do it using a 
modified DNS. what it does is you can query a (utf).foobar.tld and the 
query will response CNAME (ACE).tld or something like that. Of course, 
it is a private implementation and the idea need more work. But i think 
it might be useful to look at DNS rather then inventing new protocol. 
(Okay, for those who is afraid to load on more stuff on DNS, we can 
also consider SOAP).

ps: Sorry for the duplicates. Fast fingers :P

-James Seng

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 8 Feb 2005 18:36:28 -0800

I want to also bring the UTR #36 Security Considerations for the
Implementation of Unicode and Related Technology. Although still draft, we
will be fleshing it out over time. Feedback is welcome.

http://www.unicode.org/reports/tr36/

‎Mark

----- Original Message ----- 
From: "James Seng" <[email-masked]>
To: "JFC (Jefsey) Morfin" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Tuesday, February 08, 2005 07:21
Subject: Re: IDN security violation? Please comment

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 09 Feb 2005 04:00:31 +0100

>http://www.unicode.org/reports/tr36/

Brillant.

I think the danger is in the faked IRI usage. And the first way to protect 
the IRI is to alert on non permitted codes being used in the IDN part (this 
is where the spoofing is carried). I do not buy Jon's argument that 
filtering IRI against ccTLD Tables would be too much expensive: yes for 
each application, but this is precisely a job for OPES.

Question: what would be the load of a file giving for each code its 
availability in each ccTLD table for each script? And how does that compare 
with the 1.5 Meg base of my anti-virus?
jfc

>â€ŽMark

---

From: Martin Duerst <[email-masked]>
Date: Fri, 18 Feb 2005 14:48:28 +0900

>carry around than the nameprep/stringprep tables required by

Not necessarily true. The relationship between scripts and
blocks in Unicode is fairly straightforward; there are extremely
few blocks that contain two real scripts (as opposed to one
script and 'neutral' stuff such as punctuation, or one script
and unassigned codepoint). The experience from existing
implementations is that stringprep/nameprep comes in at
something like 100 to 200 KB. Strictly checking for normalization
(NFC in the case I implemented) comes in at 40-50 KB. My
guess is that script checking could probably be done at
something around 10 KB, maybe even less. And the number
of scripts around the world isn't really that huge; Unicode
at the moment has around 40, and while that doesn't include
Egyptian hieroglyhps, is't very comprehensive for what you
need for domain names.

By this, I don't want to imply that simple script checking
is the way to go. Maybe it is, maybe it isn't.

 >subdomains and below.

[You mentioned this yourself on the IDN list, I'll
just also mention it here so that it's documented.]

Besides the fact that it seems rather useless to design
such a protocol if we already have one: DNS. Because
this is only about existing domain names, it's easy:
if it resolves, it must have been allowed.
The cases where it resolves but wasn't supposed to are
due to bugs or security attacks,... that should be addressed
by different means.

Regards,   Martin.