From: Shawn Steele (???) (Shawn.Steele@microsoft.com)
Date: Wed Mar 18 2009 - 13:16:03 CST
Its kind of a personal perspective as to whether lookup of unassigned code points is good behavior or not. My opinion (rather obviously) is that the unknowns aren't worth the risk considering we'll service the APIs when necessary.
This archive was generated by hypermail 2.1.5
: Wed Mar 18 2009 - 13:18:20 CST
I figure with Windows Update, for consumers of my APIs they'll get updated in a reasonable time (assuming the IETF "we" ever make any progress on IDNA"2008" ;) Some people turn off WU, but that's a different problem.
Not sure this is a Unicode thread though :)
From: Mark Davis [firstname.lastname@example.org]
Sent: Wednesday, March 18, 2009 11:35 AM
To: Phillips, Addison
Cc: Shawn Steele (???); Chris Weber; email@example.com
Subject: Re: Attack vectors through Unassigned Code Points in IDN
IDNA forbids registration of unassigned code points, but allows lookup with them by clients (eg browsers). The goal was to allow users to supply characters that were of a later Unicode version than their client software supports, and yet have the lookup work where the registry supports that later version of Unicode.
I agree with Shawn, there are plenty of techniques like https://www.google.com.secure.net or https://www.google.com-secure.net; as far as I'm concerned, it is a deficiency in the browser if it doesn't signal these kinds of problems to the user.
On Wed, Mar 18, 2009 at 10:50, Phillips, Addison <firstname.lastname@example.org<mailto:email@example.com>> wrote:
Dropping unassigned code points would mean that newly assigned characters in Unicode could not be used without a browser update. So maybe that *isn’t* a good idea. Registering a name with unassigned code points is a bad idea (users will have a difficult time using the address and the name’s semantics/meaning/display would change when the character is assigned).
Globalization Architect -- Lab126
Internationalization is not a feature.
It is an architecture.
From: firstname.lastname@example.org<mailto:email@example.com> [mailto:firstname.lastname@example.org<mailto:email@example.com>] On Behalf Of Shawn Steele (???)
Sent: Wednesday, March 18, 2009 10:00 AM
To: Chris Weber ; firstname.lastname@example.org<mailto:email@example.com>
Subject: RE: Attack vectors through Unassigned Code Points in IDN
(speaking as myself)
Sounds like a Firefox bug. Unassigned code points should cause an error since they aren’t assigned. If they were dropped, then at the least, the shortened name should show up in the address bar.
For most users this probably doesn’t matter much since you can easily contrive URLs that look real at a quick glance or to someone not familiar with URLs, eg: https://www.google.com.secure.net would fool many users.
From: firstname.lastname@example.org<mailto:email@example.com> [mailto:firstname.lastname@example.org<mailto:email@example.com>] On Behalf Of Chris Weber
Sent: Pōʻ, Malaki 17, 2009 10:06 PM
Subject: Attack vectors through Unassigned Code Points in IDN
In I’m reading RFC 3491 correctly, then IDNA allows for unassigned code points to exist in strings and domain names. This makes spoofing attacks possible when one these code points don’t have associated glyphs and basically show up as white space. This seems to be the case with some ranges like U+115A..U+115E under. In this case the following URL provides an attack vector in Firefox, because the domain nottrusted.org<http://nottrusted.org> gets pushed way out of view in the Address Bar.
My question is – was this the intended behavior of IDNA to allow unassigned code points in IDN? Or is this more related to a font rendering issue?
7. Unassigned Code Points in Internationalized Domain Names
If the processing in [IDNA] specifies that a list of unassigned code
points be used, the system uses table A.1 from [STRINGPREP] as its
list of unassigned code points.
This archive was generated by hypermail 2.1.5 : Wed Mar 18 2009 - 13:18:20 CST