Message-Id: <6.1.2.0.2.20050208145906.0d03b3c0@mail.jefsey.com>
Date: Tue, 08 Feb 2005 15:18:10 +0100
To: John C Klensin <john-ietf@jck.com>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
In-Reply-To: <CB4CC5F257CA4E86A0A9C9F8@scan.jck.com>
References: <200502081241.j18CfY3F011450@bartok.nlnetlabs.nl>
	<CB4CC5F257CA4E86A0A9C9F8@scan.jck.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: ietf@ietf.org
Subject: Re: IDN security violation? Please comment
Precedence: list
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

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



On 14:39 08/02/2005, John C Klensin said:


>--On Tuesday, 08 February, 2005 13:41 +0100 Jaap Akkerhuis
><jaap@NLnetLabs.nl> wrote:
>
> >     May be IDN specialists will want to comment this.
> >     http://www.shmoo.com/idn/homograph.txt
> >
> > 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


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf