From: Mark Davis (mark.edward.davis@gmail.com)
Date: Wed Mar 18 2009 - 14:23:43 CST
It's not a perfect solution, but it does work better than nothing.
IDNA2008 removes this ability from the client. Although not ideal, that's
probably ok at this point, given the differences between coverage between
Unicode in the 3.2 timeframe and now.
Mark
On Wed, Mar 18, 2009 at 12:40, Shawn Steele (???) <
Shawn.Steele@microsoft.com> wrote:
> Sorry, mail issue, so I got some of these out of order.
>
>
>
> My concern isn’t necessarily the flexibility of allowing registration of
> new scripts/strings, but rather that there’s an inconsistency.
>
>
>
> If Latin were suddenly registered J and I had “catanddog.com”, it might
> start working in older browsers, however “CatAndDog.com” would fail because
> those code points didn’t have mapping rules for C, A & D. So the users
> would end up with an inconsistent experience, and it may even be difficult
> to explain why some versions work and some don’t.
>
>
>
> Not necessarily saying that the flexibility is “bad”, just that I don’t
> think it’s worth it because it’s only a partial solution without some sort
> of idea about the mapping tables.
>
>
>
> Of course “updating to new tables” is also only a partial solution since
> everyone doesn’t bother with updates, but at least then I can tell them why
> it doesn’t work J
>
>
>
> -Shawn
>
>
>
>
>
> *From:* Phillips, Addison [mailto:addison@amazon.com]
> *Sent:* Wednesday, March 18, 2009 11:07 AM
>
> *To:* Shawn Steele (???); Chris Weber ; unicode@unicode.org
> *Subject:* RE: Attack vectors through Unassigned Code Points in IDN
>
>
>
> If it is blocked on the registrar end, illegal addresses wouldn’t point to
> anything… the attack is “possible”, but possibly harmless? (is there such a
> thing)
>
>
>
> If it is blocked on the browser side, users are better insulated from
> potential harm, but valid registrations of new scripts would also
> potentially suffer.
>
>
>
> I do think that showing spaces is probably not appropriate. Maybe the tofu
> (hollow box) or replacement (diamond with question mark) symbol would be
> better---it would look broken.
>
>
>
> I’m not advocating one side or the other, just thinking out loud.
>
>
>
> Addison
>
>
>
> Addison Phillips
>
> Globalization Architect -- Lab126
>
>
>
> Internationalization is not a feature.
>
> It is an architecture.
>
>
>
> *From:* Shawn Steele (???) [mailto:Shawn.Steele@microsoft.com]
> *Sent:* Wednesday, March 18, 2009 10:57 AM
> *To:* Phillips, Addison; Chris Weber ; unicode@unicode.org
> *Subject:* RE: Attack vectors through Unassigned Code Points in IDN
>
>
>
> However those code points may be mapped by an update. There’s no way to
> know if they should be mapped, kept, or even forbidden as a security hole.
> So even if you use the unassigned code points it still might not work.
> Unfortunately revving IDN will require browser updates.
>
>
>
> -Shawn
>
>
>
> *From:* Phillips, Addison [mailto:addison@amazon.com]
> *Sent:* Poʻakolu, Malaki 18, 2009 10:50 AM
> *To:* Shawn Steele (???); Chris Weber ; unicode@unicode.org
> *Subject:* RE: Attack vectors through Unassigned Code Points in IDN
>
>
>
> 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).
>
>
>
> Addison
>
>
>
> Addison Phillips
>
> Globalization Architect -- Lab126
>
>
>
> Internationalization is not a feature.
>
> It is an architecture.
>
>
>
> *From:* unicode-bounce@unicode.org [mailto:unicode-bounce@unicode.org] *On
> Behalf Of *Shawn Steele (???)
> *Sent:* Wednesday, March 18, 2009 10:00 AM
> *To:* Chris Weber ; unicode@unicode.org
> *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.
>
>
>
> -Shawn
>
>
>
> *From:* unicode-bounce@unicode.org [mailto:unicode-bounce@unicode.org] *On
> Behalf Of *Chris Weber
> *Sent:* Pōʻ, Malaki 17, 2009 10:06 PM
> *To:* unicode@unicode.org
> *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 gets pushed
> way out of view in the Address Bar.
>
>
>
> https://www.google.comᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚ.phreedom.org/
>
>
>
>
>
> 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.
>
>
>
> Thanks,
>
> -Chris
>
>
>
This archive was generated by hypermail 2.1.5 : Wed Mar 18 2009 - 14:26:05 CST