Re: [idn] Re: process

James Seng <james@seng.cc> Fri, 25 February 2005 16:56 UTC

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07566 for <idn-archive@lists.ietf.org>; Fri, 25 Feb 2005 11:56:50 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4ig2-000Mb5-CF for idn-data@psg.com; Fri, 25 Feb 2005 16:50:54 +0000
Received: from [61.215.206.254] (helo=vbn.inter-touch.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4ifz-000Mae-IK for idn@ops.ietf.org; Fri, 25 Feb 2005 16:50:51 +0000
Received: from [219.101.164.151] (unknown [219.101.164.151]) by vbn.inter-touch.net (Postfix) with ESMTP id 433CC40033E; Sat, 26 Feb 2005 01:50:41 +0900 (JST)
In-Reply-To: <421F482B.1060909@vanderpoel.org>
References: <D872CCF059514053ECF8A198@scan.jck.com> <421D8411.9030006@vanderpoel.org> <p06210208be4390618c81@[192.168.0.101]> <421E0D0C.2000309@vanderpoel.org> <p06210202be43c3888991@[192.168.0.101]> <E07CE813AD23B2D95DA0C740@scan.jck.com> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <20050225113725.GA8820@nic.fr> <421F482B.1060909@vanderpoel.org>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <2b4b22d85b2872558414c64071e7b993@seng.cc>
Content-Transfer-Encoding: 7bit
Cc: idn@ops.ietf.org, Stephane Bortzmeyer <bortzmeyer@nic.fr>, Doug Ewell <dewell@adelphia.net>
From: James Seng <james@seng.cc>
Subject: Re: [idn] Re: process
Date: Sat, 26 Feb 2005 00:50:44 +0800
To: Erik van der Poel <erik@vanderpoel.org>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

FYI, punctuation were also debated extensively back then so it isn't 
really 'Oh, we just discover this!'.

It's just interesting to see people putting it into action. Does apps 
needs to be fixed? Yes, absolutely. App developers needs to go read the 
security consideration of rfc3490 and think about how to implement some 
solution to reduce the spoofing risk.

but does it warrant changing the existing rfc? I dunno..I havent seen 
anything that suggest we missed something back then.

-James Seng

On 25-Feb-05, at PM 11:45, Erik van der Poel wrote:

> Stephane Bortzmeyer wrote:
>> The issue has been discussed at length. See
>> the "Security Considerations" of RFC 3490.
>
> It is true that some of the issues are pointed out by that section, so 
> the registries and application developers have to pay attention. But 
> one  might argue that we have recently been discussing a new *class* 
> of homographs. The RFC mentions "multiple scripts" and one and l. 
> These two refer to letters such as Cyrillic small 'a' and digits (the 
> "one"). But the slash homograph recently raised on this list might be 
> considered to be a new class of homograph (punctuation), not 
> specifically indicated in the RFC. Not only is this type of character 
> different from letters and digits, it is arguably even more dangerous 
> than the script-based (Cyrillic) attack, since it can be done in a 
> domain label that is not under the control of the registries. So that 
> first line of defense is not there, and we must rely totally on the 
> apps, and there are many.
>
> One could argue that a new document should be published and widely 
> circulated to warn about this new kind of attack. One of my questions 
> is whether this warning should appear in a new version of the RFC, or 
> in a separate document. Alternatively, it may be decided that this 
> type of homograph is so different and so dangerous that a new version 
> of the protocol that prohibits these characters, with a new ACE 
> prefix, should be created. I don't know.
>
> Also, the "multiple scripts" wording does not specifically cover the 
> all-Cyrillic case. So that part could be tightened up too.
>
> By the way, the RFC's Security section includes the following:
>
>    No security issues such as string length increases or new
>    allowed values are introduced by the encoding process or the use of
>    these encoded values, apart from those introduced by the ACE 
> encoding
>    itself.
>
> What does this mean, exactly? Are any new allowed values introduced by 
> the ACE encoding? This part could be clearer.
>
> Also, O and 0 are mentioned, but is this technically correct? I mean, 
> aren't uppercase ASCIIs supposed to be lowercased? I'm sorry if I'm 
> wrong about this part.
>
>> Nothing new in the recent announces, just
>> sensation papers.
>
> Again, I think the slash homograph might be new. Do you have evidence 
> to suggest that it *was* considered by the WG or anybody else?
>
>> The Powers Above require that Something should be done
>
> Have you seen any indication of this?
>
> Thanks,
>
> Erik
>