Re: [idn] nameprep2 and the slash homograph issue

"Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord.cnri.reston.va.us> Thu, 24 February 2005 08:21 UTC

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15437 for <idn-archive@lists.ietf.org>; Thu, 24 Feb 2005 03:21:42 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4EBY-000JHs-Mo for idn-data@psg.com; Thu, 24 Feb 2005 08:17:24 +0000
Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4EBW-000JHY-L4 for idn@ops.ietf.org; Thu, 24 Feb 2005 08:17:22 +0000
Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D4EBV-0003N6-00 for <idn@ops.ietf.org>; Thu, 24 Feb 2005 00:17:21 -0800
Date: Thu, 24 Feb 2005 08:17:21 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord.cnri.reston.va.us>
To: IETF idn working group <idn@ops.ietf.org>
Subject: Re: [idn] nameprep2 and the slash homograph issue
Message-ID: <20050224081721.GB12336~@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <D872CCF059514053ECF8A198@scan.jck.com> <20050223105244.GE21463~@nicemice.net> <421CA114.9090302@vanderpoel.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <421CA114.9090302@vanderpoel.org>
User-Agent: Mutt/1.5.6+20040722i
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=AWL,BAYES_00 autolearn=ham version=3.0.1
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Erik van der Poel <erik@vanderpoel.org> wrote:

> The IETF generally only specifies the "wire" protocol, not UI
> behavior.  The IETF does not specify how apps interface with users;

Generally, that's true, but IDNA is an exception.  It state four
requirements (RFC 3490 section 3.1), and one of those four has rather
little to do with wire protocols, and quite a lot to do with UI
behavior:

   3) ACE labels obtained from domain name slots SHOULD be hidden from
      users when it is known that the environment can handle the non-ACE
      form, except when the ACE form is explicitly requested.  When it
      is not known whether or not the environment can handle the non-ACE
      form, the application MAY use the non-ACE form (which might fail,
      such as by not being displayed properly), or it MAY use the ACE
      form (which will look unintelligible to the user).

I think this discussion is headed toward an update to IDNA that would
add a second exception to that requirement, for protecting the user
against phishing.  What we need to figure out is how to describe that
exception, and how specific or deliberately vague that description
should be.

AMC